亚洲日韩在线一区二区三区,色综合1色综合2色综合3色综合4,免费看污黄网站 7 8

前面我們介紹了國(guó)人自己開發(fā)的redis集群方案——Codis，Codis友好的管理界面以及強(qiáng)大的自動(dòng)平衡槽位的功能深受廣大開發(fā)者的喜愛。今天我們一起來(lái)聊一聊Redis作者自己提供的集群方案——Cluster。希望讀完這篇文章，你能夠充分了解Codis和Cluster各自的優(yōu)缺點(diǎn)，面對(duì)不同的應(yīng)用場(chǎng)景可以從容的做出選擇。

Redis Cluster是去中心化的，這點(diǎn)與Codis有著本質(zhì)的不同，Redis Cluster劃分了16384個(gè)slots，每個(gè)節(jié)點(diǎn)負(fù)責(zé)其中的一部分?jǐn)?shù)據(jù)。slot的信息存儲(chǔ)在每個(gè)節(jié)點(diǎn)中，節(jié)點(diǎn)會(huì)將slot信息持久化到配置文件中，因此需要保證配置文件是可寫的。當(dāng)客戶端連接時(shí)，會(huì)獲得一份slot的信息。這樣當(dāng)客戶端需要訪問(wèn)某個(gè)key時(shí)，就可以直接根據(jù)緩存在本地的slot信息來(lái)定位節(jié)點(diǎn)。這樣就會(huì)存在客戶端緩存的slot信息和服務(wù)器的slot信息不一致的問(wèn)題，這個(gè)問(wèn)題具體怎么解決呢？這里先賣個(gè)關(guān)子，后面會(huì)做解釋。

特性

首先我們來(lái)看下官方對(duì)Redis Cluster的介紹。

High performance and linear scalability up to 1000 nodes. There are no proxies, asynchronous replication is used, and no merge operations are performed on values.
Acceptable degree of write safety: the system tries (in a best-effort way) to retain all the writes originating from clients connected with the majority of the master nodes. Usually there are small windows where acknowledged writes can be lost. Windows to lose acknowledged writes are larger when clients are in a minority partition.
Availability: Redis Cluster is able to survive partitions where the majority of the master nodes are reachable and there is at least one reachable slave for every master node that is no longer reachable. Moreover using replicas migration, masters no longer replicated by any slave will receive one from a master which is covered by multiple slaves.

是不是不(kan)想(bu)看(dong)？沒(méi)關(guān)系，我來(lái)給你掰開了揉碎了解釋一下。

寫安全

Redis Cluster使用異步的主從同步方式，只能保證最終一致性。所以會(huì)引起一些寫入數(shù)據(jù)丟失的問(wèn)題，在繼續(xù)閱讀之前，可以先自己思考一下在什么情況下寫入的數(shù)據(jù)會(huì)丟失。

先來(lái)看一種比較常見的寫丟失的情況：

client向一個(gè)master發(fā)送一個(gè)寫請(qǐng)求，master寫成功并通知client。在同步到slave之前，這個(gè)master掛了，它的slave代替它成為了新的master。這時(shí)前面寫入的數(shù)據(jù)就丟失了。

此外，還有一種情況。

master節(jié)點(diǎn)與大多數(shù)節(jié)點(diǎn)無(wú)法通信，一段時(shí)間后，這個(gè)master被認(rèn)為已經(jīng)下線，并且被它的slave頂替，又過(guò)了一段時(shí)間，原來(lái)的master節(jié)點(diǎn)重寫恢復(fù)了連接。這時(shí)如果一個(gè)client存有過(guò)期的路由表，它就會(huì)把寫請(qǐng)求發(fā)送的這個(gè)舊的master節(jié)點(diǎn)（已經(jīng)變成slave了）上，從而導(dǎo)致寫數(shù)據(jù)丟失。

不過(guò)，這種情況一般不會(huì)發(fā)生，因?yàn)楫?dāng)一個(gè)master失去連接足夠長(zhǎng)時(shí)間而被認(rèn)為已經(jīng)下線時(shí)，就會(huì)開始拒絕寫請(qǐng)求。當(dāng)它恢復(fù)之后，仍然會(huì)有一小段時(shí)間是拒絕寫請(qǐng)求的，這段時(shí)間是為了讓其他節(jié)點(diǎn)更新自己的路由表中的配置信息。

為了盡可能保證寫安全性，Redis Cluster在發(fā)生分區(qū)時(shí)，會(huì)盡量使客戶端連接到多數(shù)節(jié)點(diǎn)的那一部分，因?yàn)槿绻B接到少數(shù)部分，當(dāng)master被替換時(shí)，會(huì)因?yàn)槎鄶?shù)master不可達(dá)而拒絕所有的寫請(qǐng)求，這樣損失的數(shù)據(jù)要增大很多。

Redis Cluster維護(hù)了一個(gè)NODE_TIMEOUT變量，如果上述情況中，master在NODE_TIMEOUT時(shí)間內(nèi)恢復(fù)連接，就不會(huì)有數(shù)據(jù)丟失。

可用性

如果集群的大部分master可達(dá)，并且每個(gè)不可達(dá)的master至少有一個(gè)slave，在NODE_TIMEOUT時(shí)間后，就會(huì)開始進(jìn)行故障轉(zhuǎn)移（一般1到2秒），故障轉(zhuǎn)移完成后的集群仍然可用。

如果集群中得N個(gè)master節(jié)點(diǎn)都有1個(gè)slave，當(dāng)有一個(gè)節(jié)點(diǎn)掛掉時(shí)，集群一定是可用的，如果有2個(gè)節(jié)點(diǎn)掛掉，那么就會(huì)有1/(N*2-1)的概率導(dǎo)致集群不可用。

Redis Cluster為了提高可用性，新增了一個(gè)新的feature，叫做replicas migration（副本遷移，ps：我自己翻譯的），這個(gè)feature其實(shí)就是在每次故障之后，重新布局集群的slave，給沒(méi)有slave的master配備上slave，以此來(lái)更好的應(yīng)對(duì)下次故障。

性能

Redis Cluster不提供代理，而是讓client直接重定向到正確的節(jié)點(diǎn)。

client中會(huì)保存一份集群狀態(tài)的副本，一般情況下就會(huì)直接連接到正確的節(jié)點(diǎn)。

由于Redis Cluster是異步備份的，所以節(jié)點(diǎn)不需要等待其他節(jié)點(diǎn)確認(rèn)寫成功就可以直接返回，除非顯式的使用了WAIT命令。

對(duì)于操作多個(gè)key的命令，所操作的key必須是在同一節(jié)點(diǎn)上的，因?yàn)閿?shù)據(jù)是不會(huì)移動(dòng)的。（除非是resharding）

Redis Cluster設(shè)計(jì)的主要目標(biāo)是提高性能和擴(kuò)展性，只提供弱的數(shù)據(jù)安全性和可用性（但是要合理）。

Key分配模型

Redis Cluster共劃分為16384個(gè)槽位。這也意味著一個(gè)集群最多可以有16384個(gè)master，不過(guò)官方建議master的最大數(shù)量是1000個(gè)。

如果Cluster不處于重新配置過(guò)程，那么就會(huì)達(dá)到一種穩(wěn)定狀態(tài)。在穩(wěn)定狀態(tài)下，一個(gè)槽位只由一個(gè)master提供服務(wù)，不過(guò)一個(gè)master節(jié)點(diǎn)會(huì)有一個(gè)或多個(gè)slave，這些slave可以提供緩解master的讀請(qǐng)求的壓力。

Redis Cluster會(huì)對(duì)key使用CRC16算法進(jìn)行hash，然后對(duì)16384取模來(lái)確定key所屬的槽位（hash tag會(huì)打破這種規(guī)則）。

Keys hash tags

標(biāo)簽是破壞上述計(jì)算規(guī)則的實(shí)現(xiàn)，Hash tag是一種保證多個(gè)鍵被分配到同一個(gè)槽位的方法。

hash tag的計(jì)算規(guī)則是：取一對(duì)大括號(hào){}之間的字符進(jìn)行計(jì)算，如果key存在多對(duì)大括號(hào)，那么就取第一個(gè)左括號(hào)和第一個(gè)右括號(hào)之間的字符。如果大括號(hào)之前沒(méi)有字符，則會(huì)對(duì)整個(gè)字符串進(jìn)行計(jì)算。

說(shuō)了這個(gè)多，可能你還是一頭霧水。別急，我們來(lái)吃幾個(gè)栗子。

{Jackeyzhe}.following和{Jackeyzhe}.follower這兩個(gè)key都是計(jì)算Jackey的hash值
foo{{bar}}這個(gè)key就會(huì)對(duì){bar進(jìn)行hash計(jì)算
follow{}{Jackey}會(huì)對(duì)整個(gè)字符串進(jìn)行計(jì)算

重定向

前面聊性能的時(shí)候我們提到過(guò)，Redis Cluster為了提高性能，不會(huì)提供代理，而是使用重定向的方式讓client連接到正確的節(jié)點(diǎn)。下面我們來(lái)詳細(xì)說(shuō)明一下Redis Cluster是如何進(jìn)行重定向的。

MOVED重定向

Redis客戶端可以向集群的任意一個(gè)節(jié)點(diǎn)發(fā)送查詢請(qǐng)求，節(jié)點(diǎn)接收到請(qǐng)求后會(huì)對(duì)其進(jìn)行解析，如果是操作單個(gè)key的命令或者是包含多個(gè)在相同槽位key的命令，那么該節(jié)點(diǎn)就會(huì)去查找這個(gè)key是屬于哪個(gè)槽位的。

如果key所屬的槽位由該節(jié)點(diǎn)提供服務(wù)，那么就直接返回結(jié)果。否則就會(huì)返回一個(gè)MOVED錯(cuò)誤：

1GET x

2-MOVED 3999 127.0.0.1:6381

這個(gè)錯(cuò)誤包括了對(duì)應(yīng)的key屬于哪個(gè)槽位（3999）以及該槽位所在的節(jié)點(diǎn)的IP地址和端口號(hào)。client收到這個(gè)錯(cuò)誤信息后，就將這些信息存儲(chǔ)起來(lái)以便可以更準(zhǔn)確的找到正確的節(jié)點(diǎn)。

當(dāng)客戶端收到MOVED錯(cuò)誤后，可以使用CLUSTER NODES或CLUSTER SLOTS命令來(lái)更新整個(gè)集群的信息，因?yàn)楫?dāng)重定向發(fā)生時(shí)，很少會(huì)是單個(gè)槽位的變更，一般都會(huì)是多個(gè)槽位一起更新。因此，在收到MOVED錯(cuò)誤時(shí)，客戶端應(yīng)該盡早更新集群的分布信息。當(dāng)集群達(dá)到穩(wěn)定狀態(tài)時(shí)，客戶端保存的槽位和節(jié)點(diǎn)的對(duì)應(yīng)信息都是正確的，cluster的性能也會(huì)達(dá)到非常高效的狀態(tài)。

除了MOVED重定向之外，一個(gè)完整的集群還應(yīng)該支持ASK重定向。

ASK重定向

對(duì)于Redis Cluster來(lái)講，MOVED重定向意味著請(qǐng)求的slot永遠(yuǎn)由另一個(gè)node提供服務(wù)，而ASK重定向僅代表下一個(gè)請(qǐng)求需要發(fā)送到指定的節(jié)點(diǎn)。在Redis Cluster遷移的時(shí)候會(huì)用到ASK重定向，那Redis Cluster遷移的過(guò)程究竟是怎樣的呢？

Redis Cluster的遷移是以槽位單位的，遷移過(guò)程總共分3步（類似于把大象裝進(jìn)冰箱），我們來(lái)舉個(gè)栗子，看一下一個(gè)槽位從節(jié)點(diǎn)A遷移到節(jié)點(diǎn)B需要經(jīng)過(guò)哪些步驟：

首先打開冰箱門，也就是從A節(jié)點(diǎn)獲得槽位所有的key列表，再挨個(gè)key進(jìn)行遷移，在這之前，A節(jié)點(diǎn)的該槽位被設(shè)置為migrating狀態(tài)，B節(jié)點(diǎn)被設(shè)置為importing的槽位（都是用CLUSTER SETSLOT命令）。
第二步，就是要把大象裝進(jìn)去了，對(duì)于每個(gè)key來(lái)說(shuō)，就是在A節(jié)點(diǎn)用dump命令對(duì)其進(jìn)行序列化，再通過(guò)客戶端在B節(jié)點(diǎn)執(zhí)行restore命令，反序列化到B節(jié)點(diǎn)。
第三步呢，就需要把冰箱門關(guān)上，也就是把對(duì)應(yīng)的key從A節(jié)點(diǎn)刪除。

有同學(xué)會(huì)問(wèn)了，說(shuō)好的用到ASK重定向呢？上面我們所描述的只是遷移的過(guò)程，在遷移過(guò)程中，Redis還是要對(duì)外提供服務(wù)的。試想一下，如果在遷移過(guò)程中，我向A節(jié)點(diǎn)請(qǐng)求查詢x的值，A說(shuō)：我這沒(méi)有啊，我也不知道是傳到B那去了還是我一直就沒(méi)有存，你還是先問(wèn)問(wèn)B吧。然后返回給我們一個(gè)-ASK targetNodeAddr的錯(cuò)誤，讓我們?nèi)?wèn)B。而這時(shí)如果我們直接去問(wèn)B，B肯定會(huì)直接說(shuō)：這個(gè)不歸我管，你得去問(wèn)A。（-MOVED重定向）。因?yàn)檫@時(shí)候遷移還沒(méi)有完成，所以B也沒(méi)說(shuō)錯(cuò)，這時(shí)候x真的不歸它管。但是我們不能讓它倆來(lái)回踢皮球啊，所以在問(wèn)B之前，我們先給B發(fā)一個(gè)asking指令，告訴B：下面我問(wèn)你一個(gè)key的值，你得當(dāng)成是自己的key來(lái)處理，不能說(shuō)不知道。這樣如果x已經(jīng)遷移到B，就會(huì)直接返回結(jié)果，如果B也查不到x的下落，說(shuō)明x不存在。

容錯(cuò)

了解了Redis Cluster的重定向操作之后，我們?cè)賮?lái)聊一聊Redis Cluster的容錯(cuò)機(jī)制，Redis Cluster和大多數(shù)集群一樣，是通過(guò)心跳來(lái)判斷一個(gè)節(jié)點(diǎn)是否存活的。

心跳和gossip消息

集群中的節(jié)點(diǎn)會(huì)不停的互相交換ping pong包，ping pong包具有相同的結(jié)構(gòu)，只是類型不同，ping pong包合在一起叫做心跳包。

通常節(jié)點(diǎn)會(huì)發(fā)送ping包并接收接收者返回的pong包，不過(guò)這也不是絕對(duì)，節(jié)點(diǎn)也有可能只發(fā)送pong包，而不需要讓接收者發(fā)送返回包，這種操作通常用于廣播一個(gè)新的配置信息。

節(jié)點(diǎn)會(huì)每個(gè)幾秒鐘就發(fā)送一定數(shù)量的ping包。如果一個(gè)節(jié)點(diǎn)超過(guò)二分之一NODE_TIME時(shí)間沒(méi)有收到來(lái)自某個(gè)節(jié)點(diǎn)ping或pong包，那么就會(huì)在NODE_TIMEOUT之前像該節(jié)點(diǎn)發(fā)送ping包，在NODE_TIMEOUT之前，節(jié)點(diǎn)會(huì)嘗試TCP重連，避免由于TCP連接問(wèn)題而誤以為節(jié)點(diǎn)不可達(dá)。

心跳包內(nèi)容

前面我們說(shuō)了，ping和pong包的結(jié)構(gòu)是相同的，下面就來(lái)具體看一下包的內(nèi)容。

ping和pong包的內(nèi)容可以分為header和gossip消息兩部分，其中header包含以下信息：

NODE ID是一個(gè)160bit的偽隨機(jī)字符串，它是節(jié)點(diǎn)在集群中的唯一標(biāo)識(shí)
currentEpoch和configEpoch字段
node flag，標(biāo)識(shí)節(jié)點(diǎn)是master還是slave，另外還有一些其他的標(biāo)識(shí)位
節(jié)點(diǎn)提供服務(wù)的hash slot的bitmap
發(fā)送者的TCP端口
發(fā)送者認(rèn)為的集群狀態(tài)（down or ok）
如果是slave，則包含master的NODE ID

gossip包含了該節(jié)點(diǎn)認(rèn)為的其他節(jié)點(diǎn)的狀態(tài)，不過(guò)不是集群的全部節(jié)點(diǎn)。具體有以下信息：

NODE ID
節(jié)點(diǎn)的IP和端口
NODE flags

gossip消息在錯(cuò)誤檢測(cè)和節(jié)點(diǎn)發(fā)現(xiàn)中起著重要的作用。

錯(cuò)誤檢測(cè)

錯(cuò)誤檢測(cè)用于識(shí)別集群中的不可達(dá)節(jié)點(diǎn)是否已下線，如果一個(gè)master下線，會(huì)將它的slave提升為master。如果無(wú)法提升，則集群會(huì)處于錯(cuò)誤狀態(tài)。在gossip消息中，NODE flags的值包括兩種PFAIL和FAIL。

PFAIL flag

如果一個(gè)節(jié)點(diǎn)發(fā)現(xiàn)另外一個(gè)節(jié)點(diǎn)不可達(dá)的時(shí)間超過(guò)NODE_TIMEOUT ，則會(huì)將這個(gè)節(jié)點(diǎn)標(biāo)記為PFAIL，也就是Possible failure（可能下線）。節(jié)點(diǎn)不可達(dá)是說(shuō)一個(gè)節(jié)點(diǎn)發(fā)送了ping包，但是等待了超過(guò)NODE_TIMEOUT時(shí)間仍然沒(méi)有收到回應(yīng)。這也就意味著，NODE_TIMEOUT必須大于一個(gè)網(wǎng)絡(luò)包來(lái)回的時(shí)間。

FAIL flag

PFAIL標(biāo)志只是一個(gè)節(jié)點(diǎn)本地的信息，為了使slave提升為master，需要將PFAIL升級(jí)為FAIL。PFAIL升級(jí)為FAIL需要滿足一些條件：

A節(jié)點(diǎn)將B節(jié)點(diǎn)標(biāo)記為PFAIL
A節(jié)點(diǎn)通過(guò)gossip消息收集其他大部分master節(jié)點(diǎn)標(biāo)識(shí)的B節(jié)點(diǎn)的狀態(tài)
大部分master節(jié)點(diǎn)在NODE_TIMEOUT * FAIL_REPORT_VALIDITY_MULT時(shí)間段內(nèi)，標(biāo)識(shí)B節(jié)點(diǎn)為PFAIL或FAIL

如果滿足以上條件，A節(jié)點(diǎn)會(huì)將B節(jié)點(diǎn)標(biāo)識(shí)為FAIL并且向所有節(jié)點(diǎn)發(fā)送B節(jié)點(diǎn)FAIL的消息。收到消息的節(jié)點(diǎn)也都會(huì)將B標(biāo)為FAIL。

FAIL狀態(tài)是單向的，只能從PFAIL升級(jí)為FAIL，而不能從FAIL降為PFAIL。不過(guò)存在一些清除FAIL狀態(tài)的情況：

節(jié)點(diǎn)重新可達(dá)，并且是slave節(jié)點(diǎn)
節(jié)點(diǎn)重新可達(dá)，并且是master節(jié)點(diǎn)，但是不提供任何slot服務(wù)
節(jié)點(diǎn)重新可達(dá)，并且是master節(jié)點(diǎn)，但是長(zhǎng)時(shí)間沒(méi)有slave被提升為master來(lái)頂替它

PFAIL提升到FAIL使用的是一種弱協(xié)議：

節(jié)點(diǎn)收集的狀態(tài)不在同一時(shí)間點(diǎn)，我們會(huì)丟棄時(shí)間較早的報(bào)告信息，但是也只能保證節(jié)點(diǎn)的狀態(tài)在一段時(shí)間內(nèi)大部分master達(dá)成了一致
檢測(cè)到一個(gè)FAIL后，需要通知所有節(jié)點(diǎn)，但是沒(méi)有辦法保證每個(gè)節(jié)點(diǎn)都能成功收到消息

由于是弱協(xié)議，Redis Cluster只要求所有節(jié)點(diǎn)對(duì)某個(gè)節(jié)點(diǎn)的狀態(tài)最終保持一致。如果大部分master認(rèn)為某個(gè)節(jié)點(diǎn)FAIL，那么最終所有節(jié)點(diǎn)都會(huì)將其標(biāo)為FAIL。而如果只有一小部分master節(jié)點(diǎn)認(rèn)為某個(gè)節(jié)點(diǎn)FAIL，slave并不會(huì)被提升為master，因此，F(xiàn)AIL狀態(tài)將會(huì)被清除。

搭建

原理說(shuō)了這么多，我們一定要來(lái)親自動(dòng)手搭建一個(gè)Redis Cluster，下面演示一個(gè)在一臺(tái)機(jī)器上模擬搭建3主3從的Redis Cluster。當(dāng)然，如果你想了解更多Redis Cluster的其他原理，可以點(diǎn)擊閱讀原文查看官網(wǎng)的介紹。

Redis環(huán)境

首先要搭建起我們需要的Redis環(huán)境，這里啟動(dòng)6個(gè)Redis實(shí)例，端口號(hào)分別是6379、6380、6479、6480、6579、6580

拷貝6份Redis配置文件并進(jìn)行如下修改（以6379為例，端口號(hào)和配置文件根據(jù)需要修改）：

1port 6379

2cluster-enabled yes

3cluster-config-file nodes6379.conf

4Appendonly yes

配置文件的名稱也需要修改，修改完成后，分別啟動(dòng)6個(gè)實(shí)例（圖片中有一個(gè)端口號(hào)改錯(cuò)了……）。

Redis instances

創(chuàng)建Redis Cluster

實(shí)例啟動(dòng)完成后，就可以創(chuàng)建Redis Cluster了，如果Redis的版本是3.x或4.x，需要使用一個(gè)叫做redis-trib的工具，而對(duì)于Redis5.0之后的版本，Redis Cluster的命令已經(jīng)集成到了redis-cli中了。這里我用的是Redis5，所以沒(méi)有再單獨(dú)安裝redis-trib工具。

接下來(lái)執(zhí)行命令

1redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6479 127.0.0.1:6480 127.0.0.1:6579 127.0.0.1:6580 --cluster-replicas 1

當(dāng)你看到輸出了

1[OK] All 16384 slots covered

就表示Redis Cluster已經(jīng)創(chuàng)建成功了。

查看節(jié)點(diǎn)信息

此時(shí)我們使用cluster nodes 命令就可查看Redis Cluster的節(jié)點(diǎn)信息了。