内存数据库服务运营之路

@启盼cobain

“RAM is the new disk...”

— Jim Gray

⺫⽬目录

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

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

2011-2015

Redis(TB)



Memcached(TB)





19.5





6.5



0 2011











In memory application roadmap in Sina

Redis应⽤用数



Memcached应⽤用数











0 2011











In memory application roadmap in Sina

16000



Redis⽇日请求数(亿)



Memcached⽇日请求数(亿)









0 2011











In memory application roadmap in Sina

2011-2015

• ⾯面临挑战 • 2011微博索引Memcached请求量翻番 －> 缓存失效⻛风险 • 2012微博计数服务Redis改造上线 －> Redis⾼高可⽤用 • 2013异地机房部署 －> 跨机房数据更新 • 2013微博核⼼心缓存请求量再次翻番 －> 缓存⾯面临超级热点 • 2013年内存容量增⻓长三倍 －> Redis应⽤用内存疯⻓长 • 2013 2014 App数量及请求量增⻓长四倍 －> 运维效率 • 2015 2016 ?

Memcached Roadmap in Sina

应对缓存实效⻛风险



• 共享内存，更多分⽚片 (without multiget)

• 主备缓存(with multiget)



set

get Client



Master



Slave



Client

Master



Slave

应对跨机房数据更新



• 消息总线 (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

应对超级热点



• 多级缓存 • 核⼼心缓存快速构建数据副本

• Memcached L1 Group



Frontend Local



App



L0



Frontend Local



App



L0



Core API L1 L1 L1



Master



Slave

Redis Roadmap in Sina

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

…

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

应⽤用存储架构演进 • 计数服务存储演化

计数服务存储演化



• ⼗十亿级计数

• ⽤用Redis存储1亿计数需要多 ⼤大空间？

• ⽤用户纬度增⻓长(e.g ⽤用户关注 数，粉丝数，微博数)



Client

Hash(Sharding key)%n



set get



RReRededisdisscisount er shard

计数服务存储演化



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

计数服务存储演化



• 千亿级计数 (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

应⽤用存储架构演进 • 社交图谱存储演化

社交图谱存储演化



• 社交图谱 － 初级阶段



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

社交图谱存储演化



• 社交图谱 － 中期阶段 • 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

（粉丝逻辑未变）

社交图谱存储演化



• 社交图谱 － 进阶 • 内存占⽤用成本



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

社交图谱存储演化

• 未来计划－持续分级存储 • 存储层冷热分离⾄至HBase • 缓存层冷热分离⾄至SSD

DBA

OPS系统更要给⼒力...

OPS运维系统架构演进

• ⼩小作坊运维 • 运维系统1.0 • 运维系统2.0

OPS运维系统架构演进



• ⼩小作坊运维



• 独⽴立监控报警系统



运维系统



• 多套运维系统共存

• ⼯工单进展难以跟踪

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



监控&报警 Cacti



服务初始 化



WebUI

配置变更 服务扩容



Mon



Ganglia

CMDB 运维数据 监控数据



⼯工单



…

其他R&D 系统

OPS运维系统架构演进



• 运维系统1.0 • 统⼀一中⼼心管理 • 单模块架构



运维系统



WebUI



应⽤用Dashboard



监控配置 服务初始



管理



化



配置变更



服务扩容



…



• 运维系统统⼀一python



Saltstack

运维调度 CMDB 运维数据 系统



RT R&D API

监控数据 ⼯工单系统 其他基础 系统依赖

OPS运维系统架构演进



• ⼯工业时代2.0

• 模块化，服务化， 可持续迭代

• 数据驱动



WebUI



Restful API



运维系统 应⽤用Dashboard



监控服务



初始化服 务



配置变更 服务



扩容服务



基础功能API



…



Saltstack

运维调度 CMDB 运维数据 系统



RT R&D API

监控数据 ⼯工单系统 其他基础 系统依赖

反思与总结

• 应⽤用驱动，不幻想需求 • 没有银弹，避免滥⽤用 • 架构尽量化繁为简 • 运维友好，保证服务⽣生命⼒力 • 分享，好的技术应该推⼲⼴广 • 服务意识，关注应⽤用视⾓角

反思与总结

• Think big, act small!

Q&A

We are Hiring!

recruiting-apac@appannie.com