Redis基本原理
1、redis資料備份原理,RDB和AOF。
RDB:redis基於當前自身的所有資料所生成的資料快照,純粹的資料,若redis從rdb啟動,可直接載入使用。
AOF:類似redis日誌檔案,aof檔案內部是redis收到的寫命令,若redis從aof啟動,需要先讀aof檔案,然後執行裡面的命令,生產資料。
當觸發生成rdb時,redis會開啟後臺執行緒,生成一份rdb,觸發條件可以設定,類似隔多長時間或有多少資料改動時,生成rdb。
aof類似redis日誌,可控制寫入的頻率,如每秒寫入,當開啟aof時(預設關閉),redis內部維護一個aof檔案,實時將redis收到的寫命令寫入aof中。
aof由於不斷地寫入,會變得越來越大,當aof大小從0增大到設定的大小時,會觸發aof的第一次rewrite操作,redis會將基於當前的資料生成新的aof檔案,在此期間,如果redis收到新的寫命令,redis會將寫命令暫時儲存在記憶體,等新的aof完成後,再將記憶體中的命令追加到新aof中,當新aof完全完成後(假設大小為n),redis會刪除原aof檔案。當新的aof檔案不斷擴大到2n時(預設2倍),會觸發rewrite操作。
2、redis主從複製原理,斷點續傳和過期key處理
主從複製:redis主節點(master)向從節點(slave)複製資料,當叢集沒有任何問題正常運轉時,主節點將收到的如set,del等命令實時複製給從節點,從節點會讀命令並生產資料。當slave第一次連線master時,master後臺生成一份rdb,並等待一段時間,保證更多的slave接入,然後將rdb發給從節點,slave接到rdb後,首先在本地磁碟上備份,然後載入rdb。在此期間,master會將收到的寫命令先存在快取中,然後發給slave。
斷點續傳:master和slave內部都會維護一個backlog檔案,backlog裡面儲存一個offset資料,記錄複製資料位置。如果slave在工作中斷開一段時間又重新連線,會將自身的offset發給master進行對比,如果能在master找到對應的offset,則從offset開始複製,如果沒找到,則生成完整的rdb給slave。
過期key處理:master的key倍lru處理掉,會發del命令給slave。
3、redis哨兵底層原理(包括選舉演算法)
》1、sdown和odown轉換機制
sdown和odown兩種失敗狀態
sdown是主觀宕機,就一個哨兵如果自己覺得一個master宕機了,那麼就是主觀宕機
odown是客觀宕機,如果quorum數量的哨兵都覺得一個master宕機了,那麼就是客觀宕機
sdown達成的條件很簡單,如果一個哨兵ping一個master,超過了is-master-down-after-milliseconds指定的毫秒數之後,就主觀認為master宕機
sdown到odown轉換的條件很簡單,如果一個哨兵在指定時間內,收到了quorum指定數量的其他哨兵也認為那個master是sdown了,那麼就認為是odown了,客觀認為master宕機
。
》2、哨兵叢集的自動發現機制
哨兵互相之間的發現,是通過redis的pub/sub系統實現的,每個哨兵都會往__sentinel__:hello這個channel裡傳送一個訊息,這時候所有其他哨兵都可以消費到這個訊息,並感知到其他的哨兵的存在
每隔兩秒鐘,每個哨兵都會往自己監控的某個master+slaves對應的__sentinel__:hello channel裡傳送一個訊息,內容是自己的host、ip和runid還有對這個master的監控配置
每個哨兵也會去監聽自己監控的每個master+slaves對應的__sentinel__:hello channel,然後去感知到同樣在監聽這個master+slaves的其他哨兵的存在
每個哨兵還會跟其他哨兵交換對master的監控配置,互相進行監控配置的同步
。
》3、slave配置的自動糾正
哨兵會負責自動糾正slave的一些配置,比如slave如果要成為潛在的master候選人,哨兵會確保slave在複製現有master的資料; 如果slave連線到了一個錯誤的master上,比如故障轉移之後,那麼哨兵會確保它們連線到正確的master上。
》4、slave->master選舉演算法
如果一個master被認為odown了,而且majority哨兵都允許了主備切換,那麼某個哨兵就會執行主備切換操作,此時首先要選舉一個slave來
會考慮slave的一些資訊
(1)跟master斷開連線的時長
(2)slave優先順序
(3)複製offset
(4)run id
如果一個slave跟master斷開連線已經超過了down-after-milliseconds的10倍,外加master宕機的時長,那麼slave就被認為不適合選舉為master
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
接下來會對slave進行排序
(1)按照slave優先順序進行排序,slave priority越低,優先順序就越高
(2)如果slave priority相同,那麼看replica offset,哪個slave複製了越多的資料,offset越靠後,優先順序就越高
(3)如果上面兩個條件都相同,那麼選擇一個run id比較小的那個slave
》5、quorum和majority
每次一個哨兵要做主備切換,首先需要quorum數量的哨兵認為odown,然後選舉出一個哨兵來做切換,這個哨兵還得得到majority哨兵的授權,才能正式執行切換
如果quorum < majority,比如5個哨兵,majority就是3,quorum設定為2,那麼就3個哨兵授權就可以執行切換
但是如果quorum >= majority,那麼必須quorum數量的哨兵都授權,比如5個哨兵,quorum是5,那麼必須5個哨兵都同意授權,才能執行切換
》6、configuration epoch
哨兵會對一套redis master+slave進行監控,有相應的監控的配置
執行切換的那個哨兵,會從要切換到的新master(salve->master)那裡得到一個configuration epoch,這就是一個version號,每次切換的version號都必須是唯一的
如果第一個選舉出的哨兵切換失敗了,那麼其他哨兵,會等待failover-timeout時間,然後接替繼續執行切換,此時會重新獲取一個新的configuration epoch,作為新的version號
》7、configuraiton傳播
哨兵完成切換之後,會在自己本地更新生成最新的master配置,然後同步給其他的哨兵,就是通過之前說的pub/sub訊息機制
這裡之前的version號就很重要了,因為各種訊息都是通過一個channel去釋出和監聽的,所以一個哨兵完成一次新的切換之後,新的master配置是跟著新的version號的
其他的哨兵都是根據版本號的大小來更新自己的master配置的
。
4、資料分佈演算法,hash,一致性hash演算法,hash slot
一致性hash演算法要解決的問題:在多master叢集中,所有資料需要按照給定的規則存在固定的master中,保證要查詢的時候能知道在哪個master的從節點上。
最原始hash演算法:對key計算hashcode值,對master個數取餘數,得到master位置,類似hashmap。但是hashmap可以這麼做,因為hashmap不存在某個entry宕機的情況。這種做法如果某個master宕機,那麼取資料就會出錯。例如,有三個master,第二個master宕機,那麼第二個master的資料全丟失,而且master個數變成2,取資料時要除的數字變成2,存的時候除的數字是3,這樣肯定不能找到正確的master。
一致性hash演算法:一致性hash演算法引入和hash環的概念,所有的master均勻分佈在一個長度為(2^32-1)的圓環上,所有的K/V儲存時,都是將key的hashcode%(圓環長度),這個數字對應環上的位置順時針移動,打到哪個master,就存到其中。可以避免某一臺master宕機導致整個叢集不可用。
hash slot:redis叢集固定持有16384個hash slot(虛擬節點),K/V儲存時,對K的取CRC16%16384,找到對應的hash slot,儲存在hash slot上,叢集中每個master持有一部分hash slot,當某個master宕機,master上的hash slot會迅速轉移到其他master上,減小資料損失,而hash slot轉移的消耗是極低的。在讀取資料時,真正尋找的,是hash slot,與hash slot在哪個maste上無關,所以即便是master宕機了,上面的資料也不會全部消失,而且剩餘資料還能正常工作。