key命名風格

1需具有可讀性以及可管理性，禁止毫無營養隨意命名；

2 以英文字母開頭，命名中只能出現小寫字母、數字、英文點號 (.) 和英文半角冒號(:)；

3 不要包含特殊字符，如下劃線、空格、換行、單雙引號以及其他轉義字符；

key命名規范

<應用名>:<業務模塊名>:<業務邏輯含義>:<index>:<index>:...

1 以上的名稱可以進行簡寫，但是要有明確的規劃，團隊能夠達成共識。

 

2 單應用可以不用應用名。

 

3 建議key的命名的結尾加上value對應的類型或者類型結尾。提高可讀性；

示例：api:emr:patient:{userid}:str

value存儲規范

1 拒絕大key(防止網卡流量、慢查詢)。

String 類型控制在 10KB 以內，Hash、List、Set、ZSet 元素個數不要超過 5000。

業務規范

1、優先不使用緩存，防止緩存服務屏蔽底層的性能低下的業務邏輯而不自知。導致緩存重建時業務卡頓。

2、redis 在緩存場景時候，應該是為核心的小數據為主，而且QPS比較高。同時緩存在失效或者丟失情況下，應該考慮緩存重建邏輯，不能影響正常業務。

3、對 key 設置合理的過期時間。

說明：

1）若不設置的過期時間，key會一直占用內存不釋放，隨著時間會達到服務器的內存上限，導致服務器宕機等重大事故；

 

2）對于需要長期有效，可以判斷即將到期時，重新設置有效期，避免引起熱點 key。

4、低頻數據不建議放在redis中，避免浪費資源。

6、禁止大 key

再次重申，禁止將大 key 數據存? Redis。

1）帶來大的內存占用

 

2）讀寫大 key 會導致超時，網卡流量占滿，甚至阻塞服務, 更甚者導致宕機。

 

3）刪除大 key，DEL 命令可能阻塞 Redis 進程，對應用和 Redis 集群可用性造成嚴重的影響。

 

4）建議每個 key 不要超過 10Kb。

7、不可使用 Keys 之類的操作。類似操作生產環境一半會禁用掉。

8、選擇合適的數據類型。

Redis 支持的數據庫結構類型較多：字符串（String），哈希（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog 和地理空間索引（geospatial）等, 需要根據業務場景選擇合適的類型。這些之前的文章寫過。

9、關于集合類操作

對于使用了 O(N) 的操作，導致服務超時，甚至服務不可用的問題。

1）使用 Set，Zset，List，Hash 等集合類的 O(N) 操作時，要預估 O(N) 操作的元素數量，避免全量操作，可以使用 HSCAN，SSCAN，ZSCAN 進行漸進操作。

 

2）集合元素數量過大在使用過程中會影響 Redis 的實際性能，Hash 類元素個數建議盡量不要超過 100，集合類、鏈表類數據盡量不要超過 10k。

 

3） 元素數量過大可考慮拆分成多個 key 進行處理。

10、合理的監控數據和服務性能，做好安全防護和性能提升的準備。

本文參考阿里云Redis開發規范