jinfeng_wang

下面介紹Redis的集群方案。

Replication（主從復(fù)制）

Redis的replication機制允許slave從master那里通過網(wǎng)絡(luò)傳輸拷貝到完整的數(shù)據(jù)備份，從而達到主從機制。為了實現(xiàn)主從復(fù)制，我們準(zhǔn)備三個redis服務(wù)，依次命名為master，slave1，slave2。

配置主服務(wù)器

為了測試效果，我們先修改主服務(wù)器的配置文件redis.conf的端口信息

port 6300

配置從服務(wù)器

replication相關(guān)的配置比較簡單，只需要把下面一行加到slave的配置文件中。你只需要把ip地址和端口號改一下。

slaveof 192.168.1.1 6379

我們先修改從服務(wù)器1的配置文件redis.conf的端口信息和從服務(wù)器配置。

port 6301
slaveof 127.0.0.1 6300

我們再修改從服務(wù)器2的配置文件redis.conf的端口信息和從服務(wù)器配置。

port 6302
slaveof 127.0.0.1 6300

值得注意的是，從redis2.6版本開始，slave支持只讀模式，而且是默認(rèn)的?？梢酝ㄟ^配置項slave-read-only來進行配置。
此外，如果master通過requirepass配置項設(shè)置了密碼，slave每次同步操作都需要驗證密碼，可以通過在slave的配置文件中添加以下配置項

masterauth <password>

測試

分別啟動主服務(wù)器，從服務(wù)器，我們來驗證下主從復(fù)制。我們在主服務(wù)器寫入一條消息，然后再其他從服務(wù)器查看是否成功復(fù)制了。

Sentinel（哨兵）

主從機制，上面的方案中主服務(wù)器可能存在單點故障，萬一主服務(wù)器宕機，這是個麻煩事情，所以Redis提供了Redis-Sentinel，以此來實現(xiàn)主從切換的功能，類似與zookeeper。

Redis-Sentinel是Redis官方推薦的高可用性(HA)解決方案，當(dāng)用Redis做master-slave的高可用方案時，假如master宕機了，Redis本身(包括它的很多客戶端)都沒有實現(xiàn)自動進行主備切換，而Redis-Sentinel本身也是一個獨立運行的進程，它能監(jiān)控多個master-slave集群，發(fā)現(xiàn)master宕機后能進行自動切換。

它的主要功能有以下幾點

• 監(jiān)控（Monitoring）：不斷地檢查redis的主服務(wù)器和從服務(wù)器是否運作正常。
• 提醒（Notification）：如果發(fā)現(xiàn)某個redis服務(wù)器運行出現(xiàn)狀況，可以通過 API 向管理員或者其他應(yīng)用程序發(fā)送通知。
• 自動故障遷移（Automatic failover）：能夠進行自動切換。當(dāng)一個主服務(wù)器不能正常工作時，會將失效主服務(wù)器的其中一個從服務(wù)器升級為新的主服務(wù)器，并讓失效主服務(wù)器的其他從服務(wù)器改為復(fù)制新的主服務(wù)器； 當(dāng)客戶端試圖連接失效的主服務(wù)器時， 集群也會向客戶端返回新主服務(wù)器的地址， 使得集群可以使用新主服務(wù)器代替失效服務(wù)器。

Redis Sentinel 兼容 Redis 2.4.16 或以上版本， 推薦使用 Redis 2.8.0 或以上的版本。

配置Sentinel

必須指定一個sentinel的配置文件sentinel.conf，如果不指定將無法啟動sentinel。首先，我們先創(chuàng)建一個配置文件sentinel.conf

port 26379
sentinel monitor mymaster 127.0.0.1 6300 2

官方典型的配置如下

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
 
sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

配置文件只需要配置master的信息就好啦，不用配置slave的信息，因為slave能夠被自動檢測到(master節(jié)點會有關(guān)于slave的消息)。

需要注意的是，配置文件在sentinel運行期間是會被動態(tài)修改的，例如當(dāng)發(fā)生主備切換時候，配置文件中的master會被修改為另外一個slave。這樣，之后sentinel如果重啟時，就可以根據(jù)這個配置來恢復(fù)其之前所監(jiān)控的redis集群的狀態(tài)。

接下來我們將一行一行地解釋上面的配置項：

sentinel monitor mymaster 127.0.0.1 6379 2

這行配置指示 Sentinel 去監(jiān)視一個名為 mymaster 的主服務(wù)器， 這個主服務(wù)器的 IP 地址為 127.0.0.1 ， 端口號為 6300， 而將這個主服務(wù)器判斷為失效至少需要 2 個 Sentinel 同意，只要同意 Sentinel 的數(shù)量不達標(biāo)，自動故障遷移就不會執(zhí)行。

不過要注意， 無論你設(shè)置要多少個 Sentinel 同意才能判斷一個服務(wù)器失效， 一個 Sentinel 都需要獲得系統(tǒng)中多數(shù)（majority） Sentinel 的支持， 才能發(fā)起一次自動故障遷移， 并預(yù)留一個給定的配置紀(jì)元 （configuration Epoch ，一個配置紀(jì)元就是一個新主服務(wù)器配置的版本號）。換句話說， 在只有少數(shù)（minority） Sentinel 進程正常運作的情況下， Sentinel 是不能執(zhí)行自動故障遷移的。sentinel集群中各個sentinel也有互相通信，通過gossip協(xié)議。

除了第一行配置，我們發(fā)現(xiàn)剩下的配置都有一個統(tǒng)一的格式:

sentinel <option_name> <master_name> <option_value>

接下來我們根據(jù)上面格式中的option_name一個一個來解釋這些配置項：

• down-after-milliseconds 選項指定了 Sentinel 認(rèn)為服務(wù)器已經(jīng)斷線所需的毫秒數(shù)。
• parallel-syncs 選項指定了在執(zhí)行故障轉(zhuǎn)移時， 最多可以有多少個從服務(wù)器同時對新的主服務(wù)器進行同步， 這個數(shù)字越小， 完成故障轉(zhuǎn)移所需的時間就越長。

啟動 Sentinel

對于 redis-sentinel 程序， 你可以用以下命令來啟動 Sentinel 系統(tǒng)

redis-sentinel sentinel.conf

對于 redis-server 程序， 你可以用以下命令來啟動一個運行在 Sentinel 模式下的 Redis 服務(wù)器

redis-server sentinel.conf --sentinel

以上兩種方式，都必須指定一個sentinel的配置文件sentinel.conf， 如果不指定將無法啟動sentinel。sentinel默認(rèn)監(jiān)聽26379端口，所以運行前必須確定該端口沒有被別的進程占用。

測試

此時，我們開啟兩個Sentinel，關(guān)閉主服務(wù)器，我們來驗證下Sentinel。發(fā)現(xiàn)，服務(wù)器發(fā)生切換了。

當(dāng)6300端口的這個服務(wù)重啟的時候，他會變成6301端口服務(wù)的slave。

Twemproxy

Twemproxy是由Twitter開源的Redis代理， Redis客戶端把請求發(fā)送到Twemproxy，Twemproxy根據(jù)路由規(guī)則發(fā)送到正確的Redis實例，最后Twemproxy把結(jié)果匯集返回給客戶端。

Twemproxy通過引入一個代理層，將多個Redis實例進行統(tǒng)一管理，使Redis客戶端只需要在Twemproxy上進行操作，而不需要關(guān)心后面有多少個Redis實例，從而實現(xiàn)了Redis集群。

Twemproxy本身也是單點，需要用Keepalived做高可用方案。

這么些年來，Twenproxy作為應(yīng)用范圍最廣、穩(wěn)定性最高、最久經(jīng)考驗的分布式中間件，在業(yè)界廣泛使用。

但是，Twemproxy存在諸多不方便之處，最主要的是，Twemproxy無法平滑地增加Redis實例，業(yè)務(wù)量突增，需增加Redis服務(wù)器；業(yè)務(wù)量萎縮，需要減少Redis服務(wù)器。但對Twemproxy而言，基本上都很難操作。其次，沒有友好的監(jiān)控管理后臺界面，不利于運維監(jiān)控。

Codis

Codis解決了Twemproxy的這兩大痛點，由豌豆莢于2014年11月開源，基于Go和C開發(fā)、現(xiàn)已廣泛用于豌豆莢的各種Redis業(yè)務(wù)場景。

Codis 3.x 由以下組件組成：

• Codis Server：基于 redis-2.8.21 分支開發(fā)。增加了額外的數(shù)據(jù)結(jié)構(gòu)，以支持 slot 有關(guān)的操作以及數(shù)據(jù)遷移指令。具體的修改可以參考文檔 redis 的修改。
• Codis Proxy：客戶端連接的 Redis 代理服務(wù), 實現(xiàn)了 Redis 協(xié)議。 除部分命令不支持以外(不支持的命令列表)，表現(xiàn)的和原生的 Redis 沒有區(qū)別（就像 Twemproxy）。對于同一個業(yè)務(wù)集群而言，可以同時部署多個 codis-proxy 實例；不同 codis-proxy 之間由 codis-dashboard 保證狀態(tài)同步。
• Codis Dashboard：集群管理工具，支持 codis-proxy、codis-server 的添加、刪除，以及據(jù)遷移等操作。在集群狀態(tài)發(fā)生改變時，codis-dashboard 維護集群下所有 codis-proxy 的狀態(tài)的一致性。對于同一個業(yè)務(wù)集群而言，同一個時刻 codis-dashboard 只能有 0個或者1個；所有對集群的修改都必須通過 codis-dashboard 完成。
• Codis Admin：集群管理的命令行工具?？捎糜诳刂?codis-proxy、codis-dashboard 狀態(tài)以及訪問外部存儲。
• Codis FE：集群管理界面。多個集群實例共享可以共享同一個前端展示頁面；通過配置文件管理后端 codis-dashboard 列表，配置文件可自動更新。
• Codis HA：為集群提供高可用。依賴 codis-dashboard 實例，自動抓取集群各個組件的狀態(tài)；會根據(jù)當(dāng)前集群狀態(tài)自動生成主從切換策略，并在需要時通過 codis-dashboard 完成主從切換。
• Storage：為集群狀態(tài)提供外部存儲。提供 Namespace 概念，不同集群的會按照不同 product name 進行組織；目前僅提供了 Zookeeper 和 Etcd 兩種實現(xiàn)，但是提供了抽象的 interface 可自行擴展。
  

Codis引入了Group的概念，每個Group包括1個Redis Master及一個或多個Redis Slave，這是和Twemproxy的區(qū)別之一，實現(xiàn)了Redis集群的高可用。當(dāng)1個Redis Master掛掉時，Codis不會自動把一個Slave提升為Master，這涉及數(shù)據(jù)的一致性問題，Redis本身的數(shù)據(jù)同步是采用主從異步復(fù)制，當(dāng)數(shù)據(jù)在Maste寫入成功時，Slave是否已讀入這個數(shù)據(jù)是沒法保證的，需要管理員在管理界面上手動把Slave提升為Master。

Codis使用，可以參考官方文檔https://github.com/CodisLabs/codis/blob/release3.0/doc/tutorial_zh.md

Redis 3.0集群

Redis 3.0集群采用了P2P的模式，完全去中心化。支持多節(jié)點數(shù)據(jù)集自動分片，提供一定程度的分區(qū)可用性，部分節(jié)點掛掉或者無法連接其他節(jié)點后，服務(wù)可以正常運行。Redis 3.0集群采用Hash Slot方案，而不是一致性哈希。Redis把所有的Key分成了16384個slot，每個Redis實例負(fù)責(zé)其中一部分slot。集群中的所有信息（節(jié)點、端口、slot等），都通過節(jié)點之間定期的數(shù)據(jù)交換而更新。

Redis客戶端在任意一個Redis實例發(fā)出請求，如果所需數(shù)據(jù)不在該實例中，通過重定向命令引導(dǎo)客戶端訪問所需的實例。

Redis 3.0集群，目前支持的cluster特性

• 節(jié)點自動發(fā)現(xiàn)
• slave->master 選舉,集群容錯
• Hot resharding:在線分片
• 集群管理:cluster xxx
• 基于配置(nodes-port.conf)的集群管理
• ASK 轉(zhuǎn)向/MOVED 轉(zhuǎn)向機制
  

如上圖所示，所有的redis節(jié)點彼此互聯(lián)(PING-PONG機制),內(nèi)部使用二進制協(xié)議優(yōu)化傳輸速度和帶寬。節(jié)點的fail是通過集群中超過半數(shù)的節(jié)點檢測失效時才生效?？蛻舳伺credis節(jié)點直連，不需要中間proxy層。客戶端不需要連接集群所有節(jié)點，連接集群中任何一個可用節(jié)點即可。redis-cluster把所有的物理節(jié)點映射到[0-16383]slot上cluster負(fù)責(zé)維護node<->slot<->value。

選舉過程是集群中所有master參與，如果半數(shù)以上master節(jié)點與master節(jié)點通信超時，認(rèn)為當(dāng)前master節(jié)點掛掉。

當(dāng)集群不可用時，所有對集群的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)錯誤。如果集群任意master掛掉，且當(dāng)前master沒有slave，集群進入fail狀態(tài)，也可以理解成進群的slot映射[0-16383]不完成時進入fail狀態(tài)。如果進群超過半數(shù)以上master掛掉，無論是否有slave集群進入fail狀態(tài)。

環(huán)境搭建

現(xiàn)在，我們進行集群環(huán)境搭建。集群環(huán)境至少需要3個主服務(wù)器節(jié)點。本次測試，使用另外3個節(jié)點作為從服務(wù)器的節(jié)點，即3個主服務(wù)器，3個從服務(wù)器。

修改配置文件，其它的保持默認(rèn)即可。

# 根據(jù)實際情況修改
port 7000 
# 允許redis支持集群模式
cluster-enabled yes  
# 節(jié)點配置文件，由redis自動維護
cluster-config-file nodes.conf      
# 節(jié)點超時毫秒
cluster-node-timeout 5000 
# 開啟AOF同步模式
appendonly yes

創(chuàng)建集群

目前這些實例雖然都開啟了cluster模式，但是彼此還不認(rèn)識對方，接下來可以通過Redis集群的命令行工具redis-trib.rb來完成集群創(chuàng)建。
首先，下載 https://raw.githubusercontent.com/antirez/redis/unstable/src/redis-trib.rb。

然后，搭建Redis 的 Ruby 支持環(huán)境。這里，不進行擴展，參考相關(guān)文檔。

現(xiàn)在，接下來運行以下命令。這個命令在這里用于創(chuàng)建一個新的集群, 選項–replicas 1 表示我們希望為集群中的每個主節(jié)點創(chuàng)建一個從節(jié)點。

redis-trib.rb create --replicas 1 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006

5.3、測試