作者：賁紹華

愛(ài)可生研發(fā)中心工程師，負(fù)責(zé)項(xiàng)目的需求與維護(hù)工作。其他身份：柯基鏟屎官。

本文來(lái)源：原創(chuàng)投稿

*愛(ài)可生開源社區(qū)出品，原創(chuàng)內(nèi)容未經(jīng)授權(quán)不得隨意使用，轉(zhuǎn)載請(qǐng)聯(lián)系小編并注明來(lái)源。

---

一、集群架構(gòu)的一些基本概念

當(dāng)我們只使用一臺(tái) Redis 實(shí)例也就是 Single 架構(gòu)時(shí)，需要考慮一些非常實(shí)際的問(wèn)題，如：單節(jié)點(diǎn)一但宕機(jī)則業(yè)務(wù)停擺、單節(jié)點(diǎn)的容量不可能是無(wú)限制的、性能同樣存在瓶頸等......

集群架構(gòu)模式最主要的三個(gè)目的就是：高可用、提升資源限制瓶頸、提升網(wǎng)絡(luò)吞吐：

1.1 高可用 - Sentinel

Redis Sentinel 是一個(gè)分布式系統(tǒng)， 可以在一個(gè)架構(gòu)中運(yùn)行多個(gè) Sentinel 進(jìn)程（progress）

這些進(jìn)程使用流言協(xié)議（gossip protocols)來(lái)接收關(guān)于主服務(wù)器是否下線的信息， 并使用投票協(xié)議（agreement protocols）來(lái)決定是否執(zhí)行自動(dòng)故障遷移， 以及選擇哪個(gè)從服務(wù)器作為新的主服務(wù)器。

1.2 提升資源限制瓶頸 - 數(shù)據(jù)分區(qū)存儲(chǔ)（Partitioning）

將數(shù)據(jù)通過(guò)對(duì)應(yīng)的算法規(guī)則，自動(dòng)分割數(shù)據(jù)到不同的節(jié)點(diǎn)上，每一個(gè)節(jié)點(diǎn)都是主，都承擔(dān)一部分?jǐn)?shù)據(jù)。

在整個(gè)集群的部分節(jié)點(diǎn)失敗或者不可達(dá)的情況下依然能夠繼續(xù)處理命令。

數(shù)據(jù)的拆分可以依據(jù) AKF 原則根據(jù)不同維度進(jìn)行靈活拆分：

1.3 提高網(wǎng)絡(luò)吞吐

Redis 使用的是 epoll IO 模型，單機(jī)吞吐量也足夠優(yōu)秀，但當(dāng)業(yè)務(wù)流量單一入口不能兜住時(shí)則需要考慮分流策略了。

如：增加 slave 節(jié)點(diǎn)、使用 proxy 作為流量入口、Redis cluster、LVS等

靈活的架構(gòu)能使業(yè)務(wù)側(cè)不需要太關(guān)心具體到哪個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)資源瓶頸如何。均使用統(tǒng)一流量入口即可。

二、客戶端分區(qū)

此處的客戶端指的就是業(yè)務(wù)側(cè)，根據(jù)業(yè)務(wù)類型分類存取，自行維護(hù)一個(gè) key - redis node 的映射關(guān)系或服務(wù)發(fā)現(xiàn)機(jī)制。

簡(jiǎn)單場(chǎng)景下這么做并不會(huì)有什么問(wèn)題，但是也存在一些缺點(diǎn)，如：

• 存取規(guī)則需要統(tǒng)一，需要考慮擴(kuò)縮容時(shí)業(yè)務(wù)邏輯調(diào)整的影響面

• 業(yè)務(wù)其實(shí)并不清楚 Redis 節(jié)點(diǎn)機(jī)器的瓶頸

• 每個(gè)客戶端都需要連接所有的 Redis 節(jié)點(diǎn)

三、代理分區(qū)

Redis 也有一些優(yōu)秀的 proxy ，它們?cè)谧鳛榻y(tǒng)一流量入口的同時(shí)也提供了一些非常實(shí)用的功能，如數(shù)據(jù) sharding 。

根據(jù)一定規(guī)則使對(duì)應(yīng)的 key 落到集群的不同節(jié)點(diǎn)上，下邊簡(jiǎn)單介紹一下常見(jiàn)的 redis proxy 與分片的算法邏輯：

3.1 Modula [ 根據(jù)算法 + 取模存取 ]

通過(guò)算法對(duì)key進(jìn)行取模，決定最終需要在哪個(gè)節(jié)點(diǎn)上進(jìn)行存取。

• 缺點(diǎn)：可能會(huì)出現(xiàn)數(shù)據(jù)分布節(jié)點(diǎn)不均勻的情況，機(jī)器擴(kuò)縮容時(shí)需要調(diào)整取模策略

3.2 Random [ 隨機(jī)存取 ]

作為消息隊(duì)列使用時(shí)候，可以將多個(gè)Redis實(shí)例組成Topic，生產(chǎn)者存入（lpush）數(shù)據(jù)，消費(fèi)者消費(fèi)（rpop）

• 缺點(diǎn)：可能會(huì)出現(xiàn)數(shù)據(jù)分布節(jié)點(diǎn)不均勻的情況

3.3 Ketama [ 一致性哈希 ]

一致哈希算法是對(duì)一組數(shù)進(jìn)行取模運(yùn)算的結(jié)果值組織成一個(gè)圓環(huán)，就像鐘表一樣，它可以被想象成帶有60個(gè)刻度的圓，這個(gè)圓環(huán)被稱為哈希環(huán)。在移除或者添加一個(gè)服務(wù)器時(shí)，能夠盡可能小地改變已存在的服務(wù)請(qǐng)求與處理請(qǐng)求服務(wù)器之間的映射關(guān)系。

一致性哈希解決了簡(jiǎn)單哈希算法在分布式哈希表中存在的動(dòng)態(tài)伸縮等問(wèn)題。

• 優(yōu)點(diǎn)：增加節(jié)點(diǎn)可以分擔(dān)其他節(jié)點(diǎn)存儲(chǔ)壓力，因?yàn)闆](méi)有取模過(guò)程不會(huì)影響其他節(jié)點(diǎn)的存儲(chǔ)策略

• 缺點(diǎn)：新增節(jié)點(diǎn)會(huì)造成一小部分?jǐn)?shù)據(jù)不能命中（此時(shí)應(yīng)再取附近的2個(gè)節(jié)點(diǎn)查看數(shù)據(jù)是否存在）

操作步驟：

規(guī)劃一個(gè)哈希環(huán)，環(huán)上node hash后的槽位為物理節(jié)點(diǎn)，其余為虛擬節(jié)點(diǎn)

將所有物理節(jié)點(diǎn)標(biāo)記起來(lái)

數(shù)據(jù)（key）加進(jìn)來(lái)時(shí)通過(guò)hash過(guò)后查詢?cè)摬畚皇欠駷槲锢砉?jié)點(diǎn)，如果是虛擬節(jié)點(diǎn)，則找尋離它最近的物理節(jié)點(diǎn)后存入

四、Redis Cluster（無(wú)中心架構(gòu)）

Redis Cluster沒(méi)有使用一致性hash, 而是引入了哈希槽的概念。每一臺(tái)實(shí)例都會(huì)分配對(duì)應(yīng)的槽位，自帶了算法與集群內(nèi)所有槽位的記錄，所以每一臺(tái)都是主。客戶端隨機(jī)地請(qǐng)求任意一個(gè)redis實(shí)例，然后由Redis將請(qǐng)求轉(zhuǎn)發(fā)給正確的Redis節(jié)點(diǎn)。簡(jiǎn)單的說(shuō)就是每一個(gè)節(jié)點(diǎn)的組成都是：數(shù)據(jù)+路由

• 優(yōu)點(diǎn)：擴(kuò)縮容方便，Redis自帶了工具與腳本對(duì)于Redis cluster架構(gòu)也有很好的支持

• 缺點(diǎn)：客戶端連接直接壓在了實(shí)例自身（可以在上層增加?proxy），刪除重定向也會(huì)造成過(guò)多的請(qǐng)求轉(zhuǎn)發(fā)與處理流程

為了方便理解，下邊通過(guò)圖解進(jìn)行說(shuō)明：

五、其他

當(dāng)使用 Redis cluster 架構(gòu)時(shí)候：

• 涉及多個(gè) key 的操作通常不會(huì)被支持。例如不能對(duì)兩個(gè)集合求交集，因?yàn)樗麄兛赡鼙淮鎯?chǔ)到不同的 Redis 實(shí)例（KEYS *、WATCH、MULTI...）

• 同時(shí)操作多個(gè) key ，則不能使用 Redis 事務(wù)

本文關(guān)鍵字：#Redis集群# #Redis分區(qū)#

---

文章推薦：

技術(shù)分享 | TiUP工具 - TiDB集群滾動(dòng)升級(jí)核心流程解析

故障分析 | OceanBase Proxy 無(wú)法連接 OBserver 集群

技術(shù)分享 | Xtrabackup 不備份 binlog 怎么保證一致性？

技術(shù)分享 | 怎么找到上鎖的 SQL 語(yǔ)句

---

關(guān)于SQLE

愛(ài)可生開源社區(qū)的 SQLE 是一款面向數(shù)據(jù)庫(kù)使用者和管理者，支持多場(chǎng)景審核，支持標(biāo)準(zhǔn)化上線流程，原生支持 MySQL 審核且數(shù)據(jù)庫(kù)類型可擴(kuò)展的 SQL 審核工具。

SQLE 獲取

類型地址

版本庫(kù)	https://github.com/actiontech/sqle
文檔	https://actiontech.github.io/sqle-docs-cn/
發(fā)布信息	https://github.com/actiontech/sqle/releases
數(shù)據(jù)審核插件開發(fā)文檔	https://actiontech.github.io/sqle-docs-cn/3.modules/3.7_auditplugin/auditplugin_development.html

更多關(guān)于 SQLE 的信息和交流，請(qǐng)加入官方QQ交流群：637150065...

總結(jié)

以上是生活随笔為你收集整理的技术分享 | Redis 集群架构解析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。