内存数据库服务运营之路

束莞尔

2018/05/13 发布于 技术 分类

自2010年以来,国内领先的IT专业网站IT168联合旗下ITPUB、ChinaUnix两大技术社区,已经连续举办了五届中国数据库技术大会,每届大会与会规模超千人,大会云集了国内水平最高的数据架构师、数据库管理和运维工程师、数据库开发工程师、研发总监和IT经理等技术人群,是目前国内最受欢迎、人气最高的的数据库技术交流盛会。今年是中国数据库技术大会第六个年头,大会将继续秉承分享IT最佳应用实践的宗旨,围绕传统数据库和大数据两条技术主线,在目前IT技术和管理快速的大背景下,更加深入地探讨数据库技术的现状和未来的发展方向,以及我们在这个转型过程中的实践经验和教训。

文字内容
1. 内存数据库服务运营之路 @启盼cobain
2. “RAM is the new disk...” — Jim Gray
3. ⺫⽬目录 • 新浪内存数据库服务发展历程 • 内存数据应⽤用存储架构演进 • 计数服务存储演化 • 社交图谱存储演化 • OPS组织结构及运维系统架构演进 • 反思与总结
4. 2011-2015
5. Redis(TB) Memcached(TB) 26 19.5 13 6.5 0 2011 2012 2013 2014 2015 In memory application roadmap in Sina
6. Redis应⽤用数 Memcached应⽤用数 240 180 120 60 0 2011 2012 2013 2014 2015 In memory application roadmap in Sina
7. 16000 Redis⽇日请求数(亿) Memcached⽇日请求数(亿) 12000 8000 4000 0 2011 2012 2013 2014 2015 In memory application roadmap in Sina
8. 2011-2015 • ⾯面临挑战 • 2011微博索引Memcached请求量翻番 -> 缓存失效⻛风险 • 2012微博计数服务Redis改造上线 -> Redis⾼高可⽤用 • 2013异地机房部署 -> 跨机房数据更新 • 2013微博核⼼心缓存请求量再次翻番 -> 缓存⾯面临超级热点 • 2013年内存容量增⻓长三倍 -> Redis应⽤用内存疯⻓长 • 2013 2014 App数量及请求量增⻓长四倍 -> 运维效率 • 2015 2016 ?
9. Memcached Roadmap in Sina
10. 应对缓存实效⻛风险 • 共享内存,更多分⽚片 (without multiget) • 主备缓存(with multiget) set get Client 1 1 Master Slave Client 13 Master 2 Slave
11. 应对跨机房数据更新 set • 消息总线 (e.g. WMB) get • 优势:不依赖队列外其他组件 • 劣势:消息总线复杂性较⾼高 • 中间件更新 (e.g. Cacheservice) • 优势:应⽤用透明,相对运维友好 • 劣势:可靠性较低 • 数据库复制 (e.g. MySQL Replication + Mytriggerq + Processor) • 优势:可靠 • 劣势:维护额外数据库同步,消息格 式转化相对受限。 DC1 Update Cache Client DC2 Replicate Procsso r Cache WMBp WMBq WMBq WMBp DC1 Update Cache Client Cacheservice DC2 Replicate Cache DC1 Update Cache Client DC2 Replicate Procsso r Cache Database replication Mytq Database
12. 应对超级热点 • 多级缓存 • 核⼼心缓存快速构建数据副本 • Memcached L1 Group Frontend Local App L0 Frontend Local App L0 Core API L1 L1 L1 Master Slave
13. Redis Roadmap in Sina
14. Redis⾼高可⽤用 • ⼀一主多从 • Slave故障⾃自动摘除 • Master故障选主后闪恢复 RDB Master AOF1 AOF2 AOF3 … Syncing from Slave 1 3-1001 Syncing from 3-901 Slave 2 Master Slave 2 Sync from 3-901 New Master RDB AOF1 AOF2 AOF3 …
15. Redis内存疯涨 • Cache化改造 • store:cache 9:1 -> 6:4 • 数据结构优化 • Redisscounter • Counterservice 存储⼀一个Key 20字节 ,两个Value 4字节计数 a K-V structure DictEntry 16字节 RedisObject 16 字节 SDS Key 32字节 SDS 16字节 X2 3倍容量优化 a K-V structure Key 20字节 Value 4字 节 X2 2倍容量优化 a K-V structure Key 20字节 Value Value 4字 4字 节节 X1
16. 应⽤用存储架构演进 • 计数服务存储演化
17. 计数服务存储演化 • ⼗十亿级计数 • ⽤用Redis存储1亿计数需要多 ⼤大空间? • ⽤用户纬度增⻓长(e.g ⽤用户关注 数,粉丝数,微博数) set Client get Hash(Sharding key)%n RReRededisdisscisount er shard
18. 计数服务存储演化 set Client get • 百亿级计数 (Counterservice 2.0) Hash(Sharding key)%n 最近6个⽉月 • 微博纬度增⻓长(e.g 微博转 6个⽉月前 发评论数) • MySQL热点更新响应不够 稳定 RReRededisdisscisount er Shard MMyMySySQSQLQLL Client Hash(Sharding key)%n CRoReuedndtiseisrserv ice Shard
19. 计数服务存储演化 • 千亿级计数 (Counterservice 3.0) set Client get Hash(Sharding key)%n • 内存table写满后⾃自动dump⾄至 SSD • LRU cache防⽌止历史热点 6个⽉月内table in memory 6个⽉月以前table in SSD RReeddisisCounterservice3.0 Table114 … Table113 Table112 LRU cache Table111 Table110 Dump SSD …
20. 应⽤用存储架构演进 • 社交图谱存储演化
21. 社交图谱存储演化 • 社交图谱 - 初级阶段 Graph list 3. set 1. get Memcached Cluster from_uid : to_uids • graph_list • attention/followers • Memcached + MySQL 2. SELECT * FROM attention/followers WHERE from_uid/to_uid > offset_id LIMIT n; MySQL Cluster(att) id1 from_uid1 to_uid1 id2 from_uid1 to_uid2 MySQL Cluster(fol) id1 to_uid1 from_uid1 id2 to_uid1 from_uid2
22. 社交图谱存储演化 • 社交图谱 - 中期阶段 Graph service hgetall hexists Redis storage Cluster Hashset INSERT INTO att VALUES(from_uid, to_uid) • check attention/followers hset • Redis Hashset • MySQL+Mytrigger+Redis MySQL Cluster Mytrgger id1 from_uid1 to_uid1 id2 from_uid1 to_uid2 (粉丝逻辑未变)
23. 社交图谱存储演化 • 社交图谱 - 进阶 • 内存占⽤用成本 Graph service 3.Lset 1.Lexist / Lget 3.set 1.get Redis cache Cluster Longset Memcached Cluster • Redis Storage到Redis Cache 2. get/ scan • Hset性能瓶颈 2. SELECT * FROM att WHERE from_uid > offset_id LIMIT n; • Longset • 优化⻓长尾存储 MySQL Cluster id1 from_uid1 to_uid1 id2 from_uid1 to_uid2 HBase Cluster rowkey:from_uid1,to_ui d1,timestamp • HBase
24. 社交图谱存储演化 • 未来计划-持续分级存储 • 存储层冷热分离⾄至HBase • 缓存层冷热分离⾄至SSD
25. DBA OPS系统更要给⼒力...
26. OPS运维系统架构演进 • ⼩小作坊运维 • 运维系统1.0 • 运维系统2.0
27. OPS运维系统架构演进 • ⼩小作坊运维 • 独⽴立监控报警系统 运维系统 • 多套运维系统共存 • ⼯工单进展难以跟踪 监控&报警 Cacti 服务初始 化 WebUI 配置变更 服务扩容 Mon • 运维系统多语⾔言开发 php python Ganglia CMDB 运维数据 监控数据 ⼯工单 … 其他R&D 系统
28. OPS运维系统架构演进 • 运维系统1.0 • 统⼀一中⼼心管理 • 单模块架构 运维系统 WebUI 应⽤用Dashboard 监控配置 服务初始 管理 化 配置变更 服务扩容 … • 运维系统统⼀一python Saltstack 运维调度 CMDB 运维数据 系统 RT R&D API 监控数据 ⼯工单系统 其他基础 系统依赖
29. OPS运维系统架构演进 • ⼯工业时代2.0 • 模块化,服务化, 可持续迭代 • 数据驱动 运维系统 WebUI Restful API 应⽤用Dashboard 监控服务 初始化服 务 配置变更 服务 扩容服务 … 基础功能API Saltstack 运维调度 CMDB 运维数据 系统 RT R&D API 监控数据 ⼯工单系统 其他基础 系统依赖
30. 反思与总结 • 应⽤用驱动,不幻想需求 • 没有银弹,避免滥⽤用 • 架构尽量化繁为简 • 运维友好,保证服务⽣生命⼒力 • 分享,好的技术应该推⼲⼴广 • 服务意识,关注应⽤用视⾓角
31. 反思与总结 • Think big, act small!
32. Q&A We are Hiring! recruiting-apac@appannie.com