# ****Redis使用规范****
一：书写本规范的背景，目的，原因，意义等虚化的内容全部省略。制定本规范只是为了减少因滥用，乱用，误用造成的生产，研发事故
二：Redis使用场景分析及使用建议
1）、纯Cache使用，主要是key->value的使用，这个场景主要是考虑减少数据库的读压力减少数据库的QPS，所以这部分key必须设置超时时间！因为若不设置，这些Key会一直占用内存不释放，造成极大的浪费，而且随着时间的推移会导致内存占用越来越大，直到达到服务器内存上限！另外Key的超时长短要根据业务综合评估，而不是越长越好！
2）、作为限流中间件使用，如保存中奖信息，作为已中奖用户限制；如保存奖品数量信息，作为数量限制，防止减少时扣减超出限制。这部分数据往往会使用hash，set数据，这部分数据应该在某次活动结束后，对里面的内容和信息进行落地，然后删除。
3）、作为队列使用，包括限流队列用户秒杀场景，或者任务队列用于程序异步化。这里主要用到list，用于秒杀场景的key理论上在活动结束后，如果list内数据还在，则需要删除，用户任务队列的key理论上必须存在消费者，基本无需处理
4）、数据库使用，主要使用hash和set满足数据库使用场景，如存储用户信息的hash，用户排行榜数据的sortedset。这部分数据需要有同步程序，理应redis的数据和mysql或者oracle数据库中都存有一份，在数据不同步时，能进行同步恢复操作。
5）、发布订阅消息中间件使用，暂未使用。
6）、分布式session使用，尽量与业务Redis不在同一实例上，减少相关性。
7）、分布式锁，用于减少数据库的锁性能消耗，通过Redis的setnx操作实现分布式锁。
三：目前Redis使用存在的一些问题
1）、用于Cache的key没有设置超时时间
2）、用于限流中间件使用的的key未做好退出处理
3）、数据库使用的key，同步还是有缺失，导致数据出错后，无法正常使用
4）、session和业务使用同一实例，依赖性较强
5）、在操作Redis时，同一请求处理中多次操作Redis，但未使用管道合并请求
6）、只使用Redis，未将数据落地至关系型数据库，或者没有足够的日志导致在导出数据，查找数据时太烦
7）、key太多，没有统一的地方查询每个key的使用原因，场景
8）、因为不敢删除，导致内存占用越来越大，导致在持久化是超出正常内存使用
四：使用规范
根据存在的问题及使用建议，需要做如下的规范：
1）、严格控制KEY的长度，但需要注意的是KEY格式需要满足前缀+名称+（期限）等组成，前缀包括项目名称简写如zj，hb，js，sh，活动功能区分hd或者gn，名称建议与Controller名称一致，如果可以需要加期限，如1709表示17年9月过后可以删除。
2）、严格或者是必须设置ttl，需重新封装Redis操作类，封装的类中其中所有的set方法尽可能加上expire，禁止直接使用内置client库
3）、禁止使用hgetall，smembers，keys，lrange 0，-1等获取所有数据的操作，特别是严禁在生产环境使用，如需获取全量数据，需要通过scan，hscan等操作替代
4）、在同一线程或进程多次操作Redis时，需要使用管道的方式获取数据，或者mget，hmget等获取数据，但不建议在集群环境中使用。不可以在同一方法内SET10000次，GET10000次
5）、严禁将数据只保存在Redis中，对一些核心数据必须落地至数据库，一些非核心数据必须落地至日志
6）、Redis只是一个其中的工具，适用场景也是有限的，没必要拿到一个工具往死里用，在技术选型时，不要拘泥于只有Redis
7）、控制每一个value的大小，不要把大量数据合在一个key中，只保存有效的，可使用的，这种场景建议hash或其他方式，或对value进行压缩后储存
8）、建议将保存用户信息和保存业务数据及保存session数据分离使用不同实例，减少因Redis单线程读写高并发情况使用效果不佳
9）、根据目前的实际情况，提出搭建Redis KEY使用管理平台，具体内容见五
五：Redis key管理平台
目标：
初级-》所有Redis key可管理，可查询，可知道key用途
进阶-》可导出（导出方式分为csv，数据库等），删除，批量操作
实现内容：
1、按照需求详细记录每个key的使用，包括key名称，数据结构，生成规则，ttl时间，数据格式示例
2、记录时需评估合理性，在添加时需要注明key使用者，如果是list，还应注明消费者相关
3、定期导出所有key跟管理平台所维护的 key进行对比，看是否有异常key使用情况
4、记录不在管理平台中的key使用相关信息
5、做好定期检查工作，对不正常的key，进行分析
网友评论