共计 2480 个字符，预计需要花费 7 分钟才能阅读完成。
作者：喜马拉雅 董道光
宣言：缓存不是万金油，更不是垃圾桶！！！
缓存作为喜马拉雅至关重要的根底组件之一，每天承载着微小的业务申请量。一旦缓存呈现故障，对业务的影响将十分重大。因而，确保缓存服务的稳固和高效运行始终是咱们的重要指标。
上面是咱们对喜马缓存历史故障复盘后总结的一套缓存应用标准，在此分享给大家，心愿小伙伴们能在缓存选型和应用的过程中少踩坑。
1. 缓存选型
1.1 缓存类型介绍
喜马线上缓存类型次要有 4 种：
1. redis 主从模式：官网原版
2.codis-redis：豌豆荚开源，redis 集群解决方案
3. 云数据库 redis：redis-cluster 容器化部署
4.xcache：基于 codis、pika、redis 自研的一套海量 KV 存储解决方案
1.2 缓存应用模式介绍
应用模式次要分为 2 种：
1.cache 模式：数据不须要长久化，实例复原不须要加载数据，扩缩容不须要迁徙数据
2.store 模式：数据须要长久化，实例复原须要加载数据，扩缩容须要迁徙数据
上面是对各种类型缓存做了简略比照：
2. 缓存应用军规
2.1 缓存类型应用标准
1）redis 集群模式首选云数据库 redis，海量 KV 存储首选 xcache
云数据库 redis 采纳官网 redis cluster 模式，容器化部署，反对故障主动复原和弹性伸缩，是以后 redis 集群的主推计划，但不反对数据长久化，如果必须要做数据长久化，并且对延时要求十分高，能够应用 codis redis。数据量十分大，并且对延时要求不是特地高，能够抉择 xcache。
2） redis 不要当 db 应用 ，如果数据肯定要做长久化，能够抉择 xcache
redis 当 db 应用，故障复原数据很慢，重大影响 SLA。并且如果主从全副挂掉，slave 机器无奈复原时，数据就会齐全失落。xcache 人造反对数据长久化
3） 不要应用客户端分片模式
客户端分片模式不具备高可用和弹性伸缩能力，倡议应用真正的集群模式，如 codis-redis、云数据库 redis、xcache
4）集群模式不反对 lua、redisson 客户端，如果业务必须应用，只能抉择 redis 主从模式
5）redis 单节点容量不要超过 10GB，xcache 单节点容量不要超过 200GB
redis 单节点容量太大时，实例重启会比较慢，影响复原时长
2.2 键值设计规范
1）key 尽量放弃简洁性、可读性、可管理性
在保障语义的前提下，管制 key 的长度；以业务名 (或数据库名) 为前缀 (避免 key 抵触)，用冒号分隔，比方业务名：表名:id；不要蕴含特殊字符
2） 回绝 bigkey ，避免网卡流量过高、慢查问
string 类型管制在 10KB 以内，hash、list、set、zset 元素个数不要超过 5000
3）防止热点 key
热 key 会导致数据歪斜，以及单节点压力过大。倡议业务侧将热 key 打散
4）管制 key 生命周期
缓存不是垃圾桶，最好对 key 都设置 ttl，并且将 key 的 ttl 打散，防止 key 集中过期
2.3 命令应用标准
1）慎用全量操作命令
禁用 keys * 命令，尽量不应用 hgetall、smembers 等命令。在获取 key 下的多个元素时，应用相应的 scan 命令，一次获取大量元素，分屡次获取，倡议一次 scan 不要超过 200 个
2）管制 mset、mget、hmset、hmget、scan、range 等命令单次操作元素数量，倡议 不要超过 200
3）管制 pipeline 中命令的数量，倡议 不要超过 100
4）redis 删除 key 时，不要用 del 命令，应用 unlink 命令
del 一个大 key 会间接导致 redis 卡住。应用 unlink 命令能够异步删除 key，不会对 redis 主线程产生影响，因而也不会影响业务流量
5）set 和 expire 命令合并成 setex 命令，缩小服务端写压力
6）evalsha 代替 eval
redis-cluster 集群中应用 evalsha 代替 eval，缩小网络 IO，同时也减小 redis 网络 IO 压力进步性能
2.4 业务缓存架构标准
1） redis 不要应用逻辑 db ，只应用默认 db 0
能够通过实例隔离，不同业务的数据保留到不同的实例中。（只有 redis 主从能够抉择逻辑 db，集群模式默认都应用 db0）
2）防止多业务复用同一缓存资源
不同业务的数据应用不同的集群，S 级利用不要和 B 级利用混用，过多业务复用同一资源要做拆分。业务尽量提供 rpc 接口给其它业务调用，而不是间接让其它业务拜访数据源（如一个业务写，一个业务读）
3）xcache 尽量应用 string 类型
xcache 反对 string，hash，ehash，list，set，zset 六种数据类型，ehash 数据类型是对 hash 数据类型的扩大，反对对 field 设置过期工夫。xcache 中 string 类型是速度最快的，其余数据类型都是由 string 进行组合变换而实现，六种数据的性能如下：
string > hash > set > ehash > list > zset
倡议：尽量应用 string 类型
4）缩小 lua 脚本应用
集群模式对 lua 反对有限度，必须保障 lua 中操作的 key 被 sharding 到同一个节点。所以尽量减少对 lua 的应用
5）lua 脚本中不跑简单逻辑
简单逻辑放在业务代码中，而不是 lua 脚本中
6）采纳高效序列化办法和压缩办法
为了节俭内存，如果 value 较大时，能够应用压缩工具（如 snappy 或 gzip），把数据压缩后再写入 redis
7）防止批量工作、定时工作、周期工作流量太大影响在线业务
批量工作、定时工作、周期工作业务上要做限速
8）业务变更，存储流量模型变动要先评估
业务模型变动，QPS、容量减少，O (N) 命令增多等都要先评估以后缓存是否抗的住，做到灰度上线，继续察看（尤其是流量高峰期）
9）不必的资源尽早申请回收
休眠资源回收不仅能够升高业务的存储老本，还能够把资源分配给真正须要的业务，堪称是双赢
补充：OpenAtom 开源大赛 Pika 赛题放出，奖金 50 万，请扫描如下二维码进行 报名：
大家也能够增加 Pika 助手，退出 Pika 微信群，理解更多动静音讯：