如何解決 Redis 數據傾斜、熱點等問題
大家好，我是Tom哥。
Redis 作為一門主流技術，應用場景非常多，很多大中小廠面試都列為重點考察內容
前幾天有星球小伙伴學習時，遇到下面幾個問題，來咨詢 Tom哥
考慮到這些問題比較高頻，工作中經常會遇到，這里寫篇文章系統講解下
問題描述：
向你提問：tom哥，在復習redis時，有些疑問，麻煩看看：
1.如果redis集群出現數據傾斜，數據分配不均，該如何解決？2.處理hotKey時，為key創建多個副本，如k-1，k-2…， 如何讓這些副本能均勻寫入？如何均勻訪問？3.redis使用hash slot來維護集群。與一致性哈希類似，都可以避免全量遷移。為什么不直接使用一致性hash？
Tom哥 回復：
分布式緩存作為性能加速器，在系統優化中承擔著非常重要的角色。相比本地緩存，雖然增加了一次網絡傳輸，大約占用不到 1 毫秒外，但是卻有集中化管理的優勢，并支持非常大的存儲容量。
分布式緩存領域，目前應用比較廣泛的要數 Redis 了，該框架是純內存儲存，單線程執行命令，擁有豐富的底層數據結構，支持多種維度的數據存儲和查找。
當然，數據量一大，各種問題就出現了，比如：數據傾斜、數據熱點等。
什么是數據傾斜？
單臺機器的硬件配置有上限制約，一般我們會采用分布式架構將多臺機器組成一個集群，下圖的集群就是由三臺Redis單機組成。客戶端通過一定的路由策略，將讀寫請求轉發到具體的實例上。
由于業務數據特殊性，按照指定的分片規則，可能導致不同的實例上數據分布不均勻，大量的數據集中到了一臺或者幾臺機器節點上計算，從而導致這些節點負載多大，而其他節點處于空閑等待中，導致最終整體效率低下。
數據傾斜有哪些原因呢？
1、存在大key
比如存儲一個或多個 String 類型的 bigKey 數據，內存占用很大。
Tom哥之前排查過這種問題，有同事開發時為了省事，采用JSON格式，將多個業務數據合并到一個 value，只關聯一個key，導致了這個鍵值對容量達到了幾百M。
頻繁的大key讀寫，內存資源消耗比較重，同時給網絡傳輸帶了極大的壓力，進而導致請求響應變慢，引發雪崩效應，最后系統各種超時報警。
解決方案：
辦法非常簡單，采用化整為零的策略，將一個bigKey拆分為多個小key，獨立維護，成本會降低很多。當然這個拆也講究些原則，既要考慮業務場景也要考慮訪問場景，將關聯緊密的放到一起。
比如：有個RPC接口內部對 Redis 有依賴，之前訪問一次就可以拿到全部數據，拆分將要控制單值的大小，也要控制訪問的次數，畢竟調用次數增多了，會拉大整體的接口響應時間。
浙江的政府機構都在提倡優化流程，最多跑一次，都是一個道理。
2、HashTag 使用不當
Redis 采用單線程執行命令，從而保證了原子性。當采用集群部署后，為了解決mset、lua 腳本等對多key 批量操作，為了保證不同的 key 能路由到同一個 Redis 實例上，引入了 HashTag 機制。
用法也很簡單，使用{}大括號，指定key只計算大括號內字符串的哈希，從而將不同key的健值對插入到同一個哈希槽。
舉個例子：?
check 下業務代碼，有沒有引入HashTag，將太多的key路由到了一個實例。結合具體場景，考慮如何做下拆分。
就像 RocketMQ 一樣，很多時候只要能保證分區有序，就可以滿足我們的業務需求。具體實戰中，要找到這個平衡點，而不是為了解決問題而解決問題。
3、slot 槽位分配不均
如果采用 Redis Cluster 的部署方式，集群中的數據庫被分為16384個槽（slot），數據庫中的每個健都屬于這16384個槽的其中一個，集群中的每個節點可以處理的0個或最多16384個槽。
你可以手動做遷移，將一個比較大的 slot 遷移到稍微空閑的機器上，保證存儲和訪問的均勻性。
什么是緩存熱點？
緩存熱點是指大部分甚至所有的業務請求都命中同一份緩存數據，給緩存服務器帶來了巨大壓力，甚至超過了單機的承載上限，導致服務器宕機。
解決方案：
1、復制多份副本
我們可以在key的后面拼上有序編號，比如key#01、key#02。。。key#10多個副本，這些加工后的key位于多個緩存節點上。
客戶端每次訪問時，只需要在原key的基礎上拼接一個分片數上限的隨機數，將請求路由不到的實例節點。
注意：緩存一般都會設置過期時間，為了避免緩存的集中失效，我們對緩存的過期時間盡量不要一樣，可以在預設的基礎上增加一個隨機數。
至于數據路由的均勻性，這個由 Hash 算法來保證。
2、本地內存緩存
把熱點數據緩存在客戶端的本地內存中，并且設置一個失效時間。對于每次讀請求，將首先檢查該數據是否存在于本地緩存中，如果存在則直接返回，如果不存在再去訪問分布式緩存的服務器。
本地內存緩存徹底“解放”了緩存服務器，不會對緩存服務器有任何壓力。
缺點：實時感知最新的緩存數據有點麻煩，會產生數據不一致的情況。我們可以設置一個比較短的過期時間，采用被動更新。當然，也可以用監控機制，如果感知到數據已經發生了變化，及時更新本地緩存。
Redis Cluster 為什么不用一致性Hash?
Redis Cluster 集群有16384個哈希槽，每個key通過CRC16校驗后對16384取模來決定放置哪個槽。集群的每個節點負責一部分hash槽，舉個例子，比如當前集群有3個節點，那么 node-1 包含 0 到 5460 號哈希槽，node-2 包含 5461 到 10922 號哈希槽，node-3包含 10922 到 16383 號哈希槽。
一致性哈希算法是 1997年麻省理工學院的 Karger 等人提出了，為的就是解決分布式緩存的問題。
一致性哈希算法本質上也是一種取模算法，不同于按服務器數量取模，一致性哈希是對固定值 2^32 取模。
公式 = hash（key） % 2^32。
其取模的結果必然是在 [0, 2^32-1] 這個區間中的整數，從圓上映射的位置開始順時針方向找到的第一個節點即為存儲key的節點。
一致性哈希算法大大緩解了擴容或者縮容導致的緩存失效問題，只影響本節點負責的那一小段key。如果集群的機器不多，且平時單機的負載水位很高，某個節點宕機帶來的壓力很容易引發雪崩效應。
舉個例子：
Redis 集群 總共有4臺機器，假設數據分布均衡，每臺機器承擔 四分之一的流量，如果某一臺機器突然掛了，順時針方向下一臺機器將要承擔這多出來的 四分之一 流量，最終要承擔 二分之一 的流量，還是有點恐怖。
但是如果采用 CRC16計算后，并結合槽位與實例的綁定關系，無論是擴容還是縮容，只需將相應節點的key做下數據平滑遷移，廣播存儲新的槽位映射關系，不會產生緩存失效，靈活性很高。
另外，如果服務器節點配置存在差異化，我們可以自定義分配不同節點負責的 slot 編號，調整不同節點的負載能力，非常方便。
