redis通訊與高可用集羣原理
上一篇文章介紹了 單機版的redis的持久化與過期鍵刪除原理
現在將粗略介紹一下集羣的redis的通訊與集羣的原理
，好！廢話不多說，讓我們開始吧。。。
redis通訊
redis是一個小系統，那麼爲了讓這個系統可以穩定地工作，通訊便是不可缺少的功能，redis的通訊通過事件機制來實現，它的事件有兩種，文件事件和時間事件
文件事件
文件事件主要用於執行命令，如寫入寫出等。。文件事件通過套接字來進行通訊，套接字裏面說明了這個事件具體是什麼，見下圖
由圖我們可以知道，redis的文件事件處理器由以下部分組成
1、套接字：用於按照一定的規則封裝事件的任務。
2、I/O多路複用程序：文件事件處理器使用I/O多路複用程序來監聽多個套接字，並根據套接字所執行的任務爲套接字 關聯不同的事件處理器
3、文件事件分派器：文件事件分派器將將所有的文件事件放在一個隊列裏面，然後逐個取出交給事件處理器處理，所以說redis是單線程的
4、事件處理器：處理事件
時間事件
時間事件分爲定時事件和週期性事件
1、定時事件：讓程序在指定時間執行的定時任務
2、週期性事件：週期性執行的事件，如過期鍵刪除中的定期刪除
3、時間事件的實現
服務器將所有的時間事件放在一個無序的鏈表（不按照when來進行排序），每當時間事件執行器運行，就遍歷這個隊列查找已經到時間的事件然後調用相應的處理器進行處理
事件調度
在文件事件和時間事件同時存在的時候，如何進行調度？
1、首先文件事件是只要有文件事件到達就馬上執行
2、對於時間事件它的執行方式則是
- 2-1 獲取最快要開始執行的時間事件的時間
- 2-2 阻塞等待最近的需要執行的時間事件的到來
- 2-3 時間到來，執行時間事件
3、事件調度（文件事件與時間事件共存）–》aeProcessEvent 函數
函數的原理如圖（不貼代碼了）見它的原理圖
意思就是不斷處理文件事件，當時間事件到來則開始處理時間事件，沒有事件則進入阻塞狀態，不斷循環。但是需要注意的是，這些事件都不是搶佔式的，而是一個接着一個執行，當然，如果一個事件執行的時間超越某個臨界值的時候，這個事件會自動break，然後保存狀態等待下次執行
4、實例
上面解釋那麼多肯定都不如一個實例來得清楚，那麼讓我們來個實例
開始時間 結束時間 動作
0 10 創建一個在100毫秒執行的事件事件
11 30 等待文件事件
31 50 文件事件到達，處理文件事件
51 85 等待文件事件
85 130 文件事件到達，執行文件事件
130 150 處理時間事件（0毫秒創建的時間事件）
從上面的例子可以看出文件事件到來，且處理器空閒的話就立馬執行，時間事件在時間到來的時候，如果處理器空閒，則執行，處理器不空閒，需要等到當前文件事件執行完了之後才進行處理，而不進行搶佔式調度。
Redis集羣的原理
主從複製
在redis中，可以通過複製配置文件然後啓動一個新的redis（redis集羣搭建，下個文章講解），新的redis可用通過slaveof命令讓一個服務器成爲另個服務器的從服務器，現在先讓我們從單個主機和單個從機的簡單的情況探討redis集羣中的集羣與數據一致性（基於redis2.8以上的版本）
redis主從複製分爲兩部分同步與命令傳播
爲了簡單說明，我將從一條時間線進行說明
初次進行主從複製–>redis運行中命令同步–>redis宕機重啓後數據同步
1、初次主從複製
當從機剛剛啓動，則它需要從主機同步數據，也就是將主機的數據同步一份給從機，首先主機收到salveof命令後，
- 主機以當前狀態爲節點運行BGSAVE命令，生成一個RDB文件然後發給從機
- 主機生成一個緩衝區記錄從當前開始所執行的命令
- 從機先拿到主機發來的RDB文件進行同步
- 從機拿到緩衝區裏面的命令，然後執行，至此，同步完成，這種方式也叫做“同步”
2、redis運行中命令同步
對於運行中同步，redis採用偏移量機制和複製積壓緩衝區機制
2-1偏移量機制
主從同步完成後，主從均記錄一個變量offset，每執行一條命令，offest加1，從機也是如此，故而只要比較主機和從機的offest的大小，主機offest減去從機offest就知道他們兩差幾條數據
2-2複製積壓緩衝區機制
redis中有一個複製積壓緩衝區，他的大小默認爲1m，採用先進先出的方式記錄最近執行的命令，當命令還未到1m則往裏面不斷放入最近執行的命令，大於1m後拋棄最老的命令，放入最新的命令
2-3同步
- 計算偏移量：主機offest減從機offest中得到主從相差幾條數據；
- 主機通過偏移量從複製積壓緩衝區裏面取從機缺少的那幾條數據發給從機；
- 從機執行後便完成同步，這便是命令傳播
3、宕機後同步
主機宕機，則從機上位，成爲新的主機，然後老的主機啓動成爲從機，從機宕機則啓動還是從機，這兩種情況均會導致主從不一致，那麼這種情況下:同步方案如下
- 通過offest得到主從之間差了多少條命令，
- 如果偏移量差不大於複製積壓緩衝區大小，也就是宕機丟失的命令在複製積壓緩衝區裏面還能找到，則拿出裏面的命令執行一遍就可以恢復，
- 如果已經超出了複製積壓緩衝區大小，則需要進行RDB來進行同步，也就是和初次同步時那樣。
redis集羣
這是一篇理論性的文章，那麼集羣搭建的過程我將在下一篇文章裏面進行介紹，假設我們已經有一個集羣，三主三從，分別爲7001、7002、7003、7004、7005、7006
1、內存地址管理
在進行集羣后，redis默認將整個內存非爲16384塊（也可以自己分），也就是0-16383，在進行搭建的時候，我們可以指定每組主機管理的地址，最終會形成一個表，如下
它記錄了每個主機所處理的地址
如
7001處理0-5000
7002處理5001-10000
7002處理10001-16383
2命令處理
我們知道redis集羣裏面任何一個主機都可以處理所有命令，那麼他們是如何做到的呢
看圖
命令到來，先通過CRC16算法算出這條命令具體要對那個槽做操作，如果就是這個主節點管理的曹，則處理，如果不是，則先執行move命令，跳轉到正確的主節點，然後執行命令
3、宕機與選舉
當主機宕機後，從機如何變成主機，就需要進行選舉，選舉是一個很有趣的過程，首先需要明白一點，就是主機纔有投票的權力
例子
就以上面三主三從爲例，假設7001宕機，選舉如下
- 從機7004將通過廣播向集羣發送一條消息，意思就是爲自己拉票，
- 如果此時主機還沒有套票給其他從機則這個主機會將票投給第一個向他拉票的從機，
- 如果有一個從機得到半數主機以上的票則當選爲新的主機（假設除去已經宕機的主機還有N個主機，則從機需要得到N/2+1的票才能當選爲主機）
- 至此新主機上位，原來的主機會重啓變爲從機
合理性
這種選舉看起來有點隨便呀，真是這樣？仔細一想，其實這種選舉方式恰好選舉出了網絡狀態最好的從機，是很不錯的選舉
一些需要避免的問題----》選舉失敗，從機無法變爲主機
例子
看上圖，假設03主機宕機，那麼就可能出現主機選舉失敗的可能
06 和 07 均廣播拉票，如果主機01將票給了06，主機02將票給了07，那麼兩個從機均得到一票，均不滿足N/2+1的票,兩個都不能當選，故而選舉失敗，這種錯誤是可以人爲避免的。
4、可用性分析
4-1 穩定性
就以剛纔的三主三從爲例，他的生存能力已經非常的強，任何一臺機子宕機都不會導致整個集羣不可用，當然有種情況就是某個集羣的某一組主機和從機全部宕機，那麼就會導致集羣不可用，如01和04同時宕機，那麼這組主從管理的0-5000這5001個槽將不能被管理，導致集羣不可用
4-2 可用性
在設置集羣之後，主機主要負責寫，而從機負責讀，實現讀寫分離，大大加強了redis性能。
總結
前面的連篇文章都只是介紹了redis的一些原理，下一篇文章我將從實踐的角度開始介紹集羣的搭建和使用，喜歡的話可以關注一下呦，您的關注是我前進的動力
廣州蘆葦科技Java開發團隊
蘆葦科技-廣州專業互聯網軟件服務公司
抓住每一處細節 ，創造每一個美好
關注我們的公衆號，瞭解更多
想和我們一起奮鬥嗎？lagou搜索“ 蘆葦科技 ”或者投放簡歷到 [email protected] 加入我們吧
關注我們，你的評論和點贊對我們最大的支持