redis演練(6)redis主從模式搭建-創(chuàng)新互聯(lián)

redis是一款面向分布式的Nosql產(chǎn)品，天生對主備模式有很好的支持，而且配置一套完整的主備模式，非常簡單。針對redis，主備模式配置非常簡單，但線上意義重大。

創(chuàng)新互聯(lián)建站堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的奈曼網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

主要內(nèi)容

1.CAP理論

2.簡單redis的復(fù)制原理

3.redis replaction相關(guān)配置參數(shù)解析

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

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

1.研磨redis的復(fù)制與集群概念

redis的復(fù)制與集群，剛開始我把兩者鬧了個誤會，在不斷深入學(xué)習(xí)過程中及時改正了。

簡單區(qū)分一下。

redis復(fù)制：可以理解為把redis服務(wù)copy多份，供客戶端訪問。但服務(wù)器間持有的數(shù)據(jù)時一樣的?？梢灶惐认耾racle的RAC，和mysql數(shù)據(jù)庫中的主備模式。主要解決redis服務(wù)的可靠性，擴(kuò)展性上。

redis集群：集群主要解決大數(shù)據(jù)量問題。一個機(jī)器內(nèi)存和存儲往往是有限的，但數(shù)據(jù)量的增長往往是“無限”的，可以使用集群，將數(shù)據(jù)分散到多個redis服務(wù)中。如果你能想到memcached的一致性哈希算法，那就對了。

不管redis 復(fù)制核集群，都會涉及到節(jié)點信息的同步，不得不要受到CAP理論的影響。

2.CAP理論介紹

CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer's theorem），它指出對于一個分布式計算系統(tǒng)來說，不可能同時滿足以下三點：

• 一致性（Consistence) （等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本）

• 可用性（Availability）（對數(shù)據(jù)更新具備高可用性）

• 容忍網(wǎng)絡(luò)分區(qū)（Partition tolerance）（以實際效果而言，分區(qū)相當(dāng)于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇^[3]。）

根據(jù)定理，分布式系統(tǒng)只能滿足三項中的兩項而不可能滿足全部三項[4]。

redis 的設(shè)計和配置，也是在盡量解決CAP引起的問題，但不可能徹底決絕，只能在三者中進(jìn)行平衡。

3.Redis復(fù)制概論

數(shù)據(jù)庫復(fù)制指的是發(fā)生在不同數(shù)據(jù)庫實例之間，單向的信息傳播的行為，通常由被復(fù)制方和復(fù)制方組成，被復(fù)制方和復(fù)制方之間建立網(wǎng)絡(luò)連接，復(fù)制方式通常為被復(fù)制方主動將數(shù)據(jù)發(fā)送到復(fù)制方，復(fù)制方接收到數(shù)據(jù)存儲在當(dāng)前實例，最終目的是為了保證雙方的數(shù)據(jù)一致、同步。

復(fù)制示意圖

Redis的復(fù)制方式有兩種，一種是主（master）-從（slave）模式，一種是從（slave）-從（slave）模式，因此Redis的復(fù)制拓?fù)鋱D會豐富一些，可以像星型拓?fù)?，也可以像個有向無環(huán)：


Redis集群復(fù)制結(jié)構(gòu)圖
通過配置多個Redis實例獨立運行、定向復(fù)制，形成Redis集群（這兒集群的概念是廣義上的概念），master負(fù)責(zé)寫、slave負(fù)責(zé)讀。

通過復(fù)制，可以達(dá)成以下目標(biāo)

1、高可用性(如果master宕機(jī)，slave可以介入并取代master的位置)
2、高性能(主備分離，分擔(dān)master壓力)
3、水平擴(kuò)展性(按二八定律，增加slave機(jī)器可以橫向（水平）擴(kuò)展Redis服務(wù)的整個查詢服務(wù)的能力)

帶來的問題：

1.同步開銷
2.數(shù)據(jù)不一致性問題
3.編程復(fù)雜

4.redis replaction相關(guān)配置參數(shù)解析

slaveof <masterip> <masterport>	#設(shè)置該數(shù)據(jù)庫為其他數(shù)據(jù)庫的從數(shù)據(jù)庫時啟用該參數(shù)。 #設(shè)置當(dāng)本機(jī)為slave服務(wù)時，設(shè)置 master 服務(wù)的 IP 地址及端口，在 Redis 啟動時，它會自動從 master 進(jìn)行數(shù)據(jù)同步
slave-serve-stale-data yes	#當(dāng)從庫同主機(jī)失去連接或者復(fù)制正在進(jìn)行，從機(jī)庫有兩種運行方式： #1)如果 slave-serve-stale-data 設(shè)置為 yes( 默認(rèn)設(shè)置 ) ，從庫會繼續(xù)響應(yīng)客戶端的請求 #2)如果 slave-serve-stale-data 是指為 no ，出去 INFO 和 SLAVOF 命令之外的任何請求都會返回一個錯誤 "SYNC with master in progress"
slave-read-only yes	#配置 slave 實例是否接受寫。寫 slave 對存儲短暫數(shù)據(jù)（在同 master數(shù)據(jù)同步后可以很容易地被刪除）是有用的，但未配置的情況下，客戶端寫可能會發(fā)送問題。
repl-ping-slave-period 10	#從庫會按照一個時間間隔向主庫發(fā)送 PINGs. 可以通過 repl-ping-slave-period 設(shè)置這個時間間隔，默認(rèn)是 10 秒
repl-timeout 60	#repl-timeout 設(shè)置主庫批量數(shù)據(jù)傳輸時間或者 ping 回復(fù)時間間隔，默認(rèn)值是 60 秒 # 一定要確保 repl-timeout 大于 repl-ping-slave-period
repl-diskless-sync no	啟動無磁盤復(fù)制。往備節(jié)點同步，不需要中間先生成文件再進(jìn)行同步。
repl-diskless-sync-delay 5	同步前的延時, 以等待其他的要鏈接的slave 配置傳輸開始的延遲時間，以便等待更多的從服務(wù)器連接
repl-disable-tcp-nodelay no	#在 slave socket 的 SYNC 后禁用 TCP_NODELAY #如果選擇“ yes ” ,Redis 將使用一個較小的數(shù)字 TCP 數(shù)據(jù)包和更少的帶寬將數(shù)據(jù)發(fā)送到 slave ， 但是這可能導(dǎo)致數(shù)據(jù)發(fā)送到 slave 端會有延遲 , 如果是 Linux kernel 的默認(rèn)配置，會達(dá)到 40 毫秒 . #如果選擇 "no"，則發(fā)送數(shù)據(jù)到 slave 端的延遲會降低，但將使用更多的帶寬用于復(fù)制.
repl-backlog-size 1mb	#設(shè)置復(fù)制的backlog(后臺日志)大小。 #復(fù)制的后臺日志越大， slave 斷開連接及后來可能執(zhí)行部分復(fù)制花的時間就越長。 #后臺日志在至少有一個 slave 連接時，僅僅分配一次。
repl-backlog-ttl 3600	#在 master 不再連接 slave 后，后臺日志將被釋放。下面的配置定義從最后一個 slave 斷開連接后需要釋放的時間（秒）.#0意味著從不釋放后臺日志
slave-priority 100	#如果 master 不能再正常工作，那么會在多個 slave 中，選擇優(yōu)先值最小的一個 slave 提升為 master ，優(yōu)先值為 0 表示不能提升為 master
min-slaves-to-write 0	執(zhí)行寫操作所需的至少從服務(wù)器數(shù)量 #如果少于 N 個 slave 連接，且延遲時間 <=M 秒，則 master 可配置停止接受寫操作。 #例如需要至少 3 個 slave 連接，且延遲 <=10 秒的配置： #設(shè)置 0 為禁用
min-slaves-max-lag 10	指定網(wǎng)絡(luò)延遲的大值

上面所列參數(shù)，雖然對本文涉及的內(nèi)容一 一不大，但對運維和調(diào)優(yōu)卻非常重要。

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

#為了區(qū)分，有的不需要指定，我也進(jìn)行了修改。

#主(Master)節(jié)點,開啟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)節(jié)點,開啟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)節(jié)點,禁用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

通過查看日志，可以很形象的學(xué)習(xí)底層實現(xiàn)過程。

測試（通過復(fù)制，修改值確認(rèn)是否同步）

[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)節(jié)點,禁用RDB,禁用AOF slaveof 127.0.0.1 6379 改為 slaveof 127.0.0.1 6380

測試略

參考資源

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

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

網(wǎng)頁題目：redis演練(6)redis主從模式搭建-創(chuàng)新互聯(lián)
文章轉(zhuǎn)載：http://muchs.cn/article20/ddhdco.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機(jī)、移動網(wǎng)站建設(shè)、微信公眾號、網(wǎng)頁設(shè)計公司、網(wǎng)站內(nèi)鏈、標(biāo)簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)