# Redis規范 為了避免出現因redis使用不當，而造成異常影響業務，以及方便后期運維，故而經團隊內部人員協商，出具redis使用規范，通過規范更好、更高效，更安全的使用redis緩存。 ### 目前情況 * redis命名不規范，各種命名規則混合使用 * redis被用于持久化存儲數據，redis數據有丟失風險，無重新加載方案 * redis存儲的key，未設置過期時間 ### 關于文檔中「能愿動詞」的使用，參考psr使用規范的定義 為了避免歧義，文檔大量使用了「能愿動詞」，對應的解釋如下： * 必須 (MUST)：絕對，嚴格遵循，請照做，無條件遵守； * 一定不可 (MUST NOT)：禁令，嚴令禁止； * 應該 (SHOULD) ：強烈建議這樣做，但是不強求； * 不該 (SHOULD NOT)：強烈不建議這樣做，但是不強求； * 可以 (MAY) 和 可選 (OPTIONAL) ：選擇性高一點，在這個文檔內，此詞語使用較少； ### 鍵值設計 * redis key命名**應該**具有可讀性以及可管理行，**不該**使用含義不清的key以及特別長的key名； * redis key命名**必須**全部由小寫字母、數字、英文點號(.)和英文半角冒號(:)組成，**必須**以英文字母開頭； * redis key命名**必須**按照模塊區分前綴，具體模塊定義參照上述模塊劃分中的內容，邏輯含義段**必須**使用英文半角冒號(:)分割，單詞之間**必須**使用英文半角點號(.)分割，**一定不可**使用殊字符(下劃線、空格、換行、單雙引號以及其他轉義字符等)； * redis key命名必須以key所代表的value類型結尾，見到key即可知道存儲數據類型，以提高可讀性； * 總結，命名規范為 業務模塊名:業務邏輯含義:其他:value類型\*\*`user:uid:1:string`\*\* ### 業務規范 * redis**應該**定位為緩存數據，除特殊需求外，聊天等 * redis，**應該**設置過期時間 * redis定位為緩存cache使用時，對于存放的key，應該使用expire設置過期時間； * 若不設置的話，這些key會一直占用內存不釋放，隨著時間的推移會越來越大，直到達到服務器的內存上線，導致宕機等惡略影響； * 對于key的超時時長設置，可根據業務需求自行評估，并非越長越好； * 某些業務的確需要長期有效，可以在每次設置時，設置超時時間，讓超時時間順延； * redis的使用，**應該**考慮冷熱數據分離，**不該**將所有數據全部放到redis中，對于使用不頻繁，且無關的日志等存入mysql，或正常的日志文件系統中 redis的數據存儲全部都是在內存中的，成本昂貴。**應該**根據業務只將高頻熱數據存儲到redis中，對于低頻冷數據可以使用MySQL/MongoDB等基于磁盤的存儲方式，不僅節省內存成本，而且數據量小在操作時速度更快、效率更高 * redis有數據丟失風險，程序處理數據時，**應該**考慮丟失后的重新加載過程 使用redis時，要考慮丟失數據的風險，項目架構時需要考慮到相應解決方案，程序需要處理如果redis數據丟失時重新可進行重新加載 * 對于必須要存儲的大文本數據**應該**壓縮后存儲 對于大文本寫入到Redis時，要壓縮后存儲。大文本數據存入redis，除了帶來極大的內存占用外，在訪問量高時，很容易就會將網卡流量占滿，進而造成整個服務器上的所有服務不可用，并引發雪崩效應，造成各個系統癱瘓 * 線上redis**一定不可**使用Keys正則匹配操作 * 選擇合適的數據類型 * 在不能確定其它復雜數據結構一定優于String類型時，避免使用Redis的復雜數據結構。 * 每種數據結構都有相應的使用場景，String類型是Redis中最簡單的數據類型，建議使用String類型。 * 但是考慮到具體的業務場景，綜合評估性能、存儲、網絡等方面之后使用適當的數據結構。 * 需要根據業務場景選擇合適的類型，常見的如：String可以用作普通的K-V、簡單數據類類型等；Hash可以用作對象如商品、經紀人等，包含較多屬性的信息；List可以用作消息隊列、醫生粉絲/關注列表等；Set可以用于推薦；SortedSet可以用于排行榜等。 *****