建站
咨詢
售后
建站咨詢
新聞中心
大家好，我是樓仔！
在濟(jì)南等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站設(shè)計、成都做網(wǎng)站 網(wǎng)站設(shè)計制作按需網(wǎng)站建設(shè),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,網(wǎng)絡(luò)營銷推廣,成都外貿(mào)網(wǎng)站建設(shè)公司,濟(jì)南網(wǎng)站建設(shè)費(fèi)用合理。
Redis 的高可用，太重要啦！之前找工作面試，這個問題面試的頻率都能排到前幾，尤其是一些大廠，先不要著急看文章，如果面試官給你拋這么個問題，你會怎么回答呢，可以先想 5 分鐘。
這里要等待 5 分鐘 ...
其實我也可以偷個懶，完全轉(zhuǎn)載其它博客，但是沒有找到我想要的，為了不辜負(fù)廣大粉絲，樓哥還是單獨(dú)給大家寫一篇，主要根據(jù)這塊知識，再結(jié)合之前的一些面試情況，給大家嘮嘮。
1. Redis 分片策略
1.1 Hash 分片
我們都知道，對于 Reids 集群，我們需要通過 hash 策略，將 key 打在 Redis 的不同分片上。
假如我們有 3 臺機(jī)器，常見的分片方式為 hash(IP)%3，其中 3 是機(jī)器總數(shù)。
目前很多小公司都這么玩，上手快，簡單粗暴，但是這種方式有一個致命的缺點(diǎn)：當(dāng)增加或者減少緩存節(jié)點(diǎn)時，總節(jié)點(diǎn)個數(shù)發(fā)生變化，導(dǎo)致分片值發(fā)生改變，需要對緩存數(shù)據(jù)做遷移。
那如何解決該問題呢，答案是一致性 Hash。
1.2 一致性 Hash
一致性哈希算法是 1997 年由麻省理工學(xué)院提出的一種分布式哈希實現(xiàn)算法。
環(huán)形空間：按照常用的 hash 算法來將對應(yīng)的 key 哈希到一個具有 2^32 次方個桶的空間中，即 0~(2^32)-1 的數(shù)字空間中，現(xiàn)在我們可以將這些數(shù)字頭尾相連，想象成一個閉合的環(huán)形。
Key 散列 Hash 環(huán)：現(xiàn)在我們將 object1、object2、object3、object4 四個對象通過特定的 Hash 函數(shù)計算出對應(yīng)的 key 值，然后散列到 Hash 環(huán)上。
機(jī)器散列 Hash 環(huán)：假設(shè)現(xiàn)在有 NODE1、NODE2、NODE3 三臺機(jī)器，以順時針的方向計算，將所有對象存儲到離自己最近的機(jī)器中，object1 存儲到了 NODE1，object3 存儲到了 NODE2，object2、object4 存儲到了 NODE3。
節(jié)點(diǎn)刪除：如果 NODE2 出現(xiàn)故障被刪除了，object3 將會被遷移到 NODE3 中，這樣僅僅是 object3 的映射位置發(fā)生了變化，其它的對象沒有任何的改動。
添加節(jié)點(diǎn)：如果往集群中添加一個新的節(jié)點(diǎn) NODE4，object2 被遷移到了 NODE4 中，其它對象保持不變。
通過對節(jié)點(diǎn)的添加和刪除的分析，一致性哈希算法在保持了單調(diào)性的同時，還使數(shù)據(jù)的遷移達(dá)到了最小，這樣的算法對分布式集群來說是非常合適的，避免了大量數(shù)據(jù)遷移，減小了服務(wù)器的的壓力。
如果機(jī)器個數(shù)太少，為了避免大量數(shù)據(jù)集中在幾臺機(jī)器，實現(xiàn)平衡性，可以建立虛擬節(jié)點(diǎn)（比如一臺機(jī)器建立 3-4 個虛擬節(jié)點(diǎn)），然后對虛擬節(jié)點(diǎn)進(jìn)行 Hash。
2. 高可用方案
很多時候，公司只給我們提供一套 Redis 集群，至于如何計算分片，我們一般有 2 套成熟的解決方案。
客戶端方案：也就是客戶端自己計算 Redis 分片，無論你使用Hash 分片，還是一致性 Hash，都是由客戶端自己完成。
客戶端方案簡單粗暴，但是只能在單一語言系統(tǒng)之間復(fù)用，如果你使用的是 PHP 的系統(tǒng)，后來 Java 也需要使用，你需要用 Java 重新寫一套分片邏輯。
為了解決多語言、不同平臺復(fù)用的問題，就衍生出中間代理層方案。
中間代理層方案：將客戶端解決方案的經(jīng)驗移植到代理層中，通過通用的協(xié)議（如 Redis 協(xié)議）來實現(xiàn)在其他語言中的復(fù)用，用戶無需關(guān)心緩存的高可用如何實現(xiàn)，只需要依賴你的代理層即可。
代理層主要負(fù)責(zé)讀寫請求的路由功能，并且在其中內(nèi)置了一些高可用的邏輯。
你可以看看，你們公司的 Redis 使用的是哪種方案呢？對于“客戶端方案”，其實有的也不用自己去寫，比如負(fù)責(zé)維護(hù) Redis 的部門會提供不同語言的 SDK，你只需要去集成對應(yīng)的 SDK 即可。
3. 高可用原理
3.1 Redis 主從
Redis 基本都通過“主 - 從”模式進(jìn)行部署，主從庫之間采用的是讀寫分離的方式。
同 MySQL 類似，主庫支持寫和讀，從庫只支持讀，數(shù)據(jù)會先寫到主庫，然后定時同步給從庫，具體的同步規(guī)則，主要將 RDB 日志從主庫同步給從庫，然后從庫讀取 RDB 日志，這里比較復(fù)雜，其中還涉及到 replication buffer，就不再展開。
這里有個問題，一次同步過程中，主庫需要完成 2 個耗時操作：生成 RDB 文件和傳輸 RDB 文件。
如果從庫數(shù)量過多，主庫忙于 fock 子進(jìn)程生成 RDB 文件和數(shù)據(jù)同步，會阻塞主庫正常請求。
這個如何解決呢？答案是 “主 - 從 - 從” 模式。
為了避免所有從庫都從主庫同步 RDB 日志，可以借助從庫來完成同步：比如新增 3、4 兩個 Slave，可以等 Slave 2 同步完后，再通過 Slave 2 同步給 Slave 3 和 Slave 4。
如果我是面試官，我可能會繼續(xù)問，如果數(shù)據(jù)同步了 80%，網(wǎng)絡(luò)突然終端，當(dāng)網(wǎng)絡(luò)后續(xù)又恢復(fù)后，Redis 會如何操作呢？
3.2 Redis 分片
這個有點(diǎn)像 MySQL 分庫分表，將數(shù)據(jù)存儲到不同的地方，避免查詢時全部集中到一個實例。
其實還有一個好處，就是數(shù)據(jù)進(jìn)行主從同步時，如果 RDB 數(shù)據(jù)過大，會嚴(yán)重阻塞主線程，如果用分片的方式，可以將數(shù)據(jù)分?jǐn)?，比如原來?10 GB 的數(shù)據(jù)，分?jǐn)偤?，每個分片只有 2 GB。
可能有同學(xué)會問，Redis 分片，和“主 - 從”模式有啥關(guān)系呢？你可以理解，圖中的每個分片都是主庫，每個分片都有自己的“主 - 從”模式結(jié)構(gòu)。
那么數(shù)據(jù)如何找到對應(yīng)的分片呢，前面其實已經(jīng)講過，假如我們有 3 臺機(jī)器，常見的分片方式為 hash(IP)%3，其中 3 是機(jī)器總數(shù)，hash 值為機(jī)器 IP，這樣每臺機(jī)器就有自己的分片號。
對于 key，也可以采用同樣的方式，找到對應(yīng)的機(jī)器分片號 hash(key)%3，hash 算法有很多，可以用 CRC16(key)，也可以直接取 key 中的字符，通過 ASCII 碼轉(zhuǎn)換成數(shù)字。
3.3 Redis 哨兵機(jī)制
3.3.1 什么是哨兵機(jī)制 ？
在主從模式下，如果 master 宕機(jī)了，從庫不能從主庫同步數(shù)據(jù)，主庫也不能提供讀寫功能。
怎么辦呢 ？這時就需要引入哨兵機(jī)制 ！
哨兵節(jié)點(diǎn)是特殊的 Redis 服務(wù)，不提供讀寫服務(wù)，主要用來監(jiān)控 Redis 實例節(jié)點(diǎn)。
那么當(dāng) master 宕機(jī)，哨兵如何執(zhí)行呢？
3.3.2 判斷主機(jī)下線
哨兵進(jìn)程會使用 PING 命令檢測它自己和主、從庫的網(wǎng)絡(luò)連接情況，用來判斷實例的狀態(tài)，如果哨兵發(fā)現(xiàn)主庫或從庫對 PING 命令的響應(yīng)超時了，哨兵就會先把它標(biāo)記為“主觀下線”。
那是否一個哨兵判斷為“主觀下線”，就直接下線 master 呢？
答案肯定是不行的，需要遵循 “少數(shù)服從多數(shù)” 原則：有 N/2+1 個實例判斷主庫“主觀下線”，才判定主庫為“客觀下線”。
比如上圖有 3 個哨兵，有 2 個判斷 “主觀下線”，那么就標(biāo)記主庫為 “客觀下線”。
3.3.3 選取新主庫
我們有 5 個從庫，需要選取一個最優(yōu)的從庫作為主庫，分 2 步：
篩選：檢查從庫的當(dāng)前在線狀態(tài)和之前的網(wǎng)絡(luò)連接狀態(tài)，過濾不適合的從庫；
打分：根據(jù)從庫優(yōu)先級、和舊主庫的數(shù)據(jù)同步接近度進(jìn)行打分，選最高分作為主庫。
如果分?jǐn)?shù)一致怎么辦 ？ Redis 也有一個策略：ID 號最小的從庫得分最高，會被選為新主庫。
當(dāng) slave 3 選舉為新主庫后，會通知其它從庫和客戶端，對外宣布自己是新主庫，大家都得聽我的哈！
今天就講這么多，我們下期見，大家都學(xué)廢了么 ？
網(wǎng)頁標(biāo)題：聊聊Redis高可用原理
分享路徑：http://www.dlmjj.cn/article/djocpjg.html
