key命名風格
1需具有可讀性以及可管理性，禁止毫無營養隨意命名；
2 以英文字母開頭，命名中只能出現小寫字母、數字、英文點號 （。） 和英文半形冒號（：）；
3 不要包含特殊字元，如下劃線、空格、換行、單雙引號以及其他跳脫字元；
key命名規範
<應用名>：<業務模組名>：<業務邏輯含義>：
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開發規範
