新浪微博redis优化历程

2020-02-27 201浏览

1.新浪微博redis优化历程陈波 @ﬁshermen
2.大纲 • 业务场景 • Redis存储架构演进 • 一些经验 • Q&A
3.业务场景-业务 • Redis在新浪微博的应用计数 (counter) 通知提醒关系 (graph)
4.业务场景-数据 • 一些数据 6 IDC 500+servers 3700+ instances 千亿条记录 24T+内存 7千亿cmds/day 1.2万亿read/day 2千亿write/day
5.Redis存储前时代
6.Redis前时代 • 热数据mc • 全量落地mysql • 数据量不大：Graph mc 10G，计数器 mc 2G • 开发速度
7.问题出现 • 2010年，Graph mc 30G+，峰值 10wTPS • Mysql成为瓶颈 – 线程阻塞，访问卡顿 – List类型业务不适合mysql • 新的关系计算需求实现困难 – 大量关系计算：从MC取全量+本地计算->超时
8.解决方案 • 初期方案 – 增大mc容量到40G，Graph db 增至一主六从 – 监控并及时清理僵死线程 – 关系计算性能问题暂时无解 • 最终方案 – – – – 引入Redis做storage (graph/counter) 关系计算在redis实现 O(1) 促进更多复杂需求 Graph db恢复一主三从
9.小结 • 项目初期 – 30G- 日PV5kw- – 技术选型熟悉度 – 拼的是开发速度 • 产品需求与新技术相互促进
10.Redis存储初期
11.Redis初期 • Redis 2.0 • Graph存hash，40G 10w TPS，4 Server •Counter:20G2w TPS，2 Server
12.问题出现 • 2011年，初期使用经验不足 – 数据分片过少，扩容困难 – 部分数据类型使用不当，内存超预期 – 多业务混放，拆分不便 • 可用性不够 – 小业务初期没有slave，server故障à服务异常 – 大业务挂载3-4个slave，高峰期write超时，请求失败 • 重启耗时，10-20分钟服务异常
13.解决方案 • 容量规划 – 提前预估容量，上线前预拆足够的数据分片 – 选择合适的数据类型，慎用zset – 业务独立存储，拒绝混放
14.解决方案 • 提高可用性 – 所有Redis全部增加Slave – Master挂载slave不超过2个，采用M-S-S方式挂载 – 多IDC 单Master，复制同步 • 凌晨低峰升级，访问 IPà域名 – 不完美，但基本可work
15.问题升级 • 2011年底，Graph 100G+ 灵异事件 – 凌晨3点低峰期，redis无征兆崩溃 – 批量升级、扩容拆分，引发其他业务异常报警 • 多个slave严重负载不均，请求数最大差1-2个数量级，峰值响应从不足1ms->3ms • 在线版本增多 – 最多6个版本 – BUG重复修复，运维困难
16.问题分析 • 崩溃：读写会用pageCache，导致redis进 swap而崩溃 • 其他服务报警：复制全量推送导致网络阻塞 • 负载不均：client通过域名访问，域名解析返回随机ip，结果连接不均衡，最终导致负载不均衡
17.问题解决 • 紧急方案 – 超过物理内存3/5à迁移端口 – 错峰升级/扩容对网络仍然有一定冲击 – 开发ClientBalancer组件，保持域名下IP连接均衡，负载均衡 • 进一步优化方案： – 及时清理pagecache，减少对正常业务影响 – Aof去掉rewrite，改用rotate – 类似mysql，独立IO线程对rdb、aof转发复制（社区版psync, repl-backlog-size, repl-backlog-ttl） – 支持热升级，避免重启，提高可运维性 – Others…
18.小结 • 小规模 50G 1-2个集群 – 人肉运维 • 中规模 100G+，3+集群 – 可运维性->重要 – 开源组件->熟悉架构实现
19.Redis存储爆发期
20.Redis存储爆发期 • 完全增量复制 • 在线热升级 • SLAVE均衡访问 • 大量子业务切入 • 单业务数百G稳定
21.问题出现 • 2013年，Graph海量规模 – 数据T级，MS 十T级 – 数百台server，而且还在快速增加 – Graph用Hash结构，存储效率不高
22.问题出现 • Counter 业务增加，增长迅猛 – 日增：计数亿条内存5G+ – 总数据百G级， MS T级 – Feed请求计数近百倍读放大，高峰超时报警 – 存储效率低 <30% 2013000001.rep 800 2013000001.cmt 360 2013000001.like 1000 2013000001.read 10000
23.问题出现 • 占用机器增加迅猛，成本合理性需要考虑 • 部分机房机架饱和
24.解决方案 • Graph – 定位：storageàcache – 定制：hashàLongset • Counter – 定制cdb，通过table分段存储计数 – 一个KV存多个计数 2013000001.rep 800 2013000001.cmt 360 2013000001.like 1000 2013000001.read 10000 2013000001 800 360 1000 10000
25.解决方案 • Counter存储结构 – cdb=schema+tables – 计数double-hash寻址，消除冗余robj存储结构 – 冲突过多aux_dict – 数值过大extend_dict • 多管齐下，节省数百台机器 • 下线低配server，寻找廉价新机房
26.小结 • 量变->质变，极端业务定制 • 大规模集群 T级 3+idc 成本 – 单个请求成本 – 总拥有成本
27.Redis存储高速稳定期
28.Redis存储高速稳定期 • Graph 定位cache 定制longset – 内存降为 1/10 – 性能接近 • Counter 定制cdb – 内存降为 1/5 - – 性能增3-5倍
29.Redis存储高速稳定期 • 继续定制 – Counter 落地SSD，容量提升20倍，8个月à10年 – Vector – Others…
30.问题出现 • 2014，SLA 目标6个9 – 数千关联Server 6+IDC 跨地域分布 – 海量数据 24T+ – 峰值 5000w+ TPS，响应毫秒级 – 硬件/网络故障时有发生，如何实现？
31.问题解决 • 资源服务化 à – Conﬁgserver用于服务的发布与订阅 – CacheService 用于集群管理 ª数据路由 ª负载均衡 ª数据在线迁移 ª服务治理（生命周期故障转移etc.） – 运维标准化、自动化（扩/缩容etc.）
32.服务化
33.服务化 • 服务化 à – 业务服务化 motan ✓ – 资源服务化 à
34.小结 • 避免过早优化，小步快跑 • 架构没有最好，只有更适合
35.一些经验 • 结合发展阶段选择最合适的技术和架构，避免过早优化 • 拥抱需求，需求、技术相互促进 • 解决问题的root cause
36.Q&A