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过大。