redis使用规范文档 20170522版

运维redis很久了，一直是口头给rd说各种要求，尝试把这些规范总结成文档

• 强制：所有的key设置过期时间（最长可设置过期时间10天，如有特殊要求，联系dba说明原因 ）
• 强制：禁止在测试环境，本地办公环境，开发跳板机，连接线上redis实例（实例归业务自运维的 除外）
• 强制：禁止使用运维类的命令 keys monitor debug watch flush bigkeys
• 强制：list的长度最大长度不超过1万，size不超过1G
• 强制：key的长度不超过100个字符
• 建议：string类型value长度不超过10M
• 建议：做好容量规划，预先考虑内存占用过大后，业务的拆分和分片后的影响
• 建议：选择合适的数据类型（string,list,hash,set,sortset) ,使用特殊的数据类型（ bit,geo)须提前与dba沟通
• 建议：使用常用的命令，m类操作，建议个数100个以下。
• 建议：不使用多个db,只使用db0,如果要区分业务线，在配置文件里定义各业务线使用的前缀
• < 大专栏  redis使用规范文档 20170522版p>建议：有一套能区分业务归属的命名规范，key前缀是发生内存暴涨，性能问题时的分析定位问题 的可行基础，Key的命名规范建议：
  • 第1个字符小写定义数据类型：
  • string —>s,Hash—>h,Set—>s,Zset —>z,List —>l,Geo—>g
  • 第2,3字符定义公开的业务分类：
  • 第4-10个字符定义部门类的业务线细分
  • 推荐的key中可使用符号.:#
  • 不推荐使用的有： ? * {} [] ()
    
  • 例：hCMappnode.product.detail:1312342
    

• 建议：不命名用对list,set,zset等分片支持不友好的操作如：union diff， 如果不能避免 ，注意使用大括号括起key的关键字

• 建议：在代码中捕扣redis连接异常。考虑一个redis实例短时当机时业务的降级处理，尤其是对 redis的高频调用，有时候redis报错日志可能会打满磁盘

• 建议：不同业务线，不同重要程度的redis建议申请多个redis实例，避免业务线中使用的redis过大。