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