Redis最佳實踐

緩存數據庫在現代系統架構中愈來愈成爲標準配置之一，特別是隨着微服務架構的流行，微服務無狀態改造要求狀態外置，外置的狀態就須要存儲到外部緩存服務中。Redis是當前主流的緩存數據庫實現，本文介紹Redis基本概念與最佳實踐。

架構與概念

Redis是一個使用ANSI C編寫的開源、支持網絡、基於內存、可選持久性的鍵值對存儲數據庫。從2015年6月開始，Redis的開發由Redis Labs贊助，而2013年5月至2015年6月期間，其開發由Pivotal贊助。在2013年5月以前，其開發由VMware贊助。根據月度排行網站DB-Engines.com的數據，Redis是最流行的鍵值對存儲數據庫。

單機/主備/集羣模式

Redis是單線程模式，由於Redis設計理念是不消耗CPU，且單線程的結合異步IO處理效率也很高，當前Redis單實例能夠達到10萬QPS。通常的應用場景，使用單機或主備（高可用）便可知足要求。

可是現在應用程序愈來愈依賴Redis，對Redis的要求愈來愈高：訪問低時延(<5ms)、高QPS(百萬QPS)、高吞吐量(百MB/s)，從而致使不少場景下，單CPU沒法知足需求。所以多Redis進程組成的Redis集羣是高性能緩存服務的一種解決方法。
在集羣模式之下，因爲應用程序特徵，存在「熱Key」現象，熱Key會致使集羣下面的Redis使用不均衡，熱Key命中的實例很繁忙，其餘實例空閒。解決熱Key的一般作法有兩個：一個是在Redis集羣角度，提供讀寫分離特性，經過多個Redis實例分擔負載，固然讀寫分離自己是一個複製集羣，如何減小實例間數據複製時延以及複製時對主實例的消耗是讀寫分離模式設計的關鍵；另外一個方法是在應用程序內部使用內存作一級緩存，使用Redis作二級緩存。

Codis集羣

Redis官方版本3.0才支持集羣模式，在此以前，有很多Redis集羣方案，主要實現思路都是在Redis實例之上增長一個Proxy，由Proxy負責分區轉發，同時Redis實例的狀態由哨兵監控，哨兵將狀態寫入到分佈式配置中心（ZK/ETCD），Proxy經過配置中心刷新Redis實例路由信息。
在開源領域承認度較高的Proxy集羣實現是Codis,下圖是Codis的架構。

Redis原生集羣

Redis3.0版本支持集羣模式，與上面的帶Proxy集羣方式不同，Redis官方提供的集羣實現，在Server端是沒有Proxy的，Proxy路由的功能，由客戶端SDK來實現。爲了與Proxy集羣區分，Redis官方的集羣稱爲原生集羣。

Redis集羣節點之間通訊機制爲 Redis Cluster Bus，基於Gossip協議實現。

Redis客戶端經過CLUSTER相關命令獲取集羣配置信息，客戶端與節點之間經過MOVED/ASK來協調Key所屬的槽位變動。

原生集羣與Proxy集羣相比較，沒有Proxy層以後，水平擴展能力更好，官方宣傳支持1000節點。固然沒有了Proxy層，流量、路由管控會更麻煩一些。

原生集羣的槽位Slot空間總共爲16383個，所以理論上集羣節點數量是不能超過16383個。

Redis規格評估要素

選擇Redis規格時候，須要評估業務模型，避免選擇的規格與實際業務模型不匹配。

內存容量

根據Key寫入數量/頻度，TTL時常，是否顯示刪除判斷容量增加狀況，避免容量滿。
當Redis內存容量滿時，再次寫入則會觸發淘汰Key操做。同時因爲內存滿，可能致使系統資源不足，淘汰Key的操做會很耗時，從而致使寫入超時。

是否落盤

數據須要落盤的話，須要確認 appendfsync=everysec 若是開啓，底下磁盤是不是SSD；不然在高QPS寫的場景，若是不是SSD盤，可能會致使應用訪問Redis時延增長，極端狀況會訪問超時。

數據是否可重生成

若是數據能夠重生成，則不須要遷移數據。

若是數據不能重生成，那麼意味着須要遷移數據。當前並無Redis在線遷移的工具或服務（DRS服務對Redis支持還不完善），所以須要業務代碼配合完成遷移，根據業務狀況討論遷移方案。
典型的方法有：

• 業務代碼雙寫
• 若是重複Key值能夠覆蓋，則能夠寫一個工具從源庫讀，寫到目的庫，而後在某個時間點，短暫停業務切換庫
• 簡單粗暴的是停業務遷移

QPS

QPS是選擇Redis規格的主要依據之一，有的場景是數據量很小，QPS很高，因爲主備版本的最大QPS有限，若是須要的QPS超過了主備版本的QPS最大值，那麼也得上集羣版本。
內存很小，QPS很高的場景，也是小規格集羣的主要場景之一。

讀寫QPS佔比

QPS指標須要區分讀/寫，寫QPS很高的話要注意 AOF REWRITE，在執行 AOF REWRITE 時再寫入的話，時延會變高，極端狀況下會致使訪問超時。
參考鏈接

併發鏈接數

根據要求的併發鏈接數選定對應的規格。若是是短連接方式訪問，要特別注意。

是否cpu消耗類型

一些場景下如MSET、MGET等消耗CPU的命令較多，評估時候必定要考慮CPU算力是否足夠，有時候內存足夠了可是CPU不足，致使Redis CPU繁忙。這種狀況是小內存規格集羣的典型使用場景。

是否有TTL設置過長會致使內存滿

可能有一些Key的TTL設置的很長（如一個月），且沒有主動刪除機制，那麼就可能會致使內存滿，從而觸發Key淘汰策略，這時候再寫入可能會超時。

是否使用Pipeline

在QPS很高的場景下，使用Pipeline相比較單個Key操做，效率和性能都有很大提高。可是須要限定Pipeline中的命令數量，當前Codis Proxy默認的 session_max_pipeline=10000 ，建議不要超過此值。
同時還須要評估一次Pipeline返回的數據量。

是否使用多DB

有一些雲廠商（如阿里雲）支持Redis集羣有多DB特性，不一樣DB中的Key值能夠相同。Codis集羣、Redis原生集羣是不支持多DB的。

長鏈接or短鏈接

短鏈接須要特別關注鏈接數這個指標。若是是短連接，須要關注內存參數本地端口、最大句柄數等值是否調優。

主流雲廠家緩存服務對比

Redis做爲主流緩存服務，各個雲廠家都提供了託管式的Redis緩存服務，不過各個廠家實現上並不徹底一致，在此列出各個廠家主要實現原理以供選型參考。

AWS

AWS提供Redis集羣託管服務。用戶指定flavor機器（計算、存儲、網絡），AWS幫助客戶講Redis集羣部署到服務器上。
同時用戶建立實例時候能夠指定節點數量、副本數量、槽位與節點分配方式。

• 計算/存儲/網絡：可指定flavor。
• LB：不涉及。
• Proxy：不涉及。
• 多DB：不支持。
• 副本數：可指定副本數。
• 讀寫分離：不支持。
• 擴縮容：在線擴縮容。
• 跨集羣複製：不支持。
• 性能規格：
• 使用限制：使用限制
• Redis版本兼容：可選擇，範圍：3.2.4, 3.2.6, 3.2.10, 4.0.10, 5.0.0, 5.0.3, 5.0.4

阿里雲

阿里雲提供Proxy模式的集羣，Proxy自研。

• 計算/存儲/網絡：與Redis規格綁定，不可指定flavor。
• LB：使用SLB，QPS峯值爲200萬。
• Proxy：Proxy數量與集羣規格有必定配比關係，可支持用戶自定義Proxy數量，應對cpu消耗場景。
• 多DB：集羣支持多DB。
• 副本數：單副本、雙副本
• 讀寫分離：支持。slave同步數據存在必定延遲。
• 擴縮容：在線擴縮容。
• 跨集羣複製：支持。提供全球多活特性。
• 性能規格：性能規格
• 使用限制：使用限制
• Redis版本兼容：2.8, 4.0

騰訊雲

騰訊裏雲提供Proxy模式的集羣，Proxy自研。同時騰訊雲提供兩種Redis引擎：開源Redis，自研CKV。

• 計算/存儲/網絡：與Redis規格綁定，不可指定flavor。
• LB：單節點10萬QPS，QPS上限未知。
• Proxy：數量不可指定。
• 多DB：集羣不支持多DB。
• 副本數：可選擇：1,2,3,4,5
• 讀寫分離：不支持。
• 擴縮容：在線擴縮容。
• 跨集羣複製：不支持。
• 性能規格：性能規格)
• 使用限制：使用限制)
• Redis版本兼容：單機/主從版2.8，集羣版4.0

華爲雲

華爲雲提供兩種Proxy模式的集羣：Codis與Redis原生集羣。原生集羣不帶LB與Proxy。

• 計算/存儲/網絡：與Redis規格綁定，不可指定flavor。
• LB：100萬QPS。
• Proxy：數量不可指定。
• 多DB：集羣不支持多DB。
• 副本數：2
• 讀寫分離：不支持。
• 擴縮容：在線擴容。
• 跨集羣複製：不支持。
• 性能規格：性能規格))
• 使用限制：使用限制）
• Redis版本兼容：2.8, 3.x, 4.0, 5.0

更多雲最佳實踐 https://best.practices.cloud