Redis 作為一個(gè)使用場(chǎng)景很高的 NoSQL 數據庫，支持了較為豐富的數據類(lèi)型，相比于其他關(guān)系型數據庫在性能方面優(yōu)勢明顯?；ヂ?lián)網(wǎng)公司通常更加傾向于將一些熱點(diǎn)數據放入Redis中來(lái)承載高吞吐量的訪(fǎng)問(wèn)。
單機Redis在普通的服務(wù)器上通常ops上限在5w左右，開(kāi)啟pipeline的情況下在20-30w左右。對于大多數中小公司來(lái)說(shuō)，通常單機的Redis已經(jīng)足夠，最多根據不同業(yè)務(wù)分散到多臺Redis。
為什么需要集群
Redis單線(xiàn)程特性，多請求順序執行，單個(gè)耗時(shí)的操作會(huì )阻塞后續的操作
單機內存有限
某些特殊業(yè)務(wù)，帶寬壓力較大
單點(diǎn)問(wèn)題，缺乏高可用性
不能動(dòng)態(tài)擴容
Redis集群的目標就是為了實(shí)現高可用性，避免性能瓶頸，可動(dòng)態(tài)擴容，易于做監控告警。
下面介紹Redis的幾種主流的集群解決方案。
通常需要 smart-client 支持，在業(yè)務(wù)程序端根據預先設置的路由規則進(jìn)行分片，從而實(shí)現對多個(gè)redis實(shí)例的分布式訪(fǎng)問(wèn)。
圖1 客戶(hù)端分片的模式
鑒于redis本身的高性能，并且有一些設計良好的第三方庫，例如java開(kāi)發(fā)者可以使用jedis，所以很多小公司使用此方案。
優(yōu)點(diǎn)： 相比于使用代理，減少了一層網(wǎng)絡(luò )傳輸的消耗，效率較高。
缺點(diǎn)： 當redis實(shí)例需要擴容或切換的情況下，需要修改業(yè)務(wù)端的程序，較為麻煩。并且需 要維護各個(gè)語(yǔ)言的客戶(hù)端版本，如果要升級客戶(hù)端成本也會(huì )比較高。出現故障時(shí)難以及時(shí)定位問(wèn)題。（有些smart-client借助于zookeeper維護客戶(hù)端訪(fǎng)問(wèn)redis實(shí)例的一致性）
通過(guò)統一的代理程序訪(fǎng)問(wèn)多個(gè)redis實(shí)例，比如業(yè)內曾廣泛使用的 twemproxy 以及豌豆莢開(kāi)源的 codis。(twemproxy是twitter開(kāi)源的一個(gè)redis和memcache代理服務(wù)器，只用于作為簡(jiǎn)單的代理中間件，目前twitter內部已經(jīng)不再使用）
優(yōu)點(diǎn)： 業(yè)務(wù)程序端只需要使用普通的api去訪(fǎng)問(wèn)代理程序即可。各種組件分離，以后升級較為容易。也避免了客戶(hù)端需要維持和每個(gè)redis實(shí)例的長(cháng)連接導致連接數過(guò)多。
缺點(diǎn)： 增加了一層中間件，增加了網(wǎng)絡(luò )和數據處理的消耗，性能下降。
Twemproxy是由Twitter開(kāi)源的Redis代理，其基本原理是：Redis客戶(hù)端把請求發(fā)送到Twemproxy，Twemproxy根據路由規則發(fā)送到正確的Redis實(shí)例，最后Twemproxy把結果匯集返回給客戶(hù)端。
Twemproxy通過(guò)引入一個(gè)代理層，將多個(gè)Redis實(shí)例進(jìn)行統一管理，使Redis客戶(hù)端只需要在Twemproxy上進(jìn)行操作，而不需要關(guān)心后面有多少個(gè)Redis實(shí)例，從而實(shí)現了Redis集群。
Twemproxy集群架構如圖2所示。
圖2 Twemproxy集群架構
Twemproxy的優(yōu)點(diǎn)如下。
客戶(hù)端像連接Redis實(shí)例一樣連接Twemproxy，不需要改任何的代碼邏輯。
支持無(wú)效Redis實(shí)例的自動(dòng)刪除。
Twemproxy與Redis實(shí)例保持連接，減少了客戶(hù)端與Redis實(shí)例的連接數。
Twemproxy有如下不足。
由于Redis客戶(hù)端的每個(gè)請求都經(jīng)過(guò)Twemproxy代理才能到達Redis服務(wù)器，這個(gè)過(guò)程中會(huì )產(chǎn)生性能損失。
沒(méi)有友好的監控管理后臺界面，不利于運維監控。
最大的問(wèn)題是Twemproxy無(wú)法平滑地增加Redis實(shí)例。對于運維人員來(lái)說(shuō)，當因為業(yè)務(wù)需要增加Redis實(shí)例時(shí)工作量非常大。
Twemproxy作為最被廣泛使用、最久經(jīng)考驗、穩定性最高的Redis代理，在業(yè)界被廣泛使用。
Twemproxy不能平滑增加Redis實(shí)例的問(wèn)題帶來(lái)了很大的不便，于是豌豆莢自主研發(fā)了Codis，一個(gè)支持平滑增加Redis實(shí)例的Redis代理軟件，其基于Go和C語(yǔ)言開(kāi)發(fā)，并于2014年11月在GitHub上開(kāi)源。
Codis包含下面4個(gè)部分。
Codis Proxy：Redis客戶(hù)端連接到Redis實(shí)例的代理，實(shí)現了Redis的協(xié)議，Redis客戶(hù)端連接到Codis Proxy進(jìn)行各種操作。Codis Proxy是無(wú)狀態(tài)的，可以用Keepalived等負載均衡軟件部署多個(gè)Codis Proxy實(shí)現高可用。
CodisRedis：Codis項目維護的Redis分支，添加了slot和原子的數據遷移命令。Codis上層的 Codis Proxy和Codisconfig只有與這個(gè)版本的Redis通信才能正常運行。
Codisconfig：Codis管理工具?？梢詧绦刑砑觿h除CodisRedis節點(diǎn)、添加刪除Codis Proxy、數據遷移等操作。另外，Codisconfig自帶了HTTP server，里面集成了一個(gè)管理界面，方便運維人員觀(guān)察Codis集群的狀態(tài)和進(jìn)行相關(guān)的操作，極大提高了運維的方便性，彌補了Twemproxy的缺點(diǎn)。
ZooKeeper：分布式的、開(kāi)源的應用程序協(xié)調服務(wù)，是Hadoop和Hbase的重要組件，其為分布式應用提供一致性服務(wù)，提供的功能包括：配置維護、名字服務(wù)、分布式同步、組服務(wù)等。Codis依賴(lài)于ZooKeeper存儲數據路由表的信息和Codis Proxy節點(diǎn)的元信息。另外，Codisconfig發(fā)起的命令都會(huì )通過(guò)ZooKeeper同步到CodisProxy的節點(diǎn)。
Codis的架構如圖3所示
在圖3的Codis的架構圖中，Codis引入了Redis Server Group，其通過(guò)指定一個(gè)主CodisRedis和一個(gè)或多個(gè)從CodisRedis，實(shí)現了Redis集群的高可用。當一個(gè)主CodisRedis掛掉時(shí)，Codis不會(huì )自動(dòng)把一個(gè)從CodisRedis提升為主CodisRedis，這涉及數據的一致性問(wèn)題（Redis本身的數據同步是采用主從異步復制，當數據在主CodisRedis寫(xiě)入成功時(shí)，從CodisRedis是否已讀入這個(gè)數據是沒(méi)法保證的），需要管理員在管理界面上手動(dòng)把從CodisRedis提升為主CodisRedis。
如果覺(jué)得麻煩，豌豆莢也提供了一個(gè)工具Codis-ha，這個(gè)工具會(huì )在檢測到主CodisRedis掛掉的時(shí)候將其下線(xiàn)并提升一個(gè)從CodisRedis為主CodisRedis。
Codis中采用預分片的形式，啟動(dòng)的時(shí)候就創(chuàng )建了1024個(gè)slot，1個(gè)slot相當于1個(gè)箱子，每個(gè)箱子有固定的編號，范圍是1~1024。slot這個(gè)箱子用作存放Key，至于Key存放到哪個(gè)箱子，可以通過(guò)算法“crc32(key)%1024”獲得一個(gè)數字，這個(gè)數字的范圍一定是1~1024之間，Key就放到這個(gè)數字對應的slot。例如，如果某個(gè)Key通過(guò)算法“crc32(key)%1024”得到的數字是5，就放到編碼為5的slot（箱子）。1個(gè)slot只能放1個(gè)Redis Server Group，不能把1個(gè)slot放到多個(gè)Redis Server Group中。1個(gè)Redis Server Group最少可以存放1個(gè)slot，最大可以存放1024個(gè)slot。因此，Codis中最多可以指定1024個(gè)Redis Server Group。
Codis最大的優(yōu)勢在于支持平滑增加（減少）Redis Server Group（Redis實(shí)例），能安全、透明地遷移數據，這也是Codis 有別于Twemproxy等靜態(tài)分布式 Redis 解決方案的地方。Codis增加了Redis Server Group后，就牽涉到slot的遷移問(wèn)題。例如，系統有兩個(gè)Redis Server Group，Redis Server Group和slot的對應關(guān)系如下。
當增加了一個(gè)Redis Server Group，slot就要重新分配了。Codis分配slot有兩種方法。
第一種：通過(guò)Codis管理工具Codisconfig手動(dòng)重新分配，指定每個(gè)Redis Server Group所對應的slot的范圍，例如可以指定Redis Server Group和slot的新的對應關(guān)系如下。
第二種：通過(guò)Codis管理工具Codisconfig的rebalance功能，會(huì )自動(dòng)根據每個(gè)Redis Server Group的內存對slot進(jìn)行遷移，以實(shí)現數據的均衡。
Redis3.0之后的版本開(kāi)始正式支持 redis cluster，核心目標是：
性能：Redis作者比較看重性能，增加集群不能對性能有較大影響，所以Redis采用了P2P而非Proxy方式、異步復制、客戶(hù)端重定向等設計，而犧牲了部分的一致性、使用性。
水平擴展：官方文檔中稱(chēng)目標是能線(xiàn)性擴展到1000結點(diǎn)。
可用性：集群具有了以前Sentinel的監控和自動(dòng)Failover能力。
數據分布：預分片
圖4 Redis 3.0集群的預分片圖
預先分配好 16384 個(gè)slot
slot 和 server 的映射關(guān)系存儲每一個(gè) server 的路由表中
根據 CRC16(key) mod 16384 的值，決定將一個(gè)key放到哪一個(gè)slot中
數據遷移時(shí)就是調整 slot 的分布
架構：去中心化
圖5 Redis 3.0集群的去中心化示意圖
無(wú)中心結構，每個(gè)節點(diǎn)都保存數據和整個(gè)集群的狀態(tài)。
采用 gossip 協(xié)議傳播信息以及發(fā)現新節點(diǎn)（最終一致性）。
每個(gè)節點(diǎn)都和其他所有節點(diǎn)連接，并保持活躍。
PING/PONG：心跳，附加上自己以及一些其他節點(diǎn)數據，每個(gè)節點(diǎn)每秒隨機PING幾個(gè)節點(diǎn)。會(huì )選擇那些超過(guò)cluster-node-timeout一半的時(shí)間還未PING過(guò)或未收到PONG的節點(diǎn)。
UPDATE消息：計數戳，如果收到server的計數為3，自己的為4，則發(fā)UPDATE更新對方路由表，反之更新自己的路由表，最終集群路由狀態(tài)會(huì )和計數戳最大的實(shí)例一樣。
如果 cluster-node-timeout 設置較小，或者節點(diǎn)較多，數據傳輸量將比較可觀(guān)。
Broadcast：有狀態(tài)變動(dòng)時(shí)先broadcast，后PING； 發(fā)布/訂閱。
Redis node 不作為client請求的代理（不轉發(fā)請求），client根據node返回的錯誤信息重定向請求?（需要 smart-client 支持），所以client連接集群中任意一個(gè)節點(diǎn)都可以。
可用性：Master-Slave
每個(gè)Redis Node可以有一個(gè)或者多個(gè)Slave，當Master掛掉時(shí)，選舉一個(gè)Slave形成新的Master。
Master Slave 之間異步復制（可能會(huì )丟數據）。
采用 gossip 協(xié)議探測其他節點(diǎn)存活狀態(tài)，超過(guò) cluster-node-timeout，標記為 PFAIL，PING中附加此數據。當 Node A發(fā)現半數以上master將失效節點(diǎn)標記為PFAIL，將其標記為FAIL，broadcast FAIL。
各 slave 等待一個(gè)隨機時(shí)間后 發(fā)起選舉，向其他 master broadcast，半數以上同意則贏(yíng)得選舉否則發(fā)起下一次選舉
當 slave 成為 master，先broadcast，后持續PING，最終集群實(shí)例都獲知此消息
Redis 3.0集群采用了P2P的模式，完全去中心化。Redis把所有的Key分成了16384個(gè)slot，每個(gè)Redis實(shí)例負責其中一部分slot。集群中的所有信息（節點(diǎn)、端口、slot等），都通過(guò)節點(diǎn)之間定期的數據交換而更新。
Redis客戶(hù)端在任意一個(gè)Redis實(shí)例發(fā)出請求，如果所需數據不在該實(shí)例中，通過(guò)重定向命令引導客戶(hù)端訪(fǎng)問(wèn)所需的實(shí)例。
Redis 3.0集群的工作流程如圖6所示。
圖6 Redis 3.0集群的工作流程圖
如圖6所示Redis集群內的機器定期交換數據，工作流程如下。
(1)Redis客戶(hù)端在Redis2實(shí)例上訪(fǎng)問(wèn)某個(gè)數據。
(2)在Redis2內發(fā)現這個(gè)數據是在Redis3這個(gè)實(shí)例中，給Redis客戶(hù)端發(fā)送一個(gè)重定向的命令。
(3)Redis客戶(hù)端收到重定向命令后，訪(fǎng)問(wèn)Redis3實(shí)例獲取所需的數據。
Redis 3.0的集群方案有以下幾個(gè)問(wèn)題。
一個(gè)Redis實(shí)例具備了“數據存儲”和“路由重定向”，完全去中心化的設計。這帶來(lái)的好處是部署非常簡(jiǎn)單，直接部署Redis就行，不像Codis有那么多的組件和依賴(lài)。但帶來(lái)的問(wèn)題是很難對業(yè)務(wù)進(jìn)行無(wú)痛的升級，如果哪天Redis集群出了什么嚴重的Bug，就只能回滾整個(gè)Redis集群。
對協(xié)議進(jìn)行了較大的修改，對應的Redis客戶(hù)端也需要升級。升級Redis客戶(hù)端后誰(shuí)能確保沒(méi)有Bug？而且對于線(xiàn)上已經(jīng)大規模運行的業(yè)務(wù)，升級代碼中的Redis客戶(hù)端也是一個(gè)很麻煩的事情。
Gossip協(xié)議通信開(kāi)銷(xiāo)
嚴重依賴(lài)于smart-client的成熟度
如果smart-client支持緩存slot路由，需要額外占用內存空間，為了效率需要建立和所有 redis server 的長(cháng)連接（每一個(gè)使用該庫的程序都需要建立這么多連接）。
如果不支持緩存路由信息，會(huì )先訪(fǎng)問(wèn)任意一臺 redis server，之后重定向到新的節點(diǎn)。
需要更新當前所有的client。
官方只提供了一個(gè)ruby程序 redis-trib 完成集群的所有操作，缺乏監控管理工具，很難清楚目前集群的狀態(tài)
數據遷移以Key為單位，速度較慢
某些操作不支持，MultiOp和Pipeline都被限定在命令中的所有Key必須都在同一Slot內
綜合上面所述的幾個(gè)問(wèn)題，Redis 3.0集群在業(yè)界并沒(méi)有被大規模使用。
國內的云服務(wù)器提供商阿里云、UCloud等均推出了基于Redis的云存儲服務(wù)。
這個(gè)服務(wù)的特性如下。
(1)動(dòng)態(tài)擴容
用戶(hù)可以通過(guò)控制面板升級所需的Redis存儲空間，擴容的過(guò)程中服務(wù)部不需要中斷或停止，整個(gè)擴容過(guò)程對用戶(hù)透明、無(wú)感知，這點(diǎn)是非常實(shí)用的，在前面介紹的方案中，解決Redis平滑擴容是個(gè)很煩瑣的任務(wù)，現在按幾下鼠標就能搞定，大大減少了運維的負擔。
(2)數據多備
數據保存在一主一備兩臺機器中，其中一臺機器宕機了，數據還在另外一臺機器上有備份。
(3)自動(dòng)容災
主機宕機后系統能自動(dòng)檢測并切換到備機上，實(shí)現服務(wù)的高可用。
(4)實(shí)惠
很多情況下為了使Redis的性能更高，需要購買(mǎi)一臺專(zhuān)門(mén)的服務(wù)器用于Redis的存儲服務(wù)，但這樣子CPU、內存等資源就浪費了，購買(mǎi)Redis云存儲服務(wù)就很好地解決了這個(gè)問(wèn)題。
有了Redis云存儲服務(wù)，能使App后臺開(kāi)發(fā)人員從煩瑣運維中解放出來(lái)。App后臺要搭建一個(gè)高可用、高性能的Redis服務(wù)，需要投入相當的運維成本和精力。如果使用云存儲服務(wù)，就沒(méi)必要投入這些成本和精力，可以讓App后臺開(kāi)發(fā)人員更專(zhuān)注于業(yè)務(wù)。
來(lái)源：轉自公眾號“運維之美”
新春“開(kāi)工大吉”
GOPS 2019 · 深圳站
傳播先進(jìn)技術(shù)思想和理念，分享業(yè)內最佳實(shí)踐
聯(lián)系客服
