key命名風(fēng)格

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

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

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

key命名規(guī)范

<應(yīng)用名>:<業(yè)務(wù)模塊名>:<業(yè)務(wù)邏輯含義>:<index>:<index>:...

1 以上的名稱可以進(jìn)行簡寫，但是要有明確的規(guī)劃，團(tuán)隊(duì)能夠達(dá)成共識。

 

2 單應(yīng)用可以不用應(yīng)用名。

 

3 建議key的命名的結(jié)尾加上value對應(yīng)的類型或者類型結(jié)尾。提高可讀性；

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

value存儲(chǔ)規(guī)范

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

String 類型控制在 10KB 以內(nèi)，Hash、List、Set、ZSet 元素個(gè)數(shù)不要超過 5000。

業(yè)務(wù)規(guī)范

1、優(yōu)先不使用緩存，防止緩存服務(wù)屏蔽底層的性能低下的業(yè)務(wù)邏輯而不自知。導(dǎo)致緩存重建時(shí)業(yè)務(wù)卡頓。

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

3、對 key 設(shè)置合理的過期時(shí)間。

說明：

1）若不設(shè)置的過期時(shí)間，key會(huì)一直占用內(nèi)存不釋放，隨著時(shí)間會(huì)達(dá)到服務(wù)器的內(nèi)存上限，導(dǎo)致服務(wù)器宕機(jī)等重大事故；

 

2）對于需要長期有效，可以判斷即將到期時(shí)，重新設(shè)置有效期，避免引起熱點(diǎn) key。

4、低頻數(shù)據(jù)不建議放在redis中，避免浪費(fèi)資源。

6、禁止大 key

再次重申，禁止將大 key 數(shù)據(jù)存? Redis。

1）帶來大的內(nèi)存占用

 

2）讀寫大 key 會(huì)導(dǎo)致超時(shí)，網(wǎng)卡流量占滿，甚至阻塞服務(wù), 更甚者導(dǎo)致宕機(jī)。

 

3）刪除大 key，DEL 命令可能阻塞 Redis 進(jìn)程，對應(yīng)用和 Redis 集群可用性造成嚴(yán)重的影響。

 

4）建議每個(gè) key 不要超過 10Kb。

7、不可使用 Keys 之類的操作。類似操作生產(chǎn)環(huán)境一半會(huì)禁用掉。

8、選擇合適的數(shù)據(jù)類型。

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

9、關(guān)于集合類操作

對于使用了 O(N) 的操作，導(dǎo)致服務(wù)超時(shí)，甚至服務(wù)不可用的問題。

1）使用 Set，Zset，List，Hash 等集合類的 O(N) 操作時(shí)，要預(yù)估 O(N) 操作的元素?cái)?shù)量，避免全量操作，可以使用 HSCAN，SSCAN，ZSCAN 進(jìn)行漸進(jìn)操作。

 

2）集合元素?cái)?shù)量過大在使用過程中會(huì)影響 Redis 的實(shí)際性能，Hash 類元素個(gè)數(shù)建議盡量不要超過 100，集合類、鏈表類數(shù)據(jù)盡量不要超過 10k。

 

3） 元素?cái)?shù)量過大可考慮拆分成多個(gè) key 進(jìn)行處理。

10、合理的監(jiān)控?cái)?shù)據(jù)和服務(wù)性能，做好安全防護(hù)和性能提升的準(zhǔn)備。

本文參考阿里云Redis開發(fā)規(guī)范