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/

標籤：其他

上一篇：復雜多邊形的三角剖分

下一篇：02-凸函式