新浪微博redis优化历程

nbnw

贡献于2016-01-23

字数:0 关键词: NoSQL数据库 Redis

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

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享文档获得金币 ] 0 人已下载

下载文档

相关文档