新浪微博redis优化历程陈波.pdf

新浪微博redis优化历程 陈波 @fishermen 大纲 • 业务场景 • Redis存储架构演进 • 一些经验 • Q&A 业务场景-业务 • Redis在新浪微博的应用 通知提醒 关系 计数 (graph) (counter) 业务场景-数据 • 一些数据 6 IDC 500+servers 3700+ instances 千亿条记录 24T+ 内存 7千亿cmds/day 1.2万亿read/day 2 千亿write/day Redis存储前时代 Redis前时代 • 热数据mc • 全量落地mysql • 数据量不大：Graph mc 10G ，计数器mc 2G • 开发速度 问题出现 • 2010年，Graph mc 30G+ ，峰值10wTPS • Mysql 成为瓶颈 –线程阻塞，访问卡顿 –List 类型业务不适合mysql • 新的关系计算需求实现困难 –大量关系计算：从MC取全量+本地计算->超时 解决方案 • 初期方案 –增大mc 容量到40G ，Graph db 增至一主六从 –监控并及时清理僵死线程 –关系计算性能问题暂时无解 • 最终方案 –引入Redis做storage (graph/counter) –关系计算在redis 实现O(1) –促进更多复杂需求 –Graph db恢复一主三从 小结 • 项目初期 –30G- 日PV5kw- –技术选型熟悉度 –拼的是开发速度 • 产品需求与新技术相 互促进 Redis存储初期 Redis初期 • Redis 2.0 • Graph存hash ，40G 10w TPS ，4 Server • Counter:20G 2w TPS ，2 Server 问题出现 • 2011年，初期使用经验不足 –数据分片过少，扩容困难 –部分数据类型使用不当，内存超预期 –多业务混放，拆分不便 • 可用性不够 –小业务初期没有slave ，server故障服务异常 –大业务挂载3-4个slave ，高峰期write超时，请求失败 • 重启耗时，10-20分钟服务异常 解决方案 • 容量规划 –提前预估容量，上线前预拆足够的数据分片 –选择合适的数据类型，慎用zs