前言

目前網際網路大廠大量使用redis、pika作為後端快取、儲存，但是存在儲存選型不慎重、結構規劃不合理、命令使用不規範的現象，繼而造成系統性能達 到瓶頸、活動高峰系統可用性下降、dba可運維難度大大增加。所以就有了這份規範，從源頭規範redis使用，避免系統執行過程中出現上述 問題。

黑色粗體代表需要關注，紅色字型代表特別需要關注。

儲存選型

• Redis是一個單程序、基於記憶體、弱事務的NoSql儲存系統，適用於高QPS、低延遲、弱持久化的場景，適宜用作快取。
• Pika是一個多執行緒、基於磁 盤的相容redis協議的儲存系統，適用於低QPS、高延遲、大容量持久化的場景，適宜用作儲存。
• 我們建議: 在qps>5000、容量<50G、儲存高頻數 據時考慮redis;在延遲容忍>10ms、容量大於50G、有持久化需求時考慮Pika;在qps<1000、儲存大量低頻資料、需要事務時考慮Mysql。

結構規劃

1. key名設計規範

• 可讀性和可管理性:
  
  Redis有兩層(key-value)或三層(key-field-value)結構，一個好的名字有助於排查線上問題、方便的進行批量處理，同時能夠防止key衝突。
  
  建議組標識:系統標識:模組標識:…作為一個通用字首，其中組標 識在明確namespace歸屬後可以不填

比如: 當前redis記憶體暴漲，通過高頻key字首可以輕易的區分出是那個系統的那個模組在頻繁操作，快速定位問題。

• 簡潔性:
  
  保證語義的前提下，控制key的長度，當key較多時，記憶體佔用也不容忽視，key的長度不超過100個字元。

例如: 不要包含特殊字元

反例: 包含空格、換行、單雙引號以及其他轉義字元

2. value設計規範

• 拒絕 bigkey(防止網絡卡流量、慢查詢):

  • string型別控制在10KB以內，hash、list、set、zset元素個數不要超過5000。

  • 非字串的bigkey，不要使用del刪除，使用hscan、sscan、zscan方式漸進式刪除，同時要注意防止bigkey過期時間自動刪除問題(例如一個200萬的zset設定1小時過期，會觸發del操作，造成阻塞，而且該操作不會不出現在慢查詢中(latency可查))，查詢方法和刪除方法

• 選擇適合的資料型別:
  
  例如:實體型別(要合理控制和使用資料結構記憶體編碼優化配置,例如ziplist，但也要注意節省記憶體和效能之間的平衡)

• 控制key的生命週期:
  
  redis不是垃圾桶，建議使用expire設定過期時間(條件允許可以打散過期時間，防止集中過期)，不過期的資料重點關注 idletime。

• 結構選擇
  

  • Strings型別: 單個kv儲存、適用於如簡單計數等，value長度建議小於1MB，存數字最佳，如果確實value比較大，建議壓縮後儲存。 Hash型別: 多個相關屬性放到一個Hash中、適用於如儲存物件，建議field數量小於10000，整體size小於1G。

  • Set型別: 集合型別、適用於如歸類物件等，建議元素數量小於10000，整體size小於1G。

  • Sorted Set型別: 有序集合型別、適用於如榜單排行，建議元素數量小於10000，整體size小於1G。

  • Lists型別: 佇列型別、適用於如佇列、粉絲/關注列表等，建議長度小於10000，整體size小於1G，保證生產-消費平衡。 需要使用特殊的資料型別(如Hyperloglog、Geo、Scripting)，需要提前跟DBA溝通。

2. 容量預估

• 第一次申請redis是需要做好容量評估、qps評估、流量評估(根據qps、平均value)，注意: 當需要當前redis支援某個活動、需求時，需要再 次進行上述評估，以便DBA進行資源調配。

• 使用ker後沒有db的概念，所以不需要進行db切換，也不支援通過db劃分系統、模組等。

命令使用

1. 命令使用基本原則

• 冷熱資料分離，不要將所有資料全部都放到Redis中

• 不同的業務資料要分開儲存

• M類操作命令，建議個數在100個以下，整體size控制在10KB以內，如MGET、MSET、HMGET等。

• 避免使用HGETALL、HKEYS、HVALS，除非可以保證HASH內field數量在100以內、size在10KB以下。如果不可避免，可以拆分一個大 HASH為多個小的HASH。

• 單個redis例項key的數量控制在100萬以內(因為我們不是所有的key都設定過期，暫時不考慮該條規則)。

• 如果將redis定位為快取，每個key儘量設定過期時間(最長14天，更長時間需要跟DBA溝通) 。

• Redis支援過期機制，如果某些業務場景用到了過期時間這一特性就不能使用讀寫分離特性，否則需要在業務去自行管理、及時過期。

• 對於特別重要的資料、連線相關的操作需要保證捕獲異常，防止錯誤被淹沒、資料操作狀態不確定。

2. 關注O(N)命令中N的數量

例如: hgetall、lrange、smembers、zrange、sinter等並非不能使用，但是需要明確N的值。有遍歷的需求可以使用hscan、sscan、zscan代替。

3. 禁用命令

禁止線上使用keys、flushall、flushdb、monitor、save、bgsave等，通過redis的rename機制禁掉命令，或者使用scan的方式漸進式處理。

快取db資料一致性規範

必須採用延時雙刪策略，具體操作如下：

1. 寫資料庫
2. 刪除快取
3. 同步延時或者訂閱db的binlog非同步延時再次刪除快取
   
   虛擬碼示例：

public void write(String key,Object data){
  //寫db
  db.updateData(data);
  //同步刪除快取
  redis.delKey(key);
  //延時500ms
  Thread.sleep(500);
  //再次刪除快取
  redis.delKey(key);
}

正文end

往期精彩回顧

粉絲福利

福利一:

長按掃碼關注下方二維碼，回覆「後端愛碼士」四個字，即可領取後端技術資料包（由號主（阿里p7）和另外四位BAT等網際網路大廠技術專家級朋友傾力總結，包括java併發，mysql，redis，kafka，zookeeper原理以及面試套路等）

福利二:

長按掃描下方二維碼，加號主微信，然後將本文轉發朋友圈，攢夠30個贊，截圖反饋給號主，就能獲得如下福利：

• 獲邀進入號主建立的網際網路大廠面試討論群。

• 以6折優惠價（原價1499元/個）獲得筆者一對一收徒第三期的名額（前提是需要有一定的基礎，需要通過考核），先到先得，每期5個名額，前兩期10名學徒全部收穫大廠offer，平均月薪28k以上。

• 阿里，騰訊，美團，滴滴，位元組，百度等大廠內推機會。