redis开发使用规范

1、冷热数据分离,不要将所有数据全部都放在Redis中

    根据业务只将高频热数据存储到Redis中【QPS大于5000】,对于低频冷数据可以使用mysql等基于磁盘的存储方式。

    不仅节省内存成本,而且数据量小操作时速度更快,效率更高。

2、不同的业务数据要分开存储

    不要将不相关的业务数据都放到一个Redis实例中,建议新业务申请新的单独实例。因为Redis为单线程处理,

    独立存储会减少不同业务相互操作的影响,提高请求响应速度;同时也避免单个实例内存数据量膨胀过大,

    在出现异常情况时可以更快恢复服务!简言之,不同业务数据要分开存储,尽可能的独立使用,

    而不是多个业务共享同一redis实例。

3、规范Key的格式

    合适的Key,便于查看,统计,排错。

    不推荐含义不清的Key和特别长的Key。例如:"平台缩写"+":"+"项目名"+":"+"业务含义"。

    例如:CRM:STUDENTS:USERINFO

    ":" 作为key分隔符,方便客户端工具作为目录分级

    保证语义的前提下,控制 key 的长度,当 key 较多时,内存占用也不容忽视。

    不要包含特殊字符。例如:包含空格、换行、单双引号以及其他转义字符

    

    另外可参考一下几点说明:

    有一套能区分业务归属的命名规范,key前缀是发生内存暴涨,性能问题时的分析定位问题的可行基础,Key的命名规范建议:

    第1个字符小写定义数据类型:

    string —>s,Hash—>h,Set—>s,Zset —>z,List —>l,Geo—>g

    第2,3字符定义公开的业务分类:

    第4-10个字符定义部门类的业务线细分

    推荐的key中可使用符号.:#

    不推荐使用的有:\ ? * {} [] ()  

    例:hCMappnode.product.detail:1312342

 

4、value设计时,拒绝 bigkey。

    string 类型控制在 10KB 以内,hash、list、set、zset 元素个数不要超过 5000

5、对于必须要存储的大文本数据一定要压缩后存储

6、线上Redis禁止使用Keys正则匹配操作

7、所有的key设置过期时间(比如可设置过期时间10天,特殊要求除外)

8、list的长度最大长度不超过1万,size不超过1G

9、string类型value长度不超过10M

10、不使用多个db,只使用db0,如果要区分业务线,在配置文件里定义各业务线使用的前缀