突出强调部分
【强制】key 名不要包含特殊字符，如空格、换行、单双引号以及其他转义字符
【强制】拒绝 bigkey (防止网卡流量、慢查询)
【强制】控制 key 的生命周期，redis 不是垃圾桶
【强制】技术设计上避免热点 key
【强制】禁止线上使用 keys、flushall、flushdb、config 等
【强烈建议】选择适合的数据类型
【强烈建议】使用批量操作提高效率，但要注意控制一次批量操作的元素个数 (例如 500 以内，实际也和元素字节数有关)。如果用 pipeline，也注意批次下 key 数量限制在 500 以内
【强烈建议】 o (n) 命令关注 n 的数量。例如 hgetall、lrange、smembers、zrange、sinter 等并非不能使用，但是需要明确 n 的值。有遍历的需求可以使用 hscan、sscan、zscan 代替
【强烈建议】避免多个应用使用一个 redis 实例。正例：不相干的业务拆分，公共数据做服务化
【强烈建议】redis 使用定位提前确认：技术评审确认 redis 是定位为存储，还是 cache
一、键值设计
- key 名设计
(1)【建议】: 可读性和可管理性
以业务名 (或数据库名) 为前缀 (防止 key 冲突)，用冒号分隔，比如业务名：表名:id
(2)【建议】：简洁性
保证语义的前提下，控制 key 的长度，当 key 较多时，内存占用也不容忽视，例如：
(3)【强制】：不要包含特殊字符。 如空格、换行、单双引号以及其他转义字符
2. value 设计
(1)【强制】：拒绝 bigkey (防止网卡流量、慢查询)
a.string 类型控制在 10kb 以内，hash、list、set、zset 元素个数不要超过 5000。反例：一个包含 200 万个元素的 list。
b. 非字符串的 bigkey，不要使用 del 删除，使用 hscan、sscan、zscan 方式渐进式删除，同时要注意防止 bigkey 过期时间自动删除问题 (例如一个 200 万的 zset 设置 1 小时过期，会触发 del 操作，造成阻塞，而且该操作不会不出现在慢查询中 (latency 可查))，查找方法和删除方法
解释：由于 redis 单线程运行的机制，一个操作阻塞主线程，会导致该时间段内所有请求都堆积在 tcp buffer 中，得不到及时的处理。如果较多大 kv 在短时间内密集的执行删除或其他耗时操作，会导致该 redis 响应时间明显升高，甚至超时；在 kv 较大情况下，qps 承压能力受网卡上限影响，同时大量数据在内存与网卡驱动之间进行复制，对 cpu 也有较大的消耗；对于大 key 写请求，主要的压力在于主从复制使用的出口带宽，主节点下面带的从节点越多，出口带宽消耗越严重，同时主节点 cpu 消耗也越严重。
(2)【强烈建议】：选择适合的数据类型。
例如：
a. 实体类型 (要合理控制和使用数据结构内存编码优化配置，例如 ziplist，但也要注意节省内存和性能之间的平衡)
反例：
正例:
b. 典型的优化 case 是：1 个大 json 存一个大 string，只关注 json 中某一个或某几个属性的读，也要读取全部 string；只修改 json 中一个属性，也要将整个 string 重新覆盖写。优化成 hash 后，可大大降低对网卡、cpu、内存容量的压力，同时当 hash key 个数较少（512 内），value 不是很大（64 字节），可以进行压缩，降低 redis 自身的数据结构开销。
c. 尽量避免 key value 中重复的内容，比如 key 使用 id 进行索引话，value 中就可以不必再存放 id 字段。
3.【强制】：控制 key 的生命周期，redis 不是垃圾桶。
建议使用 expire 设置过期时间 (条件允许可以打散过期时间，防止集中过期)，不过期的数据重点关注 idletime。不建议在 redis 中存放 1 天以上不访问的数据，冷数据须考虑设置过期时间或使用 db 方式存储
解释：redis 作为全内存数据库，使用其第一目的就是用成本换性能，内存存储成本比 ssd 及 hdd 都要高很多，典型的服务器有 128g 内存，若算上持久化对内存的额外消耗，常规情况下只能提供约 80g 的使用容量，因此对 redis 的存储空间要格外的珍惜，设计上如果允许一个 key 进入内存长时间不使用，不做缓存超时，就会造成资源上的浪费。
4.【强制】：技术设计上避免热点 key，并且提供离线和实时分析工具。
二、命令使用
1.【强烈建议】 o (n) 命令关注 n 的数量。例如 hgetall、lrange、smembers、zrange、sinter 等并非不能使用，但是需要明确 n 的值。有遍历的需求可以使用 hscan、sscan、zscan 代替。
2.【强制】：禁用命令
禁止线上使用 keys、flushall、flushdb、config 等，通过 redis 的 rename 机制禁掉命令，或者使用 scan 的方式渐进式处理。计划在公共基础库上禁止使用
3.【建议】合理使用 select
redis 的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰。
4.【强烈建议】使用批量操作提高效率，但要注意控制一次批量操作的元素个数 (例如 500 以内，实际也和元素字节数有关)。如果用 pipeline，也注意批次下 key 数量限制在 500 以内
注意两者不同：
解释：mset、mget、del 的多 key 操作，对于 proxy 会有额外的 cpu 消耗。这三种特殊的操作，在后端做多分片时，proxy 需要将每个操作中的一批 key 按照后端分配规则，重组成 n 批 key 的组合，n 等于分片数量，然后分别将重组后的 n 个多 key 操作分片发给后端每一个分片；回复消息时，也需要等待所有请求从后端回复回来，在 proxy 层进行结果 merge，再返回给上层。因此这种操作在 key 数量上升时，对 proxy 的 cpu 会造成额外的压力，因此强烈建议控制批量操作的 key 数量，以及减少 mset、mget、del 等多 key 操作。对于一定要使用此种操作的服务，建议服务上线前根据自己的请求特点进行单独压测。一个 pipline 类型求情内容过多时，一次性打到 redis-proxy 时，会导致 proxy 申请内存数量暴涨，导致挤占同一物理机上混布的其他服务的资源，严重时会导致服务器重启。因此 pipline 类型请求需要严格限制单批次内的请求量。
5.【建议】redis 事务功能较弱，不建议过多使用
redis 的事务功能较弱 (不支持回滚)，而且集群版本 (自研和官方) 要求一次事务操作的 key 必须在一个 slot 上 (可以使用 hashtag 功能解决)
6.【建议】redis 集群版本在使用 lua 上有特殊要求：
- 所有 key 都应该由 keys 数组来传递，redis.call/pcall 里面调用的 redis 命令，key 的位置，必须是 keys array, 否则直接返回 error，”-err bad lua script for redis cluster, all the keys that the script uses should be passed using the keys arrayrn”
- 所有 key，必须在 1 个 slot 上，否则直接返回 error, “-err eval/evalsha command keys must in same slotrn”
7.【建议】必要情况下使用 monitor 命令时，要注意不要长时间使用。
8.【强烈建议】数据预热：若一个业务流程需要多次读取 redis 中相同内容，建议流程起始点一次读取，多次使用，尽量减少与 redis 交互，减轻后端压力
三、客户端使用
1.【强烈建议】避免多个应用使用一个 redis 实例。正例：不相干的业务拆分，公共数据做服务化。
2.【建议】
使用带有连接池的数据库，可以有效控制连接，同时提高效率，标准使用方式：
3.【建议】
高并发下建议客户端添加熔断功能 (例如 netflix hystrix)
4.【建议】
设置合理的密码，如有必要可以使用 ssl 加密访问
5.【建议】
根据自身业务类型，选好 maxmemory-policy (最大内存淘汰策略)，设置好过期时间。
默认策略是 volatile-lru，即超过最大内存后，在过期键中使用 lru 算法进行 key 的剔除，保证不过期数据不被删除，但是可能会出现 oom 问题。
其他策略如下：
allkeys-lru：根据 lru 算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
allkeys-random：随机删除所有键，直到腾出足够空间为止。
volatile-random: 随机删除过期键，直到腾出足够空间为止。
volatile-ttl：根据键值对象的 ttl 属性，删除最近将要过期数据。如果没有，回退到 noeviction 策略。
noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息”(error) oom command not allowed when used memory”，此时 redis 只响应读操作。
四、相关工具
1.【建议】：数据同步
redis 间数据同步可以使用：redis-port
2.【建议】：big key 搜索
redis 大 key 搜索工具
3.【建议】：热点 key 寻找 (内部实现使用 monitor，所以建议短时间使用)
facebook 的 redis-faina
五 删除 bigkey
-
hash 删除: hscan hdel
-
list 删除: ltrim
-
set 删除: sscan srem
-
sortedset 删除: zscan zrem
六、落实方式
-
加入研运技术评审 check 环节，检查 redis 的使用
-
加入 codereview 环节，check 下 redis 的使用技术方案是否合理
-
离线和实时的监控报警完善，需要出人力持续优化
七、问题讨论
- 排行榜场景大 key 问题
如有活动排行榜功能，100w 参加，每个人都需要知道自己的排名；zset 如业务必须超过 5000 的，可以设置不过期，手动删除元素，最后删除 key, 禁止直接删 key
这种大 key 方案是否短期内可以折衷接受，或者有更智能化的处理策略
是否考虑下做通用的排行榜服务了，应对通用排行榜需求，而不是目前的简单粗暴的大 key 方案
2.redis 使用定位问题：redis 是定位为存储，还是 cache。这个需要上线前考虑清楚。 两种场景配置，lru 策略都不一样。
技术评审需要提前确认定位；
需要替代方案，性能接近 redis 成本低的存储方案；