一、為什么redis集群的最大槽數是16384個？
2^14^=16384、2^16^=65536。
如果槽位是65536個，發送心跳信息的消息頭是65536/8/1024 = 8k。
如果槽位是16384個，發送心跳信息的消息頭是16384/8/1024 = 2k。
因為Redis每秒都會發送一定數量的心跳包，如果消息頭是8k，未免有些太大了，浪費網絡資源。
上面提過，Redis的集群主節點數量一般不會超過1000個。集群中節點越多，心跳包的消息體內的數據就越多，如果節點過多，也會造成網絡擁堵。因此Redis的作者Salvatore Sanfilippo不建議Redis Cluster的節點超過1000個，對于節點數在1000個以內的Redis Cluster，16384個槽位完全夠用。
Redis主節點的哈希槽信息是通過bitmap存儲的，在傳輸過程中，會對bitmap進行壓縮，bitmap的填充率越低，壓縮率越高。
bitmap 填充率 = slots / N (N表示節點數)。
也就是說slots越小，填充率就會越小，壓縮率就會越高，傳輸效率就會越高。?
二、Redis集群是什么？
由于數據量過大，單個master復制集難以承擔，因此需要多個master進行承擔工作，每個master存儲部分數據，這就是Redis集群。
Redis集群包含多個master，一個master對應多個slave，由于集群自帶故障轉移機制，因此Redis集群不用再使用哨兵sentinel功能。
Redis Cluster是Redis3.0引入的一種無中心化的集群，客戶端可以向任何一個節點通信，不同節點間的數據不互通，Redis Cluster將數據的key通過將CRC16算法的結果取模16383后，分給16384個slot槽，集群的每個節點負責一部分hash槽，節點只負責管理映射到這個槽的KV數據，對于不是當前槽的KV數據，會向客戶端發送一個MOVED，表示需要客戶端重新重定向到其它節點。
使用Redis集群時，我們將需要存儲的數據分配到多臺Redis服務器上，稱為分片。
數據如何分片？
對key進行CRC16(key)算法處理并通過對總分片數量取模，然后使用確定性哈希函數，將指定的key多次映射到同一個分片上。這種模式下，在進行服務器擴容的時候，不會影響集群的使用狀態。
Redis集群不保證強一致性，在特定條件下，Redis集群可能會丟掉一些命令。
三、slot槽位映射的方式
1、哈希取余分區
哈希取余分區的優點是分配均勻，使用hash(key)/3的形式讓固定的一部分請求存入指定的master，每臺master處理一部分數據，起到了負載均衡的效果。
哈希取余分區最大的缺點就是不方便擴容，當需要擴容時，映射關系需要進行重新計算。
2、一致性哈希算法
（1）一致性哈希算法是什么？
一致性哈希算法在1997年由麻省理工學院提出，是一種特殊的哈希算法，目的是解決分布式緩存的問題。在移除或者添加一個服務器時，能夠盡可能小地改變已存在的服務請求與處理請求服務器之間的映射關系。一致性哈希解決了簡單哈希算法在分布式哈希表( Distributed Hash Table，DHT) 中存在的動態伸縮等問題。
一致性哈希算法將整個哈希值空間映射成一個虛擬的圓環，整個哈希空間的取值范圍為0~2^32^-1，整個空間按順時針方向組織，0~2^32^-1在零點中方向重合。
接下來使用如下算法對服務請求進行映射，將服務請求使用哈希算法算出對應的hash值，然后根據hash值的位置沿圓環順時針查找，第一臺遇到的服務器就是所對應的處理請求服務器。
當增加一臺新的服務器，受影響的數據僅僅是新添加的服務器到其環空間中前一臺的服務器（也就是順著逆時針方向遇到的第一臺服務器）之間的數據，其他都不會受到影響。
綜上所述，一致性哈希算法對于節點的增減都只需重定位環空間中的一小部分數據，具有較好的容錯性和可擴展性。
（2）一致性哈希算法的優點
- 可擴展性。
- 更好的適應數據的快速增長，當某個分片存儲數據過多時，可以將其一分為二，不需要對全部的數據進行重新hash計算和劃分。
（3）一致性哈希算法的缺點
當服務節點太少時，容易造成數據傾斜，分配不均。
大量的緩存數據集中到了一臺或者幾臺服務節點上，稱為數據傾斜。
四、Redis更新策略
1、如果Redis中有數據，需要和數據庫中的值相同。
2、如果Redis中無數據，數據庫中的最新值要對Redis進行同步更新。
五、Redis讀寫緩存
1、同步直寫策略
寫入數據庫也同步寫Redis緩存，緩存和數據庫中的數據一致；對于讀寫緩存來說，要保證緩存和數據庫中的數據一致，就要保證同步直寫策略。
2、異步緩寫策略
某些業務運行中，MySQL數據更新之后，允許在一定時間后再進行Redis數據同步，比如物流系統。
當出現異常情況時，不得不將失敗的動作重新修補，需要借助rabbitmq或kafka進行重寫。
六、雙檢加鎖策略
多個線程同時去查詢數據庫的這條數據，那么我們可以在第一個查詢數據的請求上使用一個 互斥鎖來鎖住它。
其他的線程走到這一步拿不到鎖就等著，等第一個線程查詢到了數據，然后做緩存。
后面的線程進來發現已經有緩存了，就直接走緩存。
public String get(String key){
// 從Redis緩存中讀取
String value = redisTemplate.get(key);
if(value != null){
return value;
}
synchronized (RedisTest.class){
// 重新嘗試從Redis緩存中讀取
value = redisTemplate.get(key);
if(value != null){
return value;
}
// 從MySQL數據庫中查詢
value = studentDao.get(key);
// 寫入Redis緩存
redisTemplate.setnx(key,value,time);
return value;
}
}
七、數據庫和緩存一致性的更新策略
1、先更新數據庫，再更新Redis
按照常理出牌的話，應該都是如此吧？那么，這種情況下，會有啥問題呢？
如果更新數據庫成功后，更新Redis之前異常了，會出現什么情況呢？
數據庫與Redis內緩存數據不一致。
2、先更新緩存，再更新數據庫
多線程情況下，會有問題。
比如
- 線程1更新redis = 200；
- 線程2更新redis = 100；
- 線程2更新MySQL = 100；
- 線程1更新MySQL = 200；
結果呢，Redis=100、MySQL=200；我擦！
3、先刪除緩存，再更新數據庫
- 線程1刪除了Redis的緩存數據，然后去更新MySQL數據庫。
- 還沒等MySQL更新完畢，線程2殺來，讀取緩存數據。
- 但是，此時MySQL數據庫還沒更新，線程2讀取了MySQL中的舊值，然后線程2，還會將舊值寫入Redis作為數據緩存。
- 線程1更新完MySQL數據后，發現Redis中已經有數據了，之前都刪過了，那我就不更新了。
完蛋了。。
延時雙刪
延時雙刪可以解決上面的問題，只要sleep的時間大于線程2讀取數據再寫入緩存的時間就可以了，也就是線程1的二次清緩存操作要在線程2寫入緩存之后，這樣才能保證Redis緩存中的數據是最新的。
/**
* 延時雙刪
* @autor 哪吒編程
*/
public void deleteRedisData(Student stu){
// 刪除Redis中的緩存數據
jedis.del(stu);
// 更新MySQL數據庫數據
studentDao.update(stu);
// 休息兩秒
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 刪除Redis中的緩存數據
jedis.del(stu);
}
延遲雙刪最大的問題就是sleep，在效率為王的今天，sleep能不用還是不用為好。
你不睡我都嫌你慢，你還睡上了...
4、先更新數據庫，再刪除緩存
- 線程1先更新數據庫，再刪除Redis緩存。
- 線程2在線程1刪除Redis緩存之前發起請求，得到了未刪除的Redis緩存。
- 線程1此時才刪除Redis緩存數據。
問題還是有，這翻來覆去的，沒完沒了了。
這種情況如何解決呢？
引入消息中間件解決戰斗，再一次詳細的復盤一下。
- 更新數據庫。
- 數據庫將操作信息寫入binlog日志。
- 訂閱程序提取出key和數據。
- 嘗試刪除緩存操作，發現刪除失敗。
- 將這些數據信息發送到消息中間件中。
- 從消息中間件中獲取該數據，重新操作。
5、總結
哪吒推薦使用第四種方式，先更新數據庫，再刪除緩存。
方式①和方式②缺點太過明顯，不考慮；方式③中的sleep，總是讓人頭疼；方式④是一個比較全面的方案，但是增加了學習成本、維護成本，因為增加了消息中間件。
八、MySQL主從復制工作原理
1、當 master 主服務器上的數據發生改變時，則將其改變寫入二進制事件日志文件中。
2、salve 從服務器會在一定時間間隔內對 master 主服務器上的二進制日志進行探測，探測其是否發生過改變。
如果探測到 master 主服務器的二進制事件日志發生了改變，則開始一個 I/O Thread 請求 master 二進制事件日志。
3、同時 master 主服務器為每個 I/O Thread 啟動一個dump Thread，用于向其發送二進制事件日志。
4、slave 從服務器將接收到的二進制事件日志保存至自己本地的中繼日志文件中。
5、salve 從服務器將啟動 SQL Thread 從中繼日志中讀取二進制日志，在本地重放，使得其數據和主服務器保持一致。
6、最后 I/O Thread 和 SQL Thread 將進入睡眠狀態，等待下一次被喚醒。
本文轉載自微信公眾號「哪吒編程」
