董道光-喜马拉雅千万级并发缓存治理思考-ShardingSphere Meetup 上海站

1 .「Apache ShardingSphere - 喜马拉雅 2023 Meetup」 千万并发缓存治理思考 缓存技术专家 董道光 

2 .目录 • 喜马拉雅 KV 存储发展历程 • 大规模缓存治理思考与实践 • 未来规划及业界趋势 

3 .目录 • 喜马拉雅 KV 存储发展历程 • 大规模缓存治理思考与实践 • 未来规划及业界趋势 

4 .redis 主从模式 Client 容量受限 Client 扩缩容丢数据 对key哈希路由 Redis Redis Redis Redis Redis Redis Redis Redis 

5 .redis 集群 常见集群方案 Redis Cluster Ø 去中心化，官方正版 Ø 组件少，部署简单 Ø 系统高度耦合，升级困难 Ø 缺少大规模生产环境验证 Twemproxy Ø proxy代理，推特开源 Ø 无法平滑扩容缩容，运维不够友好 Codis Ø proxy代理，豌豆荚开源 Ø 兼容Twemproxy，性能优于Twemproxy Ø 平滑扩容缩容，可视化管理界面 Ø 产品成熟，很多公司已经在生产环境使用 

6 .Codis redis 集群架构 Client zookeeper （jodis） Proxy Proxy Proxy 集群管理 Codis-fe Redis Redis Redis dashboard Redis Redis Redis sentinel Group Group Group 

7 .Codis redis 扩缩容 Proxy Group 1 Group 2 Slot 0～511 Slot 512～1023 

8 .Codis redis 扩缩容 Proxy Group 1 Group 2 Group 3 Group 4 Slot 0～255 Slot 512～767 Slot 256～511 Slot 768～1023 Slot 256～511 Slot 768～1023 Slot迁移 

9 .Codis redis 存在的问题 Ø 数据全部存储在内存中，消耗大量内存 Ø 业务数据规模较大时，redis实例较多，运维成本高 Ø 实例重启需要加载数据，故障恢复时间长 Ø 一主多从, 主从切换代价大 

10 .大容量持久化KV存储 pika Ø 类redis存储系统、完全兼容redis协议 Ø 兼容string、hash、list、zset、set的绝大多数接口 Ø 使用磁盘存储数据 Ø 多线程工作模型 Ø 360开源、社区活跃 

11 .Codis pika 集群架构 Client zookeeper （jodis） Proxy Proxy Proxy 集群管理 Codis-fe Pika Pika Pika dashboard Pika Pika Pika sentinel Group Group Group 

12 .Codis pika 存在的缺陷 Ø 数据量较大时，读磁盘经常出现延时抖动 Ø 底层数据compact时，IO高导致延时毛刺 Ø 基于key的数据迁移，扩缩容太慢 Ø 数据存在磁盘，机器内存利用率低 Ø 监控不够完善，定位问题困难 

13 .XCache 自研 + 社区 容量大、高吞吐、 Codis pika XCache 低延时、高可用、 运维完善 

14 .XCache 冷热数据分离 • pika物理机空闲内存多， 太浪费？ 加缓存 • 数据量大时，读命令经常 出现延时抖动？ 

15 .XCache 热数据缓存 架构方案1：在 pika 的基础上增加一层 redis 做 cache clients 缺点： CRC32(key)%1024 Ø 组件太多，增加了运维成本。 proxy Ø 多了一层网络传输，带来一定的性能损 耗。 slot0 slot255 slot256 slot511 slot512 slot767 slot768 slot1023 conn conn conn conn conn conn conn conn redis redis redis redis slot 0-255 slot 256-511 slot 512-767 slot 768-1023 pika pika pika pika master slave master slave group1 slot 0-511 group2 slot 512-1023 

16 .XCache 热数据缓存 架构方案 2：将 redis 以 lib 库的方式嵌入到 pika 中 clients 缺点： CRC32(key)%1024 proxy Ø 开发量大，需要对redis和pika做深度 定制。 slot0 slot511 slot512 slot1023 conn conn conn conn MEM-cache MEM-cache MEM-cache MEM-cache SSD-store SSD-store SSD-store SSD-store pika master pika slave pika master pika slave group1 slot 0-511 group2 slot 512-1023 

17 .XCache 冷热数据分离 Ø 读命令吞吐量提升一倍 Ø 复杂数据类型TP100延时降低90%以上 

18 .XCache KV分离存储 • 数据写入量大，底层磁盘 IO负载过高？ KV分离存储 • 大value场景下，写请求经 常发生阻塞？ 

19 .XCache KV分离存储 LSM-tree介绍 LSM-tree（Log-Structured Merge-Tree）全称日志结构合并树。其原理是把一棵大树拆 分成N棵小树，它首先写入内存中，随着小树越来越大，内存中的小树会flush到磁盘中，磁 盘中树定期可以做merge操作，合并成一棵大树。 

20 .XCache KV分离存储 rocksdb的compact原理 

21 .XCache KV分离存储 rocksdb的compact导致写放大问题 什么是写放大？ 实际写入磁盘数据大小和程序要求写入数据大小之比。 写放大简单分析 • +1，写WAL • +1，Immutable Memtable 写入到 L0 文件 • +2，L0 和 L1 compaction（L0 SST 文件的 key 范围是重叠的，出于性能考虑，一般尽量 保持 L0 和 L1 的数据大小是一样的，每次拿全量 L0 的数据和全量 L1 的数据进行 compaction） • +11，Ln-1 和 Ln 合并的写入（n >= 2，默认情况下，Ln 的数据大小是 Ln-1 的 10 倍） 所以，总的写放大是 4 + 11 * (n-1) = 11 * n - 7 倍，关键是 n 的取值。 

22 .XCache KV分离存储 《WiscKey》 优化思路：在LSM-tree上做key和value分离存储。 

23 .XCache KV分离存储 rocksdb 存储引擎改造 Ø Compact磁盘负载降低50% Ø 大vaule写入QPS提升5倍 

24 .XCache 快慢命令分离 • 执行应该很快的请求为什 么也会超时？ 快慢命令分离 • 每次超时都是一批请求超 时？ 

25 .XCache 快慢命令分离 Ø 业务TP9999延时数量降低80%以上 

26 .XCache 秒级扩容 • 故障紧急扩容，但需要做 数据迁移，太慢，严重影 秒级扩容 响恢复时长 

27 .XCache 秒级扩容 Proxy 0～511 512～1023 Group 1 Group 2 master master slave slave 

28 .XCache 秒级扩容 Ø 扩容速度从小时级别降到秒级别 Proxy 0～255 512～767 256～511 768～1023 Group 1 Group 2 Group 3 Group 4 master master master master slave slave 

29 .XCache 开源贡献 Ø 公司的第一个开源项目 Ø 快手、得物、BOSS直聘等公司对接使用 Ø 多次为开源社区提交pr