溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
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負責讀。
通過復制，可以達成以下目標
1、高可用性(如果master宕機，slave可以介入并取代master的位置)
2、高性能(主備分離，分擔master壓力)
3、水平擴展性(按二八定律，增加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
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
