Redis根据不同的用途，会有不同的持久化策略和逐出策略，所以，在使用和申请Redis集群前，请明确是用来做缓存还是存储。redis的集群有主从和cluster两种模式，各有优缺点。以下规范不区分集群模式，我们分别从使用场景和操作限制两方面说明。

使用规范

冷热数据区分

虽然Redis支持持久化，但将所有数据存储在Redis中，成本非常昂贵。建议将热数据(如QPS超过5k)的数据加载到Redis中。低频数据可存储在Mysql、ElasticSearch中。

业务数据分离

不要将不相关的数据业务都放到一个Redis中。一方面避免业务相互影响，另一方面避免单实例膨胀，并能在故障时降低影响面，快速恢复。

消息大小限制

由于Redis是单线程服务，消息过大会阻塞并拖慢其他操作。保持消息内容在1KB以下是个好的习惯。严禁超过50KB的单条记录。消息过大还会引起网络带宽的高占用，持久化到磁盘时的IO问题。

连接数限制

连接的频繁创建和销毁，会浪费大量的系统资源，极限情况会造成宿主机当机。请确保使用了正确的Redis客户端连接池配置。

缓存Key设置失效时间

作为缓存使用的Key，必须要设置失效时间。失效时间并不是越长越好，请根据业务性质进行设置。注意，失效时间的单位是秒，这个很多同学不注意容易搞错。

扩展方式首选客户端hash

如单redis集群并不能为你的数据服务，不要着急扩大你的redis集群（包括M/S和Cluster)，集群越大，在状态同步和持久化方面的性能越差。 优先使用客户端hash进行集群拆分。如：根据用户id分10个集群，用户尾号为0的落在第一个集群。

操作限制

严禁使用Keys

Keys命令效率极低，属于O(N)操作，会阻塞其他正常命令，在cluster上，会是灾难性的操作。严禁使用，DBA应该rename此命令，从根源禁用。

严禁使用Flush

flush命令会清空所有数据，属于高危操作。严禁使用，DBA应该rename此命令，从根源禁用，仅DBA可操作。

严禁作为消息队列使用

如没有非常特殊的需求，严禁将Redis当作消息队列使用。Redis当作消息队列使用，会有容量、网络、效率、功能方面的多种问题。如需要消息队列，可使用高吞吐的Kafka或者高可靠的RocketMQ。

严禁不设置范围的批量操作

redis那么快，慢查询除了网络延迟，就属于这些批量操作函数。大多数线上问题都是由于这些函数引起。

• [zset] 严禁对zset的不设范围操作
• ZRANGE、ZRANGEBYSCORE等多个操作ZSET的函数，严禁使用 ZRANGE myzset 0 -1 等这种不设置范围的操作。请指定范围，如 ZRANGE myzset 0 100。如不确定长度，可使用ZCARD判断长度
  - [hash] 严禁对大数据量Key使用HGETALL
• HGETALL会取出相关HASH的所有数据，如果数据条数过大，同样会引起阻塞，请确保业务可控。如不确定长度，可使用HLEN先判断长度
• [key] Redis Cluster集群的mget操作
  Redis Cluster的MGET操作，会到各分片取数据聚合，相比传统的M/S架构，性能会下降很多，请提前压测和评估
  [其他] 严禁使用sunion,sinter,sdiff等一些聚合操作

禁用select函数

select函数用来切换database，对于使用方来说，这是很容易发生问题的地方，cluster模式也不支持多个database，且没有任何收益，禁用。

禁用事务

redis本身已经很快了，如无大的必要，建议捕获异常进行回滚，不要使用事务函数，很少有人这么干。

禁用lua脚本扩展

lua脚本虽然能做很多看起来很cool的事情，但它就像是SQL的存储过程，会引入性能和一些难以维护的问题，禁用。

禁止长时间monitor

monitor函数可以快速看到当前redis正在执行的数据流，但是当心，高峰期长时间阻塞在monitor命令上，会严重影响redis的性能。此命令不禁止使用，但使用一定要特别特别注意。

Key规范

Redis的Key一定要规范，这样在遇到问题时，能够进行方便的定位。Redis属于无scheme的KV数据库，所以，我们靠约定来建立其scheme语义。其好处：

• 能够根据某类key进行数据清理
• 能够根据某类key进行数据更新
• 能够方面了解到某类key的归属方和应用场景
• 为统一化、平台化做准备，减少技术变更

一般，一个key需要带以下维度：业务、key用途、变量等，各个维度使用 : 进行分隔，以下是几个key的实例:

• user:10002232:sex 用户10002232的性别
• msg:201712:achi 201712的用户发言数量排行榜