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