課程筆記第三次課分布式redis

1、集群先來(lái)簡(jiǎn)單了解下redis中提供的集群策略, 雖然redis有持久化功能能夠保障redis服務(wù)器宕機(jī)也能恢復(fù)并且只有少量的數(shù)據(jù)損失，但是由于所有數(shù)據(jù)在一臺(tái)服務(wù)器上，如果這臺(tái)服務(wù)器出現(xiàn)硬盤(pán)故障，那就算是有備份也仍然不可避免數(shù)據(jù)丟失的問(wèn)題。在實(shí)際生產(chǎn)環(huán)境中，我們不可能只使用一臺(tái)redis服務(wù)器作為我們的緩存服務(wù)器，必須要多臺(tái)實(shí)現(xiàn)集群，避免出現(xiàn) 單點(diǎn)故障；主從復(fù)制復(fù)制的作用是把redis的數(shù)據(jù)庫(kù)復(fù)制多個(gè)副本部署在不同的服務(wù)器上，如果其中一臺(tái)服務(wù)器出現(xiàn)故障，也能快速遷移到其他服務(wù)器上提供服務(wù)。 復(fù)制功能可以實(shí)現(xiàn)當(dāng)一臺(tái)redis服務(wù)器的數(shù)據(jù)更新后，自動(dòng)將新的數(shù)據(jù)同步到其他服務(wù)器上主從復(fù)制就是我們常見(jiàn)的

2、master/slave模式，主數(shù)據(jù)庫(kù)可以進(jìn)行讀寫(xiě)操作，當(dāng)寫(xiě)操作導(dǎo)致數(shù)據(jù)發(fā)生變化時(shí)會(huì)自動(dòng)將數(shù)據(jù)同步給從數(shù)據(jù)庫(kù)。而一般情況下，從數(shù)據(jù)庫(kù)是只讀的，并接收主數(shù)據(jù)庫(kù)同步過(guò)來(lái)的數(shù)據(jù)。 個(gè)從數(shù)據(jù)庫(kù)一個(gè)主數(shù)據(jù)庫(kù)可以有多配置在redis中配置master/slave是非常容易的，只需要在從數(shù)據(jù)庫(kù)的配置文件中加入slaveof 主數(shù)據(jù)庫(kù)地址 端口。 而master 數(shù)據(jù)庫(kù)不需要做任何改變準(zhǔn)備兩臺(tái)服務(wù)器，分別安裝redis ， server1 server21.在server2的redis.conf文件中增加 slaveof server1-ip 6379 、 同時(shí)將bindip注釋掉，允許所有ip訪(fǎng)問(wèn)2.啟動(dòng)s

3、erver23.訪(fǎng)問(wèn)server2的redis客戶(hù)端，輸入 INFO replication4.通過(guò)在master機(jī)器上輸入命令，比如set foo bar 、 在slave服務(wù)器就能看到該值已經(jīng)同步過(guò)來(lái)了原理全量復(fù)制Redis全量復(fù)制一般發(fā)生在Slave初始化階段，這時(shí)Slave需要將Master上的所有數(shù)據(jù)都復(fù)制一份。具體步驟完成上面幾個(gè)步驟后就完成了slave服務(wù)器數(shù)據(jù)初始化的所有操作，savle服務(wù)器此時(shí)可以接收來(lái)自用戶(hù)的讀請(qǐng)求。master/slave 復(fù)制策略是采用樂(lè)觀復(fù)制，也就是說(shuō)可以容忍在一定時(shí)間內(nèi)master/slave數(shù)據(jù)的內(nèi)容是不同的，但是兩者的數(shù)據(jù)會(huì)最終同步。具體來(lái)說(shuō)，

4、redis的主從同步過(guò)程本身是異步的，意味著master執(zhí)行完客戶(hù)端請(qǐng)求的命令 后會(huì)立即返回結(jié)果給客戶(hù)端，然后異步的方式把命令同步給slave。這一特征保證啟用master/slave后 master的性能不會(huì)受到影響。但是另一方面，如果在這個(gè)數(shù)據(jù)不一致的窗口期間，master/slave因?yàn)榫W(wǎng)絡(luò)問(wèn)題斷開(kāi)連接，而這個(gè)時(shí)候，master 是無(wú)法得知某個(gè)命令最終同步給了多少個(gè)slave數(shù)據(jù)庫(kù)。不過(guò)redis提供了一個(gè)配置項(xiàng)來(lái)限制只有數(shù)據(jù)至少同步給多少個(gè)slave的時(shí)候，master才是可寫(xiě)的：表示只有當(dāng)3個(gè)或以上的slave連接到master，master才是可寫(xiě)的表示允許slave最長(zhǎng)失去連接的

5、時(shí)間，如果10秒還沒(méi)收到slave的響應(yīng)，則master認(rèn)為該slave以斷開(kāi)增量復(fù)制從redis2.8開(kāi)始，就支持主從復(fù)制的斷點(diǎn)續(xù)傳，如果主從復(fù)制過(guò)程中，網(wǎng)絡(luò)連接斷掉了，那么可以接著上次復(fù)制的 地方，繼續(xù)復(fù)制下去，而不是從頭開(kāi)始復(fù)制一份masternode會(huì)在內(nèi)存中創(chuàng)建一個(gè)backlog，master和slave都會(huì)保存一個(gè)replicaoset還有一個(gè)masterid，oset就是保存在backlog中的。如果master和slave網(wǎng)絡(luò)連接斷掉了，slave會(huì)讓master從上次的replica 復(fù)制但是如果沒(méi)有找到對(duì)應(yīng)的oset，那么就會(huì)執(zhí)行一次全量同步oset開(kāi)始繼續(xù)mlaves-m

6、ax-lag 10mlaves-to-write 3無(wú)硬盤(pán)復(fù)制前面我們說(shuō)過(guò)，Redis復(fù)制的工作原理基于RDB方式的持久化實(shí)現(xiàn)的，也就是master在 收到rdb文件并載入，但是這種方式會(huì)存在一些問(wèn)題保存RDB快照，slave接1. 當(dāng)master禁用RDB時(shí)，如果執(zhí)行了復(fù)制初始化操作，Redis依然會(huì)生成RDB快照，當(dāng)master下次啟動(dòng)時(shí)執(zhí)行該RDB文件的恢復(fù)，但是因?yàn)閺?fù)制發(fā)生的時(shí)間點(diǎn)不確定，所以恢復(fù)的數(shù)據(jù)可能是任何時(shí)間點(diǎn)的。就會(huì)造成數(shù)據(jù)出現(xiàn)問(wèn) 題2. 當(dāng)硬盤(pán)性能比較慢的情況下（網(wǎng)絡(luò)硬盤(pán)），那初始化復(fù)制過(guò)程會(huì)對(duì)性能產(chǎn)生影響因此2.8.18以后的版本，Redis引入了無(wú)硬盤(pán)復(fù)制選項(xiàng)，可以不需

7、要通過(guò)RDB文件去同步，直接發(fā)送數(shù)據(jù)，通過(guò)以 下配置來(lái)開(kāi)啟該功能repl-diskless-sync yesmaster*在內(nèi)存中直接創(chuàng)建rdb，然后發(fā)送給slave，不會(huì)在自己本地落地磁盤(pán)了 哨兵機(jī)制在前面講的master/slave模式，在一個(gè)典型的一主多從的系統(tǒng)中，slave在整個(gè)體系中起到了數(shù)據(jù)冗余備份和讀寫(xiě)分離的作用。當(dāng)master遇到異常終端后，需要從slave中選舉一個(gè)新的master繼續(xù)對(duì)外提供服務(wù)，這種機(jī)制在前面 提到過(guò)N次，比如在zk中通過(guò)leader選舉、kafka中可以基于zk的節(jié)點(diǎn)實(shí)現(xiàn)master選舉。所以在redis中也需要一種機(jī)制去實(shí)現(xiàn)master的決策，redi

8、s并沒(méi)有提供自動(dòng)master選舉功能，而是需要借助一個(gè)哨兵來(lái)進(jìn)行監(jiān)控什么是哨兵顧名思義，哨兵的作用就是監(jiān)控Redis系統(tǒng)的運(yùn)行狀況，它的功能包括兩個(gè)1. 監(jiān)控master和slave是否正常運(yùn)行2. master出現(xiàn)故障時(shí)自動(dòng)將slave數(shù)據(jù)庫(kù)升級(jí)為master哨兵是一個(gè)獨(dú)立的進(jìn)程，使用哨兵后的架構(gòu)圖為了解決master選舉問(wèn)題，又引出了一個(gè)單點(diǎn)問(wèn)題，也就是哨兵的可用性如何解決，在一個(gè)一主多從的Redis系統(tǒng)中，可以使用多個(gè)哨兵進(jìn)行監(jiān)控任務(wù)以保證系統(tǒng)足夠穩(wěn)定。此時(shí)哨兵不僅會(huì)監(jiān)控master和slave，同時(shí)還會(huì)互相監(jiān)控；這種方式稱(chēng)為哨兵集群，哨兵集群需要解決故障發(fā)現(xiàn)、和master決策的協(xié)商機(jī)

9、制問(wèn)題為了解決master選舉問(wèn)題，又引出了一個(gè)單點(diǎn)問(wèn)題，也就是哨兵的可用性如何解決，在一個(gè)一主多從的Redis系統(tǒng)中，可以使用多個(gè)哨兵進(jìn)行監(jiān)控任務(wù)以保證系統(tǒng)足夠穩(wěn)定。此時(shí)哨兵不僅會(huì)監(jiān)控master和slave，同時(shí)還會(huì)互相監(jiān)控；這種方式稱(chēng)為哨兵集群，哨兵集群需要解決故障發(fā)現(xiàn)、和master決策的協(xié)商機(jī)制問(wèn)題sentinel之間的相互感知sentinel節(jié)點(diǎn)之間會(huì)因?yàn)楣餐O(jiān)視同一個(gè)master從而產(chǎn)生了關(guān)聯(lián)，一個(gè)新加入的sentinel節(jié)點(diǎn)需要和其他監(jiān)視相同master節(jié)點(diǎn)的sentinel相互感知，首先1. 需要相互感知的sentinel都向他們共同監(jiān)視的master節(jié)點(diǎn)訂閱channel:

10、sentinel:hello2. 新加入的sentinel節(jié)點(diǎn)向這個(gè)channel發(fā)布一條消息，包含自己本身的信息，這樣訂閱了這個(gè)channel的sentinel 就可以發(fā)現(xiàn)這個(gè)新的sentinel3. 新加入得sentinel和其他sentinel節(jié)點(diǎn)建立長(zhǎng)連接master的故障發(fā)現(xiàn)sentinel節(jié)點(diǎn)會(huì)定期向master節(jié)點(diǎn)發(fā)送心跳包來(lái)判斷存活狀態(tài)，一旦master節(jié)點(diǎn)沒(méi)有正確響應(yīng)，sentinel會(huì)把master設(shè)置為“主觀不可用狀態(tài)”，然后它會(huì)把“主觀不可用”發(fā)送給其他所有的sentinel節(jié)點(diǎn)去確認(rèn)，當(dāng)確認(rèn)的sentinel節(jié)點(diǎn)數(shù)大于quorum時(shí)，則會(huì)認(rèn)為master是“客觀不可用

11、”，接著就開(kāi)始進(jìn)入選舉新的master流程；但是 這里又會(huì)遇到一個(gè)問(wèn)題，就是sentinel中，本身是一個(gè)集群，如果多個(gè)節(jié)點(diǎn)同時(shí)發(fā)現(xiàn)master節(jié)點(diǎn)達(dá)到客觀不可用狀態(tài)，那誰(shuí)來(lái)決策選擇哪個(gè)節(jié)點(diǎn)作為maste呢？這個(gè)時(shí)候就需要從sentinel集群中選擇一個(gè)leader來(lái)做決策。而這里 用到了一致性算法Raft算法、它和Paxos算法類(lèi)似，都是分布式一致性算法。但是它比Paxos算法要更容易理解； Raft和Paxos算法一樣，也是基于投票算法，只要保證過(guò)半數(shù)節(jié)點(diǎn)通過(guò)提議即可;動(dòng)畫(huà)演示地址：/raft/配置實(shí)現(xiàn)通過(guò)在這個(gè)配置的基礎(chǔ)上增加哨

12、兵機(jī)制。在其中任意一臺(tái)服務(wù)器上創(chuàng)建一個(gè)sentinel.conf文件，文件內(nèi)容sentinel monitor name ip port quorum其中name表示要監(jiān)控的master的名字，這個(gè)名字是自己定義。 ip和port表示master的ip和端 通過(guò)票數(shù)，也就是說(shuō)至少需要幾個(gè)哨兵節(jié)點(diǎn)統(tǒng)一才可以，后面會(huì)具體講解 。 最后一個(gè)1表示最低port 6040sentinel monitor mymaster 31 6379 1sentinel down-after-milliseconds mymaster 5000 -表示如果5s內(nèi)mymaster沒(méi)響應(yīng)，就認(rèn)為S

13、DOWNsentinel failover-timeout mymaster 15000 -表示如果15秒后,mysater仍沒(méi)活過(guò)來(lái)，則啟動(dòng)failover，從剩下的slave中選一個(gè)升級(jí)為master兩種方式啟動(dòng)哨兵redis-sentinel sentinel.confredis-server /path/to/sentinel.conf -sentinel哨兵監(jiān)控一個(gè)系統(tǒng)時(shí)，只需要配置監(jiān)控master即可，哨兵會(huì)自動(dòng)發(fā)現(xiàn)所有slave；這時(shí)候，我們把master關(guān)閉，等待指定時(shí)間后（默認(rèn)是30秒），會(huì)自動(dòng)進(jìn)行切換，會(huì)輸出如下消息img+sdown表示哨兵主管認(rèn)為master已經(jīng)停止服務(wù)

14、了，+odown表示哨兵客觀認(rèn)為master停止服務(wù)了。關(guān)于主觀和客 觀，后面會(huì)給大家講解。接著哨兵開(kāi)始進(jìn)行故障恢復(fù)，挑選一個(gè)slave升級(jí)為master+try-failover表示哨兵開(kāi)始進(jìn)行故障恢復(fù)+failover-end 表示哨兵完成故障恢復(fù)+slave表示列出新的master和slave服務(wù)器，我們?nèi)匀豢梢钥吹揭呀?jīng)停掉的master，哨兵并沒(méi)有清楚已停止的服務(wù) 的實(shí)例，這是因?yàn)橐呀?jīng)停止的服務(wù)器有可能會(huì)在某個(gè)時(shí)間進(jìn)行恢復(fù)，恢復(fù)以后會(huì)以slave角色加入到整個(gè)集群中Redis-Cluster即使是使用哨兵，此時(shí)的Redis集群的每個(gè)數(shù)據(jù)庫(kù)依然存有集群中的所有數(shù)據(jù)，從而導(dǎo)致集群的總數(shù)據(jù)存

15、儲(chǔ)量受限于可用存儲(chǔ)內(nèi)存最小的節(jié)點(diǎn)，形成了木桶效應(yīng)。而因?yàn)镽edis是基于內(nèi)存存儲(chǔ)的，所以這一個(gè)問(wèn)題在redis中就顯得尤為突出了在redis3.0之前，我們是通過(guò)在客戶(hù)端去做的分片，通過(guò)hash環(huán)的方式對(duì)key進(jìn)行分片存儲(chǔ)。分片雖然能夠解決各 個(gè)節(jié)點(diǎn)的存儲(chǔ)壓力，但是導(dǎo)致維護(hù)成本高、增加、移除節(jié)點(diǎn)比較繁瑣。因此在redis3.0以后的版本最大的一個(gè)好處就是支持集群功能，集群的特點(diǎn)在于擁有和單機(jī)實(shí)例一樣的性能，同時(shí)在網(wǎng)絡(luò)分區(qū)以后能夠提供一定的可訪(fǎng)問(wèn)性以及對(duì)主數(shù)據(jù)庫(kù)故障恢復(fù)的支持。哨兵和集群是兩個(gè)獨(dú)立的功能，當(dāng)不需要對(duì)數(shù)據(jù)進(jìn)行分片使用哨兵就夠了，如果要進(jìn)行水平擴(kuò)容，集群是一個(gè)比較 好的方式拓?fù)浣Y(jié)構(gòu)一

16、個(gè)Redis Cluster由多個(gè)Redis節(jié)點(diǎn)構(gòu)成。不同節(jié)點(diǎn)組服務(wù)的數(shù)據(jù)沒(méi)有交集，也就是每個(gè)一節(jié)點(diǎn)組對(duì)應(yīng)數(shù)據(jù)sharding的一個(gè)分片。節(jié)點(diǎn)組內(nèi)部分為主備兩類(lèi)節(jié)點(diǎn)，對(duì)應(yīng)master和slave節(jié)點(diǎn)。兩者數(shù)據(jù)準(zhǔn)實(shí)時(shí)一致，通過(guò)異步化的主備復(fù)制機(jī)制來(lái)保證。一個(gè)節(jié)點(diǎn)組有且只有一個(gè)master節(jié)點(diǎn)，同時(shí)可以有0到多個(gè)slave節(jié)點(diǎn)，在這個(gè)節(jié)點(diǎn)組中master節(jié)點(diǎn)對(duì)用戶(hù)提供些服務(wù)，讀服務(wù)可以由master或者slave提供只有3.pngredis-cluster是基于gossip協(xié)議實(shí)現(xiàn)的無(wú)中心化節(jié)點(diǎn)的集群，因?yàn)槿ブ行幕募軜?gòu)不存在統(tǒng)一的配置中心，各個(gè)節(jié) 點(diǎn)對(duì)整個(gè)集群狀態(tài)的認(rèn)知來(lái)自于節(jié)點(diǎn)之間的信息交互。

17、在Redis Cluster，這個(gè)信息交互是通過(guò)Redis Cluster Bus來(lái)完成的Redis的數(shù)據(jù)分區(qū)分布式數(shù)據(jù)庫(kù)首要解決把整個(gè)數(shù)據(jù)集按照分區(qū)規(guī)則映射到多個(gè)節(jié)點(diǎn)的問(wèn)題，即把數(shù)據(jù)集劃分到多個(gè)節(jié)點(diǎn)上，每個(gè)節(jié)點(diǎn)負(fù)責(zé)整個(gè)數(shù)據(jù)的一個(gè)子集, Redis Cluster采用哈希分區(qū)規(guī)則,采用虛擬槽分區(qū)。虛擬槽分區(qū)巧妙地使用了哈?？臻g，使用分散度良好的哈希函數(shù)把所有的數(shù)據(jù)映射到一個(gè)固定范圍內(nèi)的整數(shù)集合， 整數(shù)定義為槽（slot）。比如Redis Cluster槽的范圍是0 16383。槽是集群內(nèi)數(shù)據(jù)管理和遷移的基本單位。采用大范圍的槽的主要目的是為了方便數(shù)據(jù)的拆分和集群的擴(kuò)展，每個(gè)節(jié)點(diǎn)負(fù)責(zé)一定數(shù)量的槽

18、。計(jì)算公式：slot = CRC16(key)%16383。每一個(gè)節(jié)點(diǎn)負(fù)責(zé)維護(hù)一部分槽以及槽所映射的鍵值數(shù)據(jù)。HashTags通過(guò)分片手段，可以將數(shù)據(jù)合理的劃分到不同的節(jié)點(diǎn)上，這本來(lái)是一件好事。但是有的時(shí)候，我們希望對(duì)相關(guān)聯(lián)的 業(yè)務(wù)以原子方式進(jìn)行操作。舉個(gè)簡(jiǎn)單的例子我們?cè)趩喂?jié)點(diǎn)上執(zhí)行MSET , 它是一個(gè)原子性的操作，所有給定的key會(huì)在同一時(shí)間內(nèi)被設(shè)置，不可能出現(xiàn)某些指定的key被更新另一些指定的key沒(méi)有改變的情況。但是在集群環(huán)境下，我們?nèi)匀豢梢詧?zhí)行MSET命令，但它的操作不 在是原子操作，會(huì)存在某些指定的key被更新，而另外一些指定的key沒(méi)有改變，原因是多個(gè)key可能會(huì)被分配到不同的機(jī)

19、器上。所以，這里就會(huì)存在一個(gè)矛盾點(diǎn)，及要求key盡可能的分散在不同機(jī)器，又要求某些相關(guān)聯(lián)的key分配到相同機(jī)器。 這個(gè)也是在面試的時(shí)候會(huì)容易被問(wèn)到的內(nèi)容。怎么解決呢？從前面的分析中我們了解到，分片其實(shí)就是一個(gè)hash的過(guò)程，對(duì)key做hash取模然后劃分到不同的機(jī)器上。所以為了解決這個(gè)問(wèn)題，我們需要考慮如何讓相關(guān)聯(lián)的key得到的hash值都相同呢？如果key全部相同是不現(xiàn)實(shí)的，所以 怎么解決呢？在redis中引入了HashTag的概念，可以使得數(shù)據(jù)分布算法可以根據(jù)key的某一個(gè)部分進(jìn)行計(jì)算，然后 讓相關(guān)的key落到同一個(gè)數(shù)據(jù)分片舉個(gè)簡(jiǎn)單的例子，加入對(duì)于用戶(hù)的信息進(jìn)行存儲(chǔ)， user:user1

20、:id、user:user1:name/ 那么通過(guò)hashtag的方式，user:user1:id、user:; 表示當(dāng)一個(gè)key包含 的時(shí)候，就不對(duì)整個(gè)key做hash，而僅對(duì) 包括的字符串做hash。重定向客戶(hù)端Redis Cluster并不會(huì)查詢(xún)，那么如果客戶(hù)端訪(fǎng)問(wèn)了一個(gè)key并不存在的節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)是怎么處理的呢？比如我想獲取key為msg的值，msg計(jì)算出來(lái)的槽編號(hào)為254，當(dāng)前節(jié)點(diǎn)正好不負(fù)責(zé)編號(hào)為254的槽，那么就會(huì)返回客戶(hù) 端下面信息：-MOVED 254 :6381表示客戶(hù)端想要的254槽由運(yùn)行在IP為，端口為6381的M

21、aster實(shí)例服務(wù)。如果根據(jù)key計(jì)算得出的槽恰好 由當(dāng)前節(jié)點(diǎn)負(fù)責(zé)，則當(dāng)期節(jié)點(diǎn)會(huì)立即返回結(jié)果分片遷移在一個(gè)穩(wěn)定的Redis cluster下，每一個(gè)slot對(duì)應(yīng)的節(jié)點(diǎn)是確定的，但是在某些情況下，節(jié)點(diǎn)和分片對(duì)應(yīng)的關(guān)系會(huì)發(fā)生變更1. 新加入master節(jié)點(diǎn)2. 某個(gè)節(jié)點(diǎn)宕機(jī)也就是說(shuō)當(dāng)動(dòng)態(tài)添加或減少node節(jié)點(diǎn)時(shí)，需要將16384個(gè)槽做個(gè)再分配，槽中的鍵值也要遷移。當(dāng)然，這一過(guò)程， 在目前實(shí)現(xiàn)中，還處于半自動(dòng)狀態(tài)，需要人工介入。新增一個(gè)主節(jié)點(diǎn)新增一個(gè)節(jié)點(diǎn)D，redis cluster的這種做法是從各個(gè)節(jié)點(diǎn)的前面各拿取一部分slot到D上。大致就會(huì)變成這樣： 節(jié)點(diǎn)A覆蓋1365-5460節(jié)點(diǎn)B覆蓋6827-10922 節(jié)點(diǎn)C覆蓋12288-16383節(jié)點(diǎn)D覆蓋0-1364,5461-6826,10923-12287刪除一個(gè)主節(jié)點(diǎn)先將節(jié)點(diǎn)的數(shù)據(jù)移動(dòng)到其他節(jié)點(diǎn)上，然后才能執(zhí)行刪除槽遷移的過(guò)程槽遷移的過(guò)程中有一個(gè)不穩(wěn)定狀態(tài)，這個(gè)不穩(wěn)定狀態(tài)會(huì)有一些規(guī)則，這些規(guī)則定義客戶(hù)端的行為，從而使得Redis Cluster不必宕機(jī)的情況下可以執(zhí)行槽的遷移。下面這張圖描述了我們遷移編號(hào)為1、2、3的槽的過(guò)程中，他們?cè)贛asterA節(jié)點(diǎn)和MasterB節(jié)點(diǎn)中的狀態(tài)。簡(jiǎn)