Redis主從複製、讀寫分離

前言

主從複製，即主機數據更新後根據配置和策略，自動同步到備機的master/slave機制，Master以寫爲主，Slave以讀爲主。主要用於讀寫分離和容災恢復

一. 如何使用

1. 「一主二僕」

1.1 修改配置文件

"一主二僕"是指一臺主機，兩臺從機，咱們在虛擬機中模擬這三臺機器（即讓redis服務在三個不一樣的端口運行），先拷貝兩份redis配置文件，並重命名以便啓動時區分

再在每份配置文件中修改以下配置項（此處以redis6380.conf爲例）：

a). 指定端口（重要）

b). pidfile

c). logfile

d). dbfilename

e). 開啓daemonize yes

*以上配置項按照配置文件不一樣作相應修改

由於是在一臺CentOS虛擬機上模擬了三個redis服務器，所以須要在開啓客戶端命令的後面加上端口號加以區別，不然默認會進入到6379端口的客戶端。例如，要進入6380端口的客戶端，使用命令

redis-cli -p 6380

三個客戶端同時啓動以下：

在6379端口Master主機輸入info replication，能夠查看主機與從機之間的鏈接狀況

能夠看到，如今6379端口的role是master，connected_slave如同其字面意思，表明鏈接上的從機，此時是0個。Slave從機在進行鏈接以前，輸入info replication獲得的結果和上面是同樣的。

1.2 從機鏈接主機

在兩個從機中使用以下命令，或者將以下命令寫到配置文件中

slaveof <主機IP> <主機端口>

提示ok後，再在兩個從機中輸入info replication命令應該會獲得以下結果：

此時，主機中info replication命令執行後獲得

此時，主從鏈接就已經創建了。若是在主機中set了字段，兩個從機會當即各自複製一份，保持和主機的數據同步，所以，在從機中也能夠get到該字段的值。另外，從機會開啓只讀模式，裏面的數據不能手動刪除或更改，只能跟隨主機中的數據的變化而變化。從機一旦鏈接上主機，就會把主機中全部數據都拷貝過來（並非只複製鏈接上主機後，主機中後來添加的數據）。

可是這裏鏈接還可能遇到一些小問題，就是若是主機設置了鏈接校驗密碼（具體能夠參看jedis初探的第三節），直接按照上面slaveof命令操做的話雖然也會返回ok，但實際上並無鏈接成功（能夠自行用info replication命令測試），遇到這樣的問題能夠採用以下解決辦法：

修改從機配置文件，將masterauth的註釋取消，並將主機的鏈接校驗密碼填上，以下圖

保存文件後，重啓redis服務，再進行slaveof鏈接主機，就能夠成功了。

1.3 總結

• 配從（庫）不配主（庫）
• 從庫配置：slaveof 主庫ip 主庫端口（每次與master斷開以後，都須要從新鏈接，除非你配置進redis.conf文件）
• 可使用info replication查看鏈接狀況

2. 「薪火相傳」

2.1 什麼意思

在上面的「一主二僕」中，是1臺主機鏈接了2臺從機，但實際狀況中，主機鏈接的從機數量可能有多臺，以下圖，鏈接的從機數量越多，主機的負擔越重

下圖這種模式就是一種「去中心化」的模式，從機再也不是集中從Master複製數據，而是能夠從其餘從機中複製，減輕了主機的負擔。以下圖中slave2就是從slave1中複製的數據

所以，所謂的「薪火相傳」指的是：上一個slave能夠是下一個slave的master，slave一樣能夠接收其餘slaves的鏈接和同步請求，該slave做爲了鏈條中下一個的master，能夠有效減輕master的寫壓力。

2.2  一個例子

6379端口的做爲master機，6380端口的做爲slave1，鏈接master，6381端口的做爲slave2，鏈接slave1。鏈接圖示和上面相同。鏈接成功後，master寫入數據，slave1立刻就會複製一份，而slave2也會立刻從slave1中複製一份。此時，slave1的身份信息以下：

它雖然擔當了slave2的master，但它自己仍是要從6379端口的master機中複製數據，因此它的role爲slave，同時，由於slave2連在它身上，因此connected_slaves顯示鏈接的從機數爲1。

這種「薪火相傳」的使用方法也很簡單，slave2以前鏈接的是6379端口的master，如今要改鏈接到6380端口的slave1，只須要使用以下命令：

slaveof 127.0.0.1 6380
#slaveof <從機ip> <從機端口>

須要注意的是：中途變動轉向，會清除以前的數據，從新創建拷貝最新的。什麼意思呢？slave2原來鏈接的是6379端口的master，其數據庫中就有master機的所有數據，改變鏈接後，就會刪除這些數據，從新創建對slave1的數據拷貝

3. 「反客爲主」

使當前數據庫中止與其餘數據庫的同步，轉成主數據庫

使用命令：slaveof no one

舉個例子：

在上圖的主從關係中，若是master主機忽然「掛了」，這時，slave1和slave2所採起的操做是「原地待命」，一直等待master從新回來。此時，能夠在一個從機中使用slaveof no one 命令，讓從機變成主機，繼續擔當master的任務。這時，其餘從機能夠轉鏈接到該主機上，從新組成一個主從體系。

4. 使用jedis進行主從複製

可是程序執行中可能出現下面這種狀況：

結果爲null值，這裏並非程序出了什麼錯，而是內存數據庫太快了，致使沒有取到值（程序慢於內存，redis中已經有值了，而程序還沒取到）。若是你在redis客戶端使用get命令（或者再運行一遍程序），就會發現實際上是有值的。

注意：主從的配置（slaveof）通常不在代碼中控制，而是由架構/技術經理規定好主從關係，並在後臺使用unix命令配好，開發人員須要關注的是誰是主誰是從，以及主從的讀寫操做便可。

二. 複製原理

1. Slave啓動成功鏈接到master後會發送一個sync命令
2. Master接到命令啓動後臺的存盤進程，同時收集全部接收到的用於修改數據集的命令， 在後臺進程執行完畢以後，master將傳送整個數據文件到slave,以完成一次徹底同步
3. 全量複製：slave服務在接收到數據庫文件數據後，將其存盤並加載到內存中。
4. 增量複製：Master繼續將新的全部收集到的修改命令依次傳給slave,完成同步。
5. 只要是從新鏈接master,一次徹底同步（全量複製）將被自動執行。首次是全量複製，以後是增量複製。

三. 複製的缺點

複製延時：因爲全部寫操做都是先在master上操做，而後同步更新到slave上，因此從master同步到slave機器有必定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重。slave機器數量的增長也會使這個問題更加嚴重

 

四. 哨兵模式（經常使用）

1. 是什麼

哨兵巡邏，可以後臺監控主機是否故障，若主機發生故障就會自動在剩餘的從機中經過投票的方式選出新的主機，並自動進行切換。簡單來講是上面「反客爲主」的自動版，可是也有些不一樣的地方。

2. 使用步驟

2.1 在redis安裝目錄下新建sentinel.conf文件，名字絕對不能錯

2.2 配置哨兵，填寫內容。在sentinel.conf中填寫以下內容

sentinel monitor 被監控的主機的名字（名字本身起）127.0.0.1 6379 1
#上面最後一個數字1，表示最低經過票數（主機掛掉後投票看讓誰接替成爲主機）

2.3 啓動哨兵

如上圖所示，咱們須要用到redis/bin目錄下的redis-sentinel工具，啓動時還須要帶上咱們剛纔設置的配置文件，啓動命令及啓動效果以下：

3. 遇到的問題

學習過程當中遇到主機掛掉後，哨兵自動切換出現故障的問題，具體表現爲：主機掛掉後，從新啓動鏈接不上新的主機；且有的時候，從機也連不上新的主機。爲此十分苦惱，在查閱了相關資料並進行了一些試驗後發現，原來是由於個人redis是設置了校驗密碼的，這裏的配置中須要增長一些內容，具體以下：

1). 在哨兵的配置文件sentinel.conf中，增長主機校驗密碼，改爲以下內容：

sentinel monitor mymaster 127.0.0.1 6381 1
sentinel auth-pass mymaster 123456  #增長主機校驗密碼

2). 在redis配置文件中（包括主機和從機），都添加requirepass和masterauth配置

requirepass "123456"
masterauth "123456"

須要注意的是，主機從機都儘可能設置同樣的密碼！而且主機中要添加masterauth，這點很容易被忽略，由於主機在掛掉後從新啓動，它將做爲從機去鏈接新的主機，若是沒有這項就會致使鏈接不上新的主機。

在這個過程當中，哨兵日誌是「滯後」的，好比有時候從新啓動主機，查看其info replication顯示它鏈接的是另外一個從機而不是新主機，且鏈接狀態是down，過一下子，日誌中才更新消息，將其鏈接改成鏈接到新主機

五. 參考資料

http://www.javashuo.com/article/p-udkxqvam-cb.html（redis哨兵配置詳解）

http://blog.csdn.net/a67474506/article/details/50435498（解讀redis哨兵日誌內容）