?前言

今天早上北京地鐵，看見一個正在學(xué)習(xí)Redis的小姐姐，很優(yōu)秀

在之前的Redis系列文章中，介紹了Redis的持久化、主從復(fù)制以及哨兵機(jī)制，主從復(fù)制+哨兵機(jī)制，既可以解決主master和從slave的解耦合實(shí)現(xiàn)多服務(wù)器備份數(shù)據(jù)，又可以通過哨兵機(jī)制來解決主宕機(jī)之后的主從切換，來實(shí)現(xiàn)高可用

但是，上面這種方式仍然有不足，最主要的問題就是**存儲能力受到單機(jī)限制，以及無法實(shí)現(xiàn)寫操作的負(fù)載均衡（寫操作均由主來完成）

在Redis3.0在開始使用引入的分布式存儲方案，即Redis集群cluster， 集群是由多個節(jié)點(diǎn)組成的，Redis集群的數(shù)據(jù)分區(qū)在這些節(jié)點(diǎn)中，節(jié)點(diǎn)分為主節(jié)點(diǎn)和從節(jié)點(diǎn)，一個集群有多個主節(jié)點(diǎn)和從節(jié)點(diǎn)，只有主節(jié)點(diǎn)負(fù)責(zé)讀寫請求和集群的維護(hù)，而從節(jié)點(diǎn)只負(fù)責(zé)主節(jié)點(diǎn)數(shù)據(jù)和狀態(tài)信息的復(fù)制

集群的搭建

這一部分我們來一起搭建一個含有6個節(jié)點(diǎn)的簡單的集群，三主三從，可以選擇所有節(jié)點(diǎn)在同一臺服務(wù)器上，也可以選擇不在同一服務(wù)器上

這里演示以同一服務(wù)器為準(zhǔn)，以端口號不同來區(qū)分主從，配置從簡，三個主節(jié)點(diǎn)端口號為：6001、6002、6003，三個對應(yīng)從節(jié)點(diǎn)端口號為7001、7002、7003，搭建集群大致需要四個步驟：

（1）啟動節(jié)點(diǎn)：以集群的模式啟動相應(yīng)的Redis節(jié)點(diǎn)，節(jié)點(diǎn)獨(dú)立\

（2）節(jié)點(diǎn)握手：節(jié)點(diǎn)之間握手，形成一個網(wǎng)絡(luò)\

（3）分配槽位：將16384個槽位分配給多個主節(jié)點(diǎn)

（4）指定從節(jié)點(diǎn)：為每一個主節(jié)點(diǎn)指定相應(yīng)的從節(jié)點(diǎn)

1、啟動節(jié)點(diǎn)

其實(shí)啟動集群的節(jié)點(diǎn)也是和正常節(jié)點(diǎn)一樣的，也是通過redis-server來啟動，但是配置文件需要修改，以集群的方式來啟動，看下配置文件案例

#redis-6001.conf port 6001 cluster-enabled yes cluster-config-file "node-6001.conf" logfile "log-6001.log" dbfilename "dump-6001.rdb" daemonize yes

其中的cluster-enabled和cluster-config-file都是和集群相關(guān)的配置；

cluster-enabled配置設(shè)置相應(yīng)的啟動模式是單機(jī)模式或者集群模式，如果是yes則為按照集群模式啟動，no則為單機(jī)模式

可以通過info server命令來查看服務(wù)器信息，然后會看到redis_mode這一項(xiàng)對應(yīng)的值是cluster，代表集群模式，如果是standalone，則為單機(jī)模式；

cluster-config-file則指定了集群配置文件的位置，每個節(jié)點(diǎn)在運(yùn)行的時(shí)候維護(hù)一個集群配置文件，這和剛剛上面配置文件是不同的，屬于集群特有

每當(dāng)集群信息發(fā)生變化時(shí)，集群中的所有節(jié)點(diǎn)會將信息更新到集群配置文件中，節(jié)點(diǎn)重啟的時(shí)候也可以重新讀取該配置文件，獲取到集群的信息

Redis節(jié)點(diǎn)啟動的時(shí)候，首先檢查是否含有集群配置文件，如果有則使用集群配置文件進(jìn)行配置啟動，如果沒有則初始化配置并且保存到集群配置文件中，集群配置文件是由節(jié)點(diǎn)自動維護(hù)更新的，不需要人工維護(hù)

我們按照上述代碼塊編輯好配置文件之后，使用正常的 redis-server redis-6001.conf 來啟動redis節(jié)點(diǎn)，節(jié)點(diǎn)成功啟動之后，返回值的第一項(xiàng)就是節(jié)點(diǎn)id，由40個16進(jìn)制字符組成，節(jié)點(diǎn)id只在集群初始化的時(shí)候創(chuàng)建一次，然后保存到配置文件中，下一次啟動的時(shí)候自動讀取使用該id；

和主從復(fù)制篇中runid不同的是，runid是每次重啟都會重新創(chuàng)建，但是節(jié)點(diǎn)id只在集群初始化的時(shí)候創(chuàng)建一次

2、節(jié)點(diǎn)握手

節(jié)點(diǎn)啟動之后，是互相獨(dú)立的，并不知道其它節(jié)點(diǎn)的存在，需要進(jìn)行節(jié)點(diǎn)的握手，才可以把這些節(jié)點(diǎn)組成一個網(wǎng)絡(luò)，互相知道對方的存在，節(jié)點(diǎn)握手使用cluster mett ip port 命令來實(shí)現(xiàn)

比如我們現(xiàn)在在端口號為6001上的客戶端上執(zhí)行cluster meet 127.0.0.1 6002，可以完成6001服務(wù)器和6002服務(wù)器的握手

同理，我們把其余的6003、7001、7002、7003的節(jié)點(diǎn)都握手，這樣6000節(jié)點(diǎn)便可以感受到其余五個服務(wù)器了，通過節(jié)點(diǎn)之間的通信，每個節(jié)點(diǎn)也可以感受到其它的節(jié)點(diǎn)的存在

3、分配槽位

集群中有16384個槽位，槽是數(shù)據(jù)管理和遷移的基本單位，當(dāng)數(shù)據(jù)庫中的16384個槽位都進(jìn)行了分配之后，集群處于線程狀態(tài)，如果有任意一個槽未進(jìn)行分配，則集群處于下線狀態(tài)，我們可以通過cluster info命令來查看集群的狀態(tài)，看到cluster_state的狀態(tài)是fail，分配槽使用cluster addslots命令，分配槽給主節(jié)點(diǎn)

redis-cli -p 6001cluster addslots {0..5461} redis-cli -p 6002cluster addslots {5462..10922} redis-cli -p 6003cluster addslots {10923..16383}

此時(shí)再用cluster info查看集群狀態(tài)，處于OK狀態(tài)

4、指定主從關(guān)系

集群中指定主從關(guān)系不再像主從復(fù)制那樣使用slaveof命令，而是使用cluster replicate命令，參數(shù)是節(jié)點(diǎn)的id，就是我們上面提到的節(jié)點(diǎn)id，可以通過cluster node來查看節(jié)點(diǎn)id

redis-cli -p 8000 cluster replicate 2d87d7708efa6df6feb3b1e0cce081dd8984420d redis-cli -p 8001 cluster replicate f1e370caddac65e23477e098863177ba4387a506 redis-cli -p 8002 cluster replicate 171d843413b3d3d0b63f644b6cf07a467108c214

此時(shí)再用cluster node查看節(jié)點(diǎn)狀態(tài)，可以看到節(jié)點(diǎn)的主從關(guān)系已經(jīng)建立，實(shí)際上，前三步完成后便可以對外提供服務(wù)，但是需要指定相應(yīng)的從節(jié)點(diǎn)之后，集群才可以提供高可用的服務(wù)

集群搭建完畢，開始原理部分

集群內(nèi)部

我們雖然上面搞會了搭建集群，但是我們還不知道關(guān)于集群的內(nèi)部原理部分，內(nèi)部原理這塊我大體分為數(shù)據(jù)分區(qū)、節(jié)點(diǎn)通信、集群狀態(tài)三部分來說明

1、數(shù)據(jù)分區(qū)：

數(shù)據(jù)分區(qū)有順序分區(qū)，哈希分區(qū)等，而哈希分區(qū)具有天然的隨機(jī)性，集群使用的分區(qū)方案便是哈希分區(qū)的一種。

衡量數(shù)據(jù)分區(qū)方法好壞的標(biāo)準(zhǔn)有很多，其中比較重要的兩個因素是

• 數(shù)據(jù)分布是否均勻
• 增加或刪減節(jié)點(diǎn)對數(shù)據(jù)分布的影響。

由于哈希的隨機(jī)性，哈希分區(qū)基本可以保證數(shù)據(jù)分布均勻，因此在比較哈希分區(qū)方案時(shí)，重點(diǎn)要看增減節(jié)點(diǎn)對數(shù)據(jù)分布的影響。

哈希分區(qū)又可分為哈希取余分區(qū)、一致性哈希分區(qū)、帶虛擬節(jié)點(diǎn)的一致性哈希分區(qū)，接下來簡單介紹下

哈希取余分區(qū)

哈希取余分區(qū)思路非常簡單：計(jì)算key的hash值，然后對節(jié)點(diǎn)數(shù)量進(jìn)行取余，從而決定數(shù)據(jù)映射到哪個節(jié)點(diǎn)上。

該方案最大的問題是，當(dāng)新增或刪減節(jié)點(diǎn)時(shí)，節(jié)點(diǎn)數(shù)量發(fā)生變化，系統(tǒng)中所有的數(shù)據(jù)都需要重新計(jì)算映射關(guān)系，引發(fā)大規(guī)模數(shù)據(jù)遷移

一致性哈希

將整個哈希值空間組織成一個虛擬的圓環(huán)，范圍為0-2^32-1；

對于每個數(shù)據(jù)，根據(jù)key計(jì)算hash值，確定數(shù)據(jù)在環(huán)上的位置，然后從此位置沿環(huán)順時(shí)針行走，找到的第一臺服務(wù)器就是其應(yīng)該映射到的服務(wù)器

與哈希取余分區(qū)相比，一致性哈希分區(qū)將增減節(jié)點(diǎn)的影響限制在相鄰節(jié)點(diǎn)。

以上圖為例，如果在node1和node2之間增加node5，則只有node2中的一部分?jǐn)?shù)據(jù)會遷移到node5；如果去掉node2，則原node2中的數(shù)據(jù)只會遷移到node4中，只有node4會受影響

一致性哈希分區(qū)的主要問題在于，當(dāng)節(jié)點(diǎn)數(shù)量較少時(shí)，增加或刪減節(jié)點(diǎn)，對單個節(jié)點(diǎn)的影響可能很大，造成數(shù)據(jù)的嚴(yán)重不平衡。

還是以上圖為例，如果去掉node2，node4中的數(shù)據(jù)由總數(shù)據(jù)的1/4左右變?yōu)?/2左右，與其他節(jié)點(diǎn)相比負(fù)載過高

帶虛擬節(jié)點(diǎn)的一致性哈希

集群采用的是帶虛擬節(jié)點(diǎn)的一致性哈希分區(qū)，在redis中這里的虛擬節(jié)點(diǎn)被稱為槽（slot），redis被設(shè)計(jì)為16384個槽。

槽是介于數(shù)據(jù)和實(shí)際節(jié)點(diǎn)之間的虛擬概念；每個實(shí)際節(jié)點(diǎn)包含一定數(shù)量的槽，每個槽包含哈希值在一定范圍內(nèi)的數(shù)據(jù)。

引入槽以后，數(shù)據(jù)的映射關(guān)系由數(shù)據(jù)hash->實(shí)際節(jié)點(diǎn)，變成了數(shù)據(jù)hash->槽->實(shí)際節(jié)點(diǎn)，在使用了槽的一致性哈希分區(qū)中，槽是數(shù)據(jù)管理和遷移的基本單位。

槽解耦了數(shù)據(jù)和實(shí)際節(jié)點(diǎn)之間的關(guān)系，增加或刪除節(jié)點(diǎn)對系統(tǒng)的影響很小

舉個簡單例子說明：我們存取的key會根據(jù)crc16的算法得出一個結(jié)果，然后把結(jié)果對 16384 求余數(shù)，這樣每個 key 都會對應(yīng)一個編號在 0-16383 之間的哈希槽，通過這個值，去找到對應(yīng)的插槽所對應(yīng)的節(jié)點(diǎn)，然后直接自動跳轉(zhuǎn)到這個對應(yīng)的節(jié)點(diǎn)上進(jìn)行存取操作

2、節(jié)點(diǎn)通信：

節(jié)點(diǎn)通信主要是依靠端口號、Gossip協(xié)議來完成的

端口號

我們通過哨兵那一篇知道了哨兵系統(tǒng)中，哨兵節(jié)點(diǎn)是不存儲數(shù)據(jù)的，主要是負(fù)責(zé)控制故障轉(zhuǎn)移；

而在集群系統(tǒng)中，所有的節(jié)點(diǎn)都是存儲數(shù)據(jù)的，也都參與集群的維護(hù)，更像是一個大家庭，大家一起來維護(hù)，集群中的每個節(jié)點(diǎn)都提供了兩個端口號：

• 普通端口：即我們在前面指定的端口(6001這些)。普通端口主要用于為客戶端提供服務(wù)，在節(jié)點(diǎn)間數(shù)據(jù)遷移時(shí)也會使用
• 集群端口：集群端口是普通端口+10000（10000是固定值，無法改變），如6001節(jié)點(diǎn)的集群端口為16001。集群端口只用于節(jié)點(diǎn)之間的通信，如搭建集群、增減節(jié)點(diǎn)等操作時(shí)節(jié)點(diǎn)間的通信，為了保證集群可以正常工作，可以關(guān)閉本地防火墻，不要使用客戶端連接集群接口

Gossip協(xié)議

節(jié)點(diǎn)之間通信，主要分為幾種類型：單對單、廣播、Gossip協(xié)議幾種類型

單對單，這個應(yīng)該不用我多嗶嗶；

廣播的話，指的是向集群內(nèi)所有節(jié)點(diǎn)發(fā)送消息，優(yōu)點(diǎn)是集群內(nèi)所有節(jié)點(diǎn)獲得的集群信息是一致的，速度快，缺點(diǎn)是每條消息都要發(fā)送給所有節(jié)點(diǎn)，消耗帶寬；

Gossip協(xié)議，在有限的節(jié)點(diǎn)網(wǎng)絡(luò)中，每個節(jié)點(diǎn)隨機(jī)的和部分節(jié)點(diǎn)通信（其實(shí)并不真隨機(jī)，而是根據(jù)特定的規(guī)則選擇相應(yīng)的節(jié)點(diǎn)），經(jīng)過看似無序的通信之后每個節(jié)點(diǎn)的狀態(tài)很快會達(dá)到一致

Gossip協(xié)議的優(yōu)點(diǎn)是負(fù)載低、去中心化、容錯性高；缺點(diǎn)主要是集群的收斂速度慢。

3、集群狀態(tài)：

集群的狀態(tài)這個概念是比較廣的，包括集群是否處于上線狀態(tài)、集群中有哪些節(jié)點(diǎn)、節(jié)點(diǎn)是否可達(dá)、槽的狀態(tài)、節(jié)點(diǎn)的主從狀態(tài)等

那么，集群狀態(tài)的信息是由誰來維護(hù)的呢？又是怎樣維護(hù)的呢？

集群的狀態(tài)是由集群中所有節(jié)點(diǎn)共同維護(hù)的，向上面說的，每個節(jié)點(diǎn)對應(yīng)著有個集群中的端口號，也會生成相應(yīng)的集群配置文件；

節(jié)點(diǎn)為了存儲集群狀態(tài)，最主要的是通過clusterNode和clusterState這兩種結(jié)構(gòu)維護(hù)集群，前者是記錄了一個節(jié)點(diǎn)的狀態(tài)，后者是記錄了集群整體的狀態(tài)

clusterNode

clusterNode結(jié)構(gòu)保存了一個節(jié)點(diǎn)的當(dāng)前狀態(tài)，包括創(chuàng)建時(shí)間、節(jié)點(diǎn)id、ip和端口號等。

每個節(jié)點(diǎn)都會用一個clusterNode結(jié)構(gòu)記錄自己的狀態(tài)，并為集群內(nèi)所有其他節(jié)點(diǎn)都創(chuàng)建一個clusterNode結(jié)構(gòu)來記錄節(jié)點(diǎn)狀態(tài)

typedef struct clusterNode {//節(jié)點(diǎn)創(chuàng)建時(shí)間mstime_t ctime;//節(jié)點(diǎn)idchar name[REDIS_CLUSTER_NAMELEN];//節(jié)點(diǎn)的ip和端口號char ip[REDIS_IP_STR_LEN];int port;//節(jié)點(diǎn)標(biāo)識：整型，每個bit都代表了不同狀態(tài)，如節(jié)點(diǎn)的主從狀態(tài)、是否在線、是否在握手等int flags;//配置紀(jì)元：故障轉(zhuǎn)移時(shí)起作用，類似于哨兵的配置紀(jì)元uint64_t configEpoch;//槽在該節(jié)點(diǎn)中的分布：占用16384/8個字節(jié)，16384個比特；每個比特對應(yīng)一個槽：比特值為1，則該比特對應(yīng)的槽在節(jié)點(diǎn)中；比特值為0，則該比特對應(yīng)的槽不在節(jié)點(diǎn)中unsigned char slots[16384/8];//節(jié)點(diǎn)中槽的數(shù)量int numslots;…………} clusterNode;

clusterState

clusterState結(jié)構(gòu)保存了在當(dāng)前節(jié)點(diǎn)視角下，集群所處的狀態(tài)。主要字段包括：

typedef struct clusterState {//自身節(jié)點(diǎn)clusterNode *myself;//配置紀(jì)元uint64_t currentEpoch;//集群狀態(tài)：在線還是下線int state;//集群中至少包含一個槽的節(jié)點(diǎn)數(shù)量int size;//哈希表，節(jié)點(diǎn)名稱->clusterNode節(jié)點(diǎn)指針dict *nodes;//槽分布信息：數(shù)組的每個元素都是一個指向clusterNode結(jié)構(gòu)的指針；如果槽還沒有分配給任何節(jié)點(diǎn)，則為NULLclusterNode *slots[16384];………… } clusterState;

集群方案的設(shè)計(jì)

設(shè)計(jì)集群方案時(shí)，至少要考慮以下因素：

• 數(shù)據(jù)量和訪問量：估算應(yīng)用需要的數(shù)據(jù)量和總訪問量(考慮業(yè)務(wù)發(fā)展，留有冗余)，結(jié)合每個主節(jié)點(diǎn)的容量和能承受的訪問量(可以通過benchmark得到較準(zhǔn)確估計(jì))，計(jì)算需要的主節(jié)點(diǎn)數(shù)量
• 高可用要求：根據(jù)故障轉(zhuǎn)移的原理，至少需要3個主節(jié)點(diǎn)才能完成故障轉(zhuǎn)移，且3個主節(jié)點(diǎn)不應(yīng)在同一臺物理機(jī)上；每個主節(jié)點(diǎn)至少需要1個從節(jié)點(diǎn)，且主從節(jié)點(diǎn)不應(yīng)在一臺物理機(jī)上；因此高可用集群至少包含6個節(jié)點(diǎn)
• 節(jié)點(diǎn)數(shù)量限制：Redis官方給出的節(jié)點(diǎn)數(shù)量限制為1000，主要是考慮節(jié)點(diǎn)間通信帶來的消耗。在實(shí)際應(yīng)用中應(yīng)盡量避免大集群；如果節(jié)點(diǎn)數(shù)量不足以滿足應(yīng)用對Redis數(shù)據(jù)量和訪問量的要求，可以考慮：(1)業(yè)務(wù)分割，大集群分為多個小集群；(2)減少不必要的數(shù)據(jù)；(3)調(diào)整數(shù)據(jù)過期策略等
• 適度冗余：Redis可以在不影響集群服務(wù)的情況下增加節(jié)點(diǎn)，因此節(jié)點(diǎn)數(shù)量適當(dāng)冗余即可，不用太大

從節(jié)點(diǎn)服務(wù)器內(nèi)部維護(hù)了masterhost、masterport兩個字段，用于保存主節(jié)點(diǎn)服務(wù)器的IP和端口信息

關(guān)于主從復(fù)制的問題還有很多，下面我會單獨(dú)肝一篇來分析主從復(fù)制中存在的問題以及解決辦法

結(jié)束語

感謝大家能夠做我最初的讀者和傳播者，請大家相信，只要你給我一

份愛，我終究會還你們一頁情的。

歡迎大家關(guān)注我的公眾號【左耳君】，探索技術(shù)，分享生活

哦對了，后續(xù)所有的文章都會更新到這里

https://github.com/DayuMM2021/Java

總結(jié)

以上是生活随笔為你收集整理的你了解Redis集群中的秘密吗？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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