redis开发使用规范

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,如果要区分业务线，在配置文件里定义各业务线使用的前缀