团队内部redis使用规范

团队内部Redis使用约定

目的

为了避免再次出现因redis使用不当，而造成异常影响业务，以及方便后期运维，故而经团队内部人员协商，出具redis使用规范，通过规范使用更好、更高效，更安全的使用redis缓存。

目前情况

• redis命名不规范，各种命名规则混合使用
• redis被用于持久化存储数据，redis数据有丢失风险，无重新加载方案
• redis存储的key，未设置过期时间

规范定义

关于文档中「能愿动词」的使用，参考psr使用规范的定义

为了避免歧义，文档大量使用了「能愿动词」，对应的解释如下：

• 必须 (MUST)：绝对，严格遵循，请照做，无条件遵守；
• 一定不可 (MUST NOT)：禁令，严令禁止；
• 应该 (SHOULD) ：强烈建议这样做，但是不强求；
• 不该 (SHOULD NOT)：强烈不建议这样做，但是不强求；
• 可以 (MAY) 和 可选 (OPTIONAL) ：选择性高一点，在这个文档内，此词语使用较少；

键值设计

1. redis key命名应该具有可读性以及可管理行，不该使用含义不清的key以及特别长的key名；
2. redis key命名必须全部由小写字母、数字、英文点号(.)和英文半角冒号(:)组成，必须以英文字母开头；
3. redis key命名必须按照模块区分前缀，具体模块定义参照上述模块划分中的内容，逻辑含义段必须使用英文半角冒号(:)分割，单词之间必须使用英文半角点号(.)分割，一定不可使用殊字符(下划线、空格、换行、单双引号以及其他转义字符等)；
4. redis key命名必须以key所代表的value类型结尾，见到key即可知道存储数据类型，以提高可读性；
5. 总结，命名规范为 业务模块名:业务逻辑含义:其他:value类型

   user:uid:1:string
   

业务规范

1. redis应该定位为缓存数据，除特殊需求外，聊天等

2. redis，应该设置过期时间

• redis定位为缓存cache使用时，对于存放的key，应该使用expire设置过期时间；
• 若不设置的话，这些key会一直占用内存不释放，随着时间的推移会越来越大，直到达到服务器的内存上线，导致宕机等恶略影响；
• 对于key的超时时长设置，可根据业务需求自行评估，并非越长越好；
• 某些业务的确需要长期有效，可以在每次设置时，设置超时时间，让超时时间顺延；

1. redis的使用，应该考虑冷热数据分离，不该将所有数据全部放到redis中，对于使用不频繁，且无关的日志等存入mysql，或正常的日志文件系统中

redis的数据存储全部都是在内存中的，成本昂贵。应该根据业务只将高频热数据存储到redis中，对于低频冷数据可以使用MySQL/MongoDB等基于磁盘的存储方式，不仅节省内存成本，而且数据量小在操作时速度更快、效率更高

1. redis有数据丢失风险，程序处理数据时，应该考虑丢失后的重新加载过程

使用redis时，要考虑丢失数据的风险，项目架构时需要考虑到相应解决方案，程序需要处理如果redis数据丢失时重新可进行重新加载

1. 对于必须要存储的大文本数据应该压缩后存储

对于大文本写入到Redis时，要压缩后存储。大文本数据存入redis，除了带来极大的内存占用外，在访问量高时，很容易就会将网卡流量占满，进而造成整个服务器上的所有服务不可用，并引发雪崩效应，造成各个系统瘫痪

1. 线上redis一定不可使用Keys正则匹配操作

2. 选择合适的数据类型

• 在不能确定其它复杂数据结构一定优于String类型时，避免使用Redis的复杂数据结构。
• 每种数据结构都有相应的使用场景，String类型是Redis中最简单的数据类型，建议使用String类型。
• 但是考虑到具体的业务场景，综合评估性能、存储、网络等方面之后使用适当的数据结构。
• 需要根据业务场景选择合适的类型，常见的如：String可以用作普通的K-V、简单数据类类型等；Hash可以用作对象如商品、经纪人等，包含较多属性的信息；List可以用作消息队列、医生粉丝/关注列表等；Set可以用于推荐；SortedSet可以用于排行榜等。

扫码关注有惊喜

（转载本站文章请注明作者和出处 白贺-studytime）