Redis 面試知識點筆記（七）pipeline及主從同步、集羣

問：redis的pipeline有什麼好處？

前面作測試數據的時候用到 cat /tmp/redisTest.txt | /redis-5.0/src/redis-cli -h 127.0.0.1 -p 6379 --pipe

就是一個pipeline管道批量執行指令，能夠節省屢次IO往返的時間，可是若是指令間有依賴建議分批發送

問：redis的同步機制？

主從同步原理，通常集羣都是一個主多個從，主負責寫，從負責讀。開始主節點會啓動命令開始全量同步，而後會啓動增量同步。

全同步過程：

1. Slave發送sync命令到Master
2. Master啓動一個後臺進程，將Redis中的數據快照保存到文件中（bgsave）
3. Master將保存的數據快照期間接收到的寫命令也緩存起來（增量數據緩存）
4. Master完成寫操做以後，將該文件發送給Slave
5. 使用新的AOF文件替換掉舊的AOF文件，而後寫入內存中，恢復數據快照
6. Master將這期間收集的增量寫命令也發送給Slave，Slave完成同步

增量同步過程：

1. Master接收到用戶的操做指令，判斷是否須要傳播到Slave
2. 將操做記錄追加到AOF文件
3. 將該操做傳播到其餘Slave ,對齊住從庫，往響應的緩存寫入指令
4. 將緩存中的數據發送給Slave

主從的弊端就是主服務器掛掉以後就不能進行寫操做了，因此就有了sentinel 哨兵

解決主從同步Master宕機後的主從切換問題：

• 監控：檢查主從服務器是否運行正常
• 提醒：經過API向管理員或者其餘應用程序發送故障通知
• 自動故障遷移：主從切換

流言協議Gossip，在雜亂無章中尋求一致（區塊鏈中有用到）：

• 每一個節點都隨機地與對方通訊，最終全部節點的狀態達成一致
• 種子節點按期隨機向其餘節點發送節點列表以及傳播的消息
• 不保證信息必定會傳播給全部節點，可是最終會趨於一致

 

Redis的集羣原理

問：如何從海量數據裏快速找到所需？

• 分片：按照某種規則去劃分數據，分散存儲在多個節點上
• 常規的按照哈希（按哈希值取模）劃分沒法實現節點的動態增減（當動態增長或減小節點的時候會致使大量的key沒法命中）

一致性哈希算法（哈希環）：對2^32次方取模，將哈希值的空間組織成虛擬圓環

當NodeC宕機了(在一致性哈希算法中，若是一臺服務器不能夠，其影響的只是此服務器到哈希環的前一臺服務器（逆時針方向上的第一臺）之間的數據，其餘數據不受影響，新增的數據也會到下一個節點，順時針的下一臺)

新增服務器NodeX （新增一臺服務器，受影響的只是新服務器到其環的前一臺服務器，逆時針第一臺之間的數據）

Hash環數據傾斜問題（大部分數據緩存到一個服務器上，分配不均勻）

一致性哈希又引入了虛擬節點解決數據傾斜的問題（一個節點計算多個hash值，結算結果位置放置一個虛擬節點，具體作法能夠在節點後面增長編號來實現）

在實際應用中把虛擬節點設置成32或更大，即便是不多的服務節點也能很好的數據分佈。