redis使用規範文檔 20170522版

運維redis很久了，一直是口頭給rd說各種要求，嘗試把這些規範總結成文檔

摘選一些可能比較通用的規則如下：

1. 強制：所有的key設置過期時間（最長可設置過期時間10天，如有特殊要求，聯繫dba說明原因）
2. 強制：禁止在測試環境，本地辦公環境，開發跳板機，連接線上redis實例（實例歸業務自運維的除外）
3. 強制：禁止使用運維類的命令  keys  monitor debug watch flush bigkeys 
4. 強制：list的長度最大長度不超過1萬，size不超過1G
5. 強制：key的長度不超過100個字元
6. 建議：string類型value長度不超過10M
7. 建議：做好容量規劃，預先考慮記憶體占用過大後，業務的拆分和分片後的影響
8. 建議：選擇合適的數據類型（string,list,hash,set,sortset)  ,使用特殊的數據類型（bit,geo)須提前與dba溝通
9. 建議：使用常用的命令，m類操作，建議個數100個以下。
10. 建議：不使用多個db,只使用db0,如果要區分業務線，在配置文件里定義各業務線使用的首碼
11. 建議：有一套能區分業務歸屬的命名規範，key首碼是發生記憶體暴漲，性能問題時的分析定位問題的可行基礎，Key的命名規範建議：
    1. 第1個字元小寫定義數據類型：
       1. string —>s,Hash—>h,Set—>s,Zset —>z,List —>l,Geo—>g
    2. 第2,3字元定義公開的業務分類：
    3. 第4-10個字元定義部門類的業務線細分
    4. 推薦的key中可使用符號.:#
    5. 不推薦使用的有：\ ? * {} [] ()  
       例：hCMappnode.product.detail:1312342
12. 建議：不命名用對list,set,zset等分片支持不友好的操作如：union diff，  如果不能避免，註意使用大括弧括起key的關鍵字
13. 建議：在代碼中捕扣redis連接異常。考慮一個redis實例短時當機時業務的降級處理，尤其是對redis的高頻調用，有時候redis報錯日誌可能會打滿磁碟
14. 建議：不同業務線，不同重要程度的redis建議申請多個redis實例，避免業務線中使用的redis過大。