# 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可以用于排行榜等。 *****