团队内部redis使用规范
团队内部Redis使用约定
目的
为了避免再次出现因redis使用不当，而造成异常影响业务，以及方便后期运维，故而经团队内部人员协商，出具redis使用规范，通过规范使用更好、更高效，更安全的使用redis缓存。
目前情况
- redis命名不规范，各种命名规则混合使用
- redis被用于持久化存储数据，redis数据有丢失风险，无重新加载方案
- redis存储的key，未设置过期时间
规范定义
关于文档中「能愿动词」的使用，参考psr使用规范的定义
为了避免歧义，文档大量使用了「能愿动词」，对应的解释如下：
- 必须 (MUST)：绝对，严格遵循，请照做，无条件遵守；
- 一定不可 (MUST NOT)：禁令，严令禁止；
- 应该 (SHOULD) ：强烈建议这样做，但是不强求；
- 不该 (SHOULD NOT)：强烈不建议这样做，但是不强求；
- 可以 (MAY) 和 可选 (OPTIONAL) ：选择性高一点，在这个文档内，此词语使用较少；
键值设计
- redis key命名应该具有可读性以及可管理行，不该使用含义不清的key以及特别长的key名；
- redis key命名必须全部由小写字母、数字、英文点号(.)和英文半角冒号(:)组成，必须以英文字母开头；
- redis key命名必须按照模块区分前缀，具体模块定义参照上述模块划分中的内容，逻辑含义段必须使用英文半角冒号(:)分割，单词之间必须使用英文半角点号(.)分割，一定不可使用殊字符(下划线、空格、换行、单双引号以及其他转义字符等)；
- redis key命名必须以key所代表的value类型结尾，见到key即可知道存储数据类型，以提高可读性；
- 总结，命名规范为 业务模块名:业务逻辑含义:其他:value类型
user:uid:1:string
业务规范
-
redis应该定位为缓存数据，除特殊需求外，聊天等
-
redis，应该设置过期时间
- redis定位为缓存cache使用时，对于存放的key，应该使用expire设置过期时间；
- 若不设置的话，这些key会一直占用内存不释放，随着时间的推移会越来越大，直到达到服务器的内存上线，导致宕机等恶略影响；
- 对于key的超时时长设置，可根据业务需求自行评估，并非越长越好；
- 某些业务的确需要长期有效，可以在每次设置时，设置超时时间，让超时时间顺延；
- redis的使用，应该考虑冷热数据分离，不该将所有数据全部放到redis中，对于使用不频繁，且无关的日志等存入mysql，或正常的日志文件系统中
redis的数据存储全部都是在内存中的，成本昂贵。应该根据业务只将高频热数据存储到redis中，对于低频冷数据可以使用MySQL/MongoDB等基于磁盘的存储方式，不仅节省内存成本，而且数据量小在操作时速度更快、效率更高
- redis有数据丢失风险，程序处理数据时，应该考虑丢失后的重新加载过程
使用redis时，要考虑丢失数据的风险，项目架构时需要考虑到相应解决方案，程序需要处理如果redis数据丢失时重新可进行重新加载
- 对于必须要存储的大文本数据应该压缩后存储
对于大文本写入到Redis时，要压缩后存储。大文本数据存入redis，除了带来极大的内存占用外，在访问量高时，很容易就会将网卡流量占满，进而造成整个服务器上的所有服务不可用，并引发雪崩效应，造成各个系统瘫痪
-
线上redis一定不可使用Keys正则匹配操作
-
选择合适的数据类型
- 在不能确定其它复杂数据结构一定优于String类型时，避免使用Redis的复杂数据结构。
- 每种数据结构都有相应的使用场景，String类型是Redis中最简单的数据类型，建议使用String类型。
- 但是考虑到具体的业务场景，综合评估性能、存储、网络等方面之后使用适当的数据结构。
- 需要根据业务场景选择合适的类型，常见的如：String可以用作普通的K-V、简单数据类类型等；Hash可以用作对象如商品、经纪人等，包含较多属性的信息；List可以用作消息队列、医生粉丝/关注列表等；Set可以用于推荐；SortedSet可以用于排行榜等。
扫码关注有惊喜
（转载本站文章请注明作者和出处 白贺-studytime）
