AirJD 焦点
AirJD

没有录音文件
00:00/00:00
加收藏

内存数据库服务运营之路 by 启盼cobain@新浪微博

发布者 devops
发布于 1436837154808  浏览 2531 关键词 Redis, NoSQL, 数据库 
分享到

第1页

内存数据库服务运营之路

@启盼cobain



第2页

“RAM is the new disk...”

— Jim Gray



第3页

⺫⽬目录

• 新浪内存数据库服务发展历程 • 内存数据应⽤用存储架构演进

• 计数服务存储演化 • 社交图谱存储演化 • OPS组织结构及运维系统架构演进 • 反思与总结



第4页

2011-2015



第5页

Redis(TB)



Memcached(TB)





19.5





6.5



0 2011











In memory application roadmap in Sina



第6页

Redis应⽤用数



Memcached应⽤用数











0 2011











In memory application roadmap in Sina



第7页

16000



Redis⽇日请求数(亿)



Memcached⽇日请求数(亿)









0 2011











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



Master



Slave



Client

Master



Slave



第11页

应对跨机房数据更新



• 消息总线 (e.g. WMB)



set 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



DC2 Replicate Cache



Cacheservice



DC1 Update



Cache



Client



DC2 Replicate



Procsso r



Cache



Database



replication



Database Mytq



第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 ⽤用户关注 数,粉丝数,微博数)



Client

Hash(Sharding key)%n



set get



RReRededisdisscisount er shard



第18页

计数服务存储演化



Client



set 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)



Client

Hash(Sharding key)%n



set get



• 内存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页

社交图谱存储演化



• 社交图谱 - 中期阶段 • check attention/followers • Redis Hashset • MySQL+Mytrigger+Redis



Graph service



hgetall hexists



INSERT INTO att VALUES(from_uid, to_uid)



MySQL Cluster

id1|from_uid1|to_uid1 id2|from_uid1|to_uid2



Mytrgger



Redis storage Cluster

Hashset

hset

(粉丝逻辑未变)



第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运维系统架构演进



• ⼩小作坊运维



• 独⽴立监控报警系统



运维系统



• 多套运维系统共存

• ⼯工单进展难以跟踪

• 运维系统多语⾔言开发 php python



监控&报警 Cacti



服务初始 化



WebUI

配置变更 服务扩容



Mon



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



支持文件格式:*.ppt, *.pptx, *.pdf
上传最后阶段需要进行在线转换,可能需要1~2分钟,请耐心等待。