redis使用规范文档

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

Leave a Comment.