redis演練(6) redis主從模式搭建

redis是一款面向分佈式的Nosql產品，天生對主備模式有很好的支持，並且配置一套完整的主備模式，很是簡單。針對redis，主備模式配置很是簡單，但線上意義重大。

主要內容

1.CAP理論

2.簡單redis的複製原理

3.redis replaction相關配置參數解析

4.配置星型模型主備模式

5.配置有向無歡模型主備模式

1.研磨redis的複製與集羣概念

redis的複製與集羣，剛開始我把二者鬧了個誤會，在不斷深刻學習過程當中及時改正了。

簡單區分一下。

redis複製：能夠理解爲把redis服務copy多份，供客戶端訪問。但服務器間持有的數據時同樣的。能夠類比下oracle的RAC，和mysql數據庫中的主備模式。主要解決redis服務的可靠性，擴展性上。

redis集羣：集羣主要解決大數據量問題。一個機器內存和存儲每每是有限的，但數據量的增加每每是「無限」的，可使用集羣，將數據分散到多個redis服務中。若是你能想到memcached的一致性哈希算法，那就對了。

無論redis 複製核集羣，都會涉及到節點信息的同步，不得不要受到CAP理論的影響。

2.CAP理論介紹

CAP定理（CAP theorem），又被稱做布魯爾定理（Brewer's theorem），它指出對於一個分佈式計算系統來講，不可能同時知足如下三點：

• 一致性（Consistence) （等同於全部節點訪問同一份最新的數據副本）

• 可用性（Availability）（對數據更新具有高可用性）

• 容忍網絡分區（Partition tolerance）（以實際效果而言，分區至關於對通訊的時限要求。系統若是不能在時限內達成數據一致性，就意味着發生了分區的狀況，必須就當前操做在C和A之間作出選擇^[3]。）

根據定理，分佈式系統只能知足三項中的兩項而不可能知足所有三項[4]。

redis 的設計和配置，也是在儘可能解決CAP引發的問題，但不可能完全決絕，只能在三者中進行平衡。

3.Redis複製概論

數據庫複製指的是發生在不一樣數據庫實例之間，單向的信息傳播的行爲，一般由被複制方和複製方組成，被複制方和複製方之間創建網絡鏈接，複製方式一般爲被複制方主動將數據發送到複製方，複製方接收到數據存儲在當前實例，最終目的是爲了保證雙方的數據一致、同步。

複製示意圖

Redis的複製方式有兩種，一種是主（master）-從（slave）模式，一種是從（slave）-從（slave）模式，所以Redis的複製拓撲圖會豐富一些，能夠像星型拓撲，也能夠像個有向無環：


Redis集羣複製結構圖
經過配置多個Redis實例獨立運行、定向複製，造成Redis集羣（這兒集羣的概念是廣義上的概念），master負責寫、slave負責讀。

經過複製，能夠達成如下目標

一、高可用性(若是master宕機，slave能夠介入並取代master的位置)
二、高性能(主備分離，分擔master壓力)
三、水平擴展性(按二八定律，增長slave機器能夠橫向（水平）擴展Redis服務的整個查詢服務的能力)

帶來的問題：

1.同步開銷
2.數據不一致性問題
3.編程複雜

4.redis replaction相關配置參數解析

slaveof <masterip> <masterport>	#設置該數據庫爲其餘數據庫的從數據庫時啓用該參數。 #設置當本機爲slave服務時，設置 master 服務的 IP 地址及端口，在 Redis 啓動時，它會自動從 master 進行數據同步
slave-serve-stale-data yes	#當從庫同主機失去鏈接或者複製正在進行，從機庫有兩種運行方式： #1)若是 slave-serve-stale-data 設置爲 yes( 默認設置 ) ，從庫會繼續響應客戶端的請求 #2)若是 slave-serve-stale-data 是指爲 no ，出去 INFO 和 SLAVOF 命令以外的任何請求都會返回一個錯誤 "SYNC with master in progress"
slave-read-only yes	#配置 slave 實例是否接受寫。寫 slave 對存儲短暫數據（在同 master數據同步後能夠很容易地被刪除）是有用的，但未配置的狀況下，客戶端寫可能會發送問題。
repl-ping-slave-period 10	#從庫會按照一個時間間隔向主庫發送 PINGs. 能夠經過 repl-ping-slave-period 設置這個時間間隔，默認是 10 秒
repl-timeout 60	#repl-timeout  設置主庫批量數據傳輸時間或者 ping 回覆時間間隔，默認值是 60 秒 # 必定要確保 repl-timeout 大於 repl-ping-slave-period
repl-diskless-sync no	啓動無磁盤複製。往備節點同步，不須要中間先生成文件再進行同步。
repl-diskless-sync-delay 5	同步前的延時, 以等待其餘的要連接的slave 配置傳輸開始的延遲時間，以便等待更多的從服務器鏈接
repl-disable-tcp-nodelay no	#在 slave socket 的 SYNC 後禁用 TCP_NODELAY #若是選擇「 yes 」 ,Redis 將使用一個較小的數字 TCP 數據包和更少的帶寬將數據發送到 slave ， 可是這可能致使數據發送到 slave 端會有延遲 , 若是是 Linux kernel 的默認配置，會達到 40 毫秒 . #若是選擇 "no"，則發送數據到 slave 端的延遲會下降，但將使用更多的帶寬用於複製.
repl-backlog-size 1mb	#設置複製的backlog(後臺日誌)大小。 #複製的後臺日誌越大， slave 斷開鏈接及後來可能執行部分複製花的時間就越長。 #後臺日誌在至少有一個 slave 鏈接時，僅僅分配一次。
repl-backlog-ttl 3600	#在 master 再也不鏈接 slave 後，後臺日誌將被釋放。下面的配置定義從最後一個 slave 斷開鏈接後須要釋放的時間（秒）.#0意味着從不釋放後臺日誌
slave-priority 100	#若是 master 不能再正常工做，那麼會在多個 slave 中，選擇優先值最小的一個 slave 提高爲 master ，優先值爲 0 表示不能提高爲 master
min-slaves-to-write 0	執行寫操做所需的至少從服務器數量 #若是少於 N 個 slave 鏈接，且延遲時間 <=M 秒，則 master 可配置中止接受寫操做。 #例如須要至少 3 個 slave 鏈接，且延遲 <=10 秒的配置： #設置 0 爲禁用
min-slaves-max-lag 10	指定網絡延遲的最大值

上面所列參數，雖然對本文涉及的內容一 一不大，但對運維和調優卻很是重要。

4.配置星型模型主備模式

#爲了區分，有的不須要指定，我也進行了修改。

#主(Master)節點,開啓AOF,禁用RDB
port 6379
pidfile /var/run/redis_6379.pid
logfile "redis6379.log"
save 900 1
save 300 10
save 60 10000
save ""
dbfilename dump6379.rdb

appendonly yes
appendfilename "appendonly6379.aof"

------------------------------------------------
#備(Slaver1)節點,開啓RDB,禁用AOF
port 6380
pidfile /var/run/redis_6380.pid
save 900 1
save 300 10
save 60 10000
dbfilename dump6380.rdb
logfile "redis6380.log"
appendonly no
appendfilename "appendonly6380.aof"
slaveof 127.0.0.1 6379
----------------------------------------------------
#備(Slaver2)節點,禁用RDB,禁用AOF
port 6381
pidfile /var/run/redis_6381.pid
logfile "redis6381.log"
save 900 1
save 300 10
save 60 10000
save ""
dbfilename dump6381.rdb
appendonly no
appendfilename "appendonly6381.aof"
slaveof 127.0.0.1 6379

#配置完了三個配置文件，啓動
[root@hadoop2 redis]# bin/redis-server  redis.conf 
[root@hadoop2 redis]# bin/redis-server  redis6380.conf 
[root@hadoop2 redis]# bin/redis-server  redis6381.conf

查看Master(6379)日誌

[root@hadoop2 redis]# cat redis6381.log
2925:M 03 Sep 20:53:44.398 * The server is now ready to accept connections on port 6379
2925:M 03 Sep 20:53:55.042 * Slave 127.0.0.1:6380 asks for synchronization
2925:M 03 Sep 20:53:55.042 * Full resync requested by slave 127.0.0.1:6380
2925:M 03 Sep 20:53:55.042 * Starting BGSAVE for SYNC with target: disk
2925:M 03 Sep 20:53:55.043 * Background saving started by pid 2933
2933:C 03 Sep 20:53:55.055 * DB saved on disk
2933:C 03 Sep 20:53:55.055 * RDB: 0 MB of memory used by copy-on-write
2925:M 03 Sep 20:53:55.106 * Background saving terminated with success
2925:M 03 Sep 20:53:55.106 * Synchronization with slave 127.0.0.1:6380 succeeded
2925:M 03 Sep 20:53:57.772 * Slave 127.0.0.1:6381 asks for synchronization
2925:M 03 Sep 20:53:57.772 * Full resync requested by slave 127.0.0.1:6381
2925:M 03 Sep 20:53:57.772 * Starting BGSAVE for SYNC with target: disk
2925:M 03 Sep 20:53:57.772 * Background saving started by pid 2938
2938:C 03 Sep 20:53:57.784 * DB saved on disk
2938:C 03 Sep 20:53:57.785 * RDB: 0 MB of memory used by copy-on-write
2925:M 03 Sep 20:53:57.833 * Background saving terminated with success
2925:M 03 Sep 20:53:57.833 * Synchronization with slave 127.0.0.1:6381 succeeded

查看Slave1(6380)日誌

[root@hadoop2 redis]# cat redis6380.log
2930:S 03 Sep 20:53:55.041 * The server is now ready to accept connections on port 6380
2930:S 03 Sep 20:53:55.041 * Connecting to MASTER 127.0.0.1:6379
2930:S 03 Sep 20:53:55.042 * MASTER <-> SLAVE sync started
2930:S 03 Sep 20:53:55.042 * Non blocking connect for SYNC fired the event.
2930:S 03 Sep 20:53:55.042 * Master replied to PING, replication can continue...
2930:S 03 Sep 20:53:55.042 * Partial resynchronization not possible (no cached master)
2930:S 03 Sep 20:53:55.043 * Full resync from master: e82c16f8f2b7e139bcaf8b690d389d6cc4ddd972:1
2930:S 03 Sep 20:53:55.106 * MASTER <-> SLAVE sync: receiving 76 bytes from master
2930:S 03 Sep 20:53:55.107 * MASTER <-> SLAVE sync: Flushing old data
2930:S 03 Sep 20:53:55.107 * MASTER <-> SLAVE sync: Loading DB in memory
2930:S 03 Sep 20:53:55.107 * MASTER <-> SLAVE sync: Finished with success

查看Slave2(6381)日誌

[root@hadoop2 redis]# cat redis6381.log

2935:S 03 Sep 20:53:57.771 * The server is now ready to accept connections on port 6381
2935:S 03 Sep 20:53:57.771 * Connecting to MASTER 127.0.0.1:6379
2935:S 03 Sep 20:53:57.771 * MASTER <-> SLAVE sync started
2935:S 03 Sep 20:53:57.771 * Non blocking connect for SYNC fired the event.
2935:S 03 Sep 20:53:57.771 * Master replied to PING, replication can continue...
2935:S 03 Sep 20:53:57.771 * Partial resynchronization not possible (no cached master)
2935:S 03 Sep 20:53:57.772 * Full resync from master: e82c16f8f2b7e139bcaf8b690d389d6cc4ddd972:1
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: receiving 76 bytes from master
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: Flushing old data
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: Loading DB in memory
2935:S 03 Sep 20:53:57.834 * MASTER <-> SLAVE sync: Finished with success
[root@hadoop2 redis]# cat redis6382.log

經過查看日誌，能夠很形象的學習底層實現過程。

測試（經過複製，修改值確認是否同步）

[root@hadoop2 redis]# bin/redis-cli -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set title "replaction"
OK
127.0.0.1:6379> exit

[root@hadoop2 redis]# bin/redis-cli -p 6380
127.0.0.1:6380> keys *
1) "title"
127.0.0.1:6380> get title
"replaction"

[root@hadoop2 redis]# bin/redis-cli  -p 6381
127.0.0.1:6381> keys *
1) "title"
127.0.0.1:6381> get title
"replaction"
127.0.0.1:6381> set title 111
(error) READONLY You can't write against a read only slave.

修改下值
127.0.0.1:6379> set title "replaction 1"
OK
127.0.0.1:6380> get title
"replaction 1"
127.0.0.1:6381> get title
"replaction 1"

驗證經過

5.配置有向無歡模型主備模式

基本上和星型模型主備模式，沒有差異。

變動點
#備(Slaver2)節點,禁用RDB,禁用AOF
slaveof 127.0.0.1 6379 改成 slaveof 127.0.0.1 6380

測試略

參考資源

http://my.oschina.net/andylucc/blog/683631