这多是最中肯的Redis规范了

更多精彩文章。

《微服务不是所有，只是特定领域的子集》

《“分库分表" ？选型和流程要慎重，不然会失控》

这么多监控组件，总有一款适合你

《使用Netty，咱们到底在开发些什么？》

《这多是最中肯的Redis规范了》

《程序员画像，十年沉浮》

最有用系列：

《Linux生产环境上，最经常使用的一套“vim“技巧》

《Linux生产环境上，最经常使用的一套“Sed“技巧》

《Linux生产环境上，最经常使用的一套“AWK“技巧》

---

Linux五件套之类的。

《Linux之《荒岛余生》（一）准备篇》

《Linux之《荒岛余生》（二）CPU篇》

《Linux之《荒岛余生》（三）内存篇》

《Linux之《荒岛余生》（四）I/O篇》

《Linux之《荒岛余生》（五）网络篇》

更多请关注。固然也能够关注公众号: xjjdog 。

redis功能强大，数据类型丰富，再快的系统，也经不住疯狂的滥用。经过禁用部分高风险功能，并挂上开发的枷锁，业务更可以以简洁、通用的思想去考虑问题，而不是绑定在某种实现上。

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:sex 用户 10002232 的性别

msg:achi 201712 的用户发言数量排行榜

End

适当的约束是架构成熟的必要条件，经过约定能达到规范是集体开发的最高境界。Redis用的多，也要用的稳，给点约束、立点规矩，生活将变的美好。经过二次封装redis客户端，直接阻断，效果更佳。