做网站销售的,会计培训班要多少钱一般要学多久,如何创建自己的卡网,做网站有没有免费空间作者#xff1a;喜马拉雅 董道光
宣言#xff1a;缓存不是万金油#xff0c;更不是垃圾桶#xff01;#xff01;#xff01;
缓存作为喜马拉雅至关重要的基础组件之一#xff0c;每天承载着巨大的业务请求量。一旦缓存出现故障#xff0c;对业务的影响将非常严重。因…作者喜马拉雅 董道光
宣言缓存不是万金油更不是垃圾桶
缓存作为喜马拉雅至关重要的基础组件之一每天承载着巨大的业务请求量。一旦缓存出现故障对业务的影响将非常严重。因此确保缓存服务的稳定和高效运行始终是我们的重要目标。
下面是我们对喜马缓存历史故障复盘后总结的一套缓存使用规范在此分享给大家希望小伙伴们能在缓存选型和使用的过程中少踩坑。
1. 缓存选型
1.1 缓存类型介绍
喜马线上缓存类型主要有 4 种
1. redis 主从模式官方原版
2.codis-redis豌豆荚开源redis 集群解决方案
3. 云数据库 redisredis-cluster 容器化部署
4.xcache基于 codis、pika、redis 自研的一套海量 KV 存储解决方案
1.2 缓存使用模式介绍
使用模式主要分为 2 种
1.cache 模式数据不需要持久化实例恢复不需要加载数据扩缩容不需要迁移数据
2.store 模式数据需要持久化实例恢复需要加载数据扩缩容需要迁移数据
下面是对各种类型缓存做了简单对比 2. 缓存使用军规 2.1 缓存类型使用规范
1redis 集群模式首选云数据库 redis海量 KV 存储首选 xcache
云数据库 redis 采用官方 redis cluster 模式容器化部署支持故障自动恢复和弹性伸缩是当前 redis 集群的主推方案但不支持数据持久化如果必须要做数据持久化并且对延时要求非常高可以使用 codis redis。数据量非常大并且对延时要求不是特别高可以选择 xcache。
2redis 不要当 db 使用如果数据一定要做持久化可以选择 xcache
redis 当 db 使用故障恢复数据很慢严重影响 SLA。并且如果主从全部挂掉slave 机器无法恢复时数据就会完全丢失。xcache 天然支持数据持久化
3不要使用客户端分片模式
客户端分片模式不具备高可用和弹性伸缩能力建议使用真正的集群模式如 codis-redis、云数据库 redis、xcache
4集群模式不支持 lua、redisson 客户端如果业务必须使用只能选择 redis 主从模式
5redis 单节点容量不要超过 10GBxcache 单节点容量不要超过 200GB
redis 单节点容量太大时实例重启会比较慢影响恢复时长 2.2 键值设计规范
1key 尽量保持简洁性、可读性、可管理性
在保证语义的前提下控制 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
4redis 删除 key 时不要用 del 命令使用 unlink 命令
del 一个大 key 会直接导致 redis 卡住。使用 unlink 命令可以异步删除 key不会对 redis 主线程产生影响因此也不会影响业务流量
5set 和 expire 命令合并成 setex 命令减少服务端写压力
6evalsha 代替 eval
redis-cluster 集群中使用 evalsha 代替 eval减少网络 IO同时也减小 redis 网络 IO 压力提高性能
2.4 业务缓存架构规范
1redis 不要使用逻辑 db只使用默认 db 0
可以通过实例隔离不同业务的数据保存到不同的实例中。只有 redis 主从可以选择逻辑 db集群模式默认都使用 db0
2避免多业务复用同一缓存资源
不同业务的数据使用不同的集群S 级应用不要和 B 级应用混用过多业务复用同一资源要做拆分。业务尽量提供 rpc 接口给其它业务调用而不是直接让其它业务访问数据源如一个业务写一个业务读
3xcache 尽量使用 string 类型
xcache 支持 stringhashehashlistsetzset 六种数据类型ehash 数据类型是对 hash 数据类型的扩展支持对 field 设置过期时间。xcache 中 string 类型是速度最快的其他数据类型都是由 string 进行组合变换而实现六种数据的性能如下
string hash set ehash list zset
建议尽量使用 string 类型
4减少 lua 脚本使用
集群模式对 lua 支持有限制必须保证 lua 中操作的 key 被 sharding 到同一个节点。所以尽量减少对 lua 的使用
5lua 脚本中不跑复杂逻辑
复杂逻辑放在业务代码中而不是 lua 脚本中
6采用高效序列化方法和压缩方法
为了节省内存如果 value 较大时可以使用压缩工具如 snappy 或 gzip把数据压缩后再写入 redis
7避免批量任务、定时任务、周期任务流量太大影响在线业务
批量任务、定时任务、周期任务业务上要做限速
8业务变更存储流量模型变化要先评估
业务模型变化QPS、容量增加O (N) 命令增多等都要先评估当前缓存是否抗的住做到灰度上线持续观察尤其是流量高峰期
9不用的资源尽早申请回收
休眠资源回收不仅可以降低业务的存储成本还可以把资源分配给真正需要的业务可谓是双赢 补充OpenAtom 开源大赛 Pika 赛题放出奖金 50 万请扫描如下二维码进行 报名 大家也可以添加 Pika 助手加入 Pika 微信群了解更多动态消息
