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 的落在第一个丛集。
操作限制
严禁使用 KeysKeys 命令效率极低，属于 O(N)操作，会阻塞其他正常命令，在 cluster 上，会是灾难性的操作。严禁使用，DBA 应该 rename 此命令，从根源禁用。
严禁使用 Flush
flush 命令会清空所有资料，属于高危操作。严禁使用，DBA 应该 rename 此命令，从根源禁用，仅 DBA 可操作。
严禁作为讯息伫列使用
如没有非常特殊的需求，严禁将 Redis 当作讯息伫列使用。Redis 当作讯息伫列使用，会有容量、网络、效率、功能方面的多种问题。如需要讯息伫列，可使用高吞吐的 Kafka 或者高可靠的 RocketMQ。
严禁不设定范围的批量操作
redis 那么快，慢查询除了网络延迟，就属于这些批量操作函式。大多数线上问题都是由于这些函式引起。
1、[zset] 严禁对 zset 的不设范围操作
2、ZRANGE、 ZRANGEBYSCORE等多个操作 ZSET 的函式，严禁使用 ZRANGE myzset 0 -1 等这种不设定范围的操作。请指定范围，如 ZRANGE myzset 0 100。如不确定长度，可使用 ZCARD 判断长度
3、[hash] 严禁对大资料量 Key 使用 HGETALL
4、HGETALL会取出相关 HASH 的所有资料，如果资料条数过大，同样会引起阻塞，请确保业务可控。如不确定长度，可使用 HLEN 先判断长度
5、[key] Redis Cluster 丛集的 mget 操作 Redis Cluster 的 MGET 操作，会到各分片取资料聚合，相比传统的 M/S架构，效能会下降很多，请提前压测和评估
6、[其他] 严禁使用 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 语义。其好处：1、能够根据某类 key 进行资料清理
2、能够根据某类 key 进行资料更新
3、能够方面了解到某类 key 的归属方和应用场景
4、为统一化、平台化做准备，减少技术变更
一般，一个 key 需要带以下维度：业务、key 用途、变数等，各个维度使用 : 进行分隔，以下是几个 key 的例项:
user:sex 使用者 10002232 的性别
msg:achi 201712 的使用者发言数量排行榜
小结
适当的约束是架构成熟的必要条件，通过约定能达到规范是集体开发的最高境界。Redis用的多，也要用的稳，给点约束、立点规矩，生活将变的美好。通过二次封装redis客户端，直接阻断，效果更佳。Redis实践文案
如果需要获取到这个【Redis文件】文件的话帮忙转发一下然后再关注我加群：536976563获取（内容细节比较多，所以把知识点粗略的截图出来了）小编还总结了Nginx、springboot的文件资料之前没有获取到的可以一次性入群获取
小编还总结了Nginx、springboot的文件资料，之前没有获取到的可以一次性加群：536976563获取
