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