⼤大数据时代 feed架构

新浪微博 @TimYang

当前架构



端 Web



客户端



平台 接⼊入层



内⺴⽹网核⼼心池



内⺴⽹网池



开放平台 公⺴⽹网池



平台



feed



服务层 算法



微博 内容



关系



⽤用户



评论



短链



私信



Config Service



RPC Cache-Service



Motan



!



中间层



MC Redis



超⻓长列表 计数服务



SLA体系 Trace体系 TouchStone



MQ(mcq) Firehose



算 法 策 略



存储层



MySQL



HBase



Redis(存储)



分布式⽂文件

当前架构



每天数百亿调⽤用



端 Web



客户端



平台 接⼊入层



内⺴⽹网核⼼心池



内⺴⽹网池



开放平台 公⺴⽹网池



平台



feed



服务层 算法



微博 内容



关系



⽤用户



评论



短链



私信



Config Service



RPC Cache-Service



Motan



!



中间层



MC Redis



超⻓长列表 计数服务



SLA体系 Trace体系 TouchStone



MQ(mcq) Firehose



算 法 策 略



存储层



MySQL



HBase



Redis(存储)



分布式⽂文件

当前架构



每天数百亿调⽤用



端 Web



客户端



平台 接⼊入层



内⺴⽹网核⼼心池



内⺴⽹网池



开放平台 公⺴⽹网池



平台



feed



服务层 算法



微博 内容



关系



⽤用户



评论



短链



私信



Config Service



服务化



RP!C Cache-Service



Mot!an



!



中间层 !



!

MC Redis



超⻓长列表 计数服务



SLA体系 Trace体系 TouchStone



MQ(mcq) Firehose



算 法 策 略



存储层



MySQL



HBase



Redis(存储)



分布式⽂文件

当前架构



每天数百亿调⽤用



端 Web



客户端



平台 接⼊入层



内⺴⽹网核⼼心池



内⺴⽹网池



开放平台 公⺴⽹网池



Config Service



平台



feed



服务层 算法



微博 内容



关系



⽤用户



服务化



性能



RP!C Cache-S!ervice



Mot!an



!!



中间层 !



!



!!



MC Redis



超⻓长列表 计数服务



评论



短链



私信



SLA体系 Trace体系 TouchStone



MQ(mcq) Firehose



算 法 策 略



存储层



MySQL



HBase



Redis(存储)



分布式⽂文件

当前架构



每天数百亿调⽤用



端 Web



客户端



平台 接⼊入层



内⺴⽹网核⼼心池



内⺴⽹网池



开放平台 公⺴⽹网池



Config Service



平台



feed



服务层 算法



微博 内容



关系



⽤用户



服务化



性能



RP!C Cache-S!ervice



Mot!an



!!



中间层 !



!



!!



MC Redis



扩展性

! 超⻓长列! 表

! 计数服! 务



评论



短链



私信



SLA体系 Trace体系 TouchStone



MQ(mcq) Firehose



算 法 策 略



存储层



MySQL



HBase



Redis(存储)



分布式⽂文件

当前架构



每天数百亿调⽤用



端 Web



客户端



平台 接⼊入层



内⺴⽹网核⼼心池



内⺴⽹网池



开放平台 公⺴⽹网池



Config Service



平台



feed



服务层 算法



微博 内容



关系



⽤用户



服务化



性能



RP!C Cache-S!ervice



Mot!an



!!



中间层 !



!



!!



MC Redis



扩展性

! 超⻓长列! 表

! 计数服! 务



评论



短链



私信



可⽤用性

SLA!!体系 Trace! 体系

!

TouchStone



MQ(mcq) Firehose



算 法 策 略



存储层



MySQL



HBase



Redis(存储)



分布式⽂文件

当前架构



每天数百亿调⽤用



端 Web



客户端



平台 接⼊入层



内⺴⽹网核⼼心池



内⺴⽹网池



开放平台 公⺴⽹网池



Config Service



平台



feed



服务层 算法



微博 内容



关系



⽤用户



服务化



性能



RP!C Cache-S!ervice



Mot!an



!!



中间层 !



!



!!



MC Redis



扩展性

! 超⻓长列! 表

! 计数服! 务



评论



短链



私信



可⽤用性

SLA!!体系 Trace! 体系

!

TouchStone



实时数据流



! MQ(mcq)!

! Firehose !



算 法 策 略



存储层



MySQL



HBase



Redis(存储)



分布式⽂文件

架构特点

✓ 解决了数据规模⼤大且超⻓长LIST访问的问题

 ✓ MySQL sharding by time range



✓ 解决了数据存储可扩展的问题

 ✓ 2~3 years



✓ 解决了百万QPS访问的问题

 ✓Cache replication及分级



✓ 解决了可⽤用性及错误隔离问题

 ✓ by SLA体系，核⼼心功能 99.99%+

读写⽐比例⾼高 冷热数据明显 存在热点问题

⾼高访问量



10:1读写⽐比以上

80%访问的是当天内的数据

峰值写⼊入80万/分钟!

(2014元旦)

每天超过7000万⽤用户访问!

(2014Q3数据)

读写⽐比例⾼高 冷热数据明显 存在热点问题

⾼高访问量



10:1读写⽐比以上

80%访问的是当天内的数据

峰值写⼊入80万/分钟!

(2014元旦)

每天超过7000万⽤用户访问!

(2014Q3数据)



⼤大数据环境的性能解决之道 — 缓存

⼤大数据环境的

 性能解决之道

Service



L1/LRU Pool 1



L1/LRU Pool 2



L1/LRU Pool 3



Master Pool



Slave Pool

⼤大数据环境的

 性能解决之道

Service



L1/LRU Pool 1

主数据

Master Pool



L1/LRU Pool 2



L1/LRU Pool 3

Slave Pool

⼤大数据环境的

 性能解决之道

Service



L1/LRU Pool 1

主数据

Master Pool



L1/LRU Pool 2



L1/LRU Pool 3

副本（对等）

Slave Pool

L1/LRU Pool 1



⼤大数据环境的

 性能解决之道



Service



分级缓存 - 副本 （可选）



L1/LRU Pool 2



L1/LRU Pool 3



主数据

Master Pool



副本（对等）

Slave Pool

L1/LRU Pool 1



⼤大数据环境的

 性能解决之道



Service



分级缓存 - 副本 （可选）



L1/LRU Pool 2



L1/LRU Pool 3



分层设计 解决热数据 性能



主数据

Master Pool



副本（对等）

Slave Pool

• 如何使⽤用缓存模型来解决可⽤用性及性能问题 • ⼆二级缓存的运作机制详解



Client0



Client1



Cache service

Write



Cache service

read

L1L1



Master



Slave

feed性能 - 总结

‣ Local cache?

 ‣ 删除实现复杂

 ‣ 可以通过短超时⽅方式

 ‣ 极热数据的带宽问题需要提前考虑

feed消息队列

Feed 发表



Data Center 2



其他 业务



Firehose



Data change event Fanout



Input Fanout



Fanout



feed mq



mcq



mcq



msg processor



worker



worker



worker



worker



Hadoop / Spark



画像 标签



⼲⼴广告 Appli推荐 cations



开放 平台



feed存储

cache redis mysql



多机房分发



worker (in)



worker (out)

feed消息队列



Feed 发表

信息流处理



其他 业务



Firehose



Data change event Fanout



Input Fanout



Fanout



feed mq



mcq



mcq



msg processor



worker



worker



worker



worker



多机房分发



worker (in)



worker (out)



Data Center 2



Hadoop / Spark



画像 标签



⼲⼴广告 Appli推荐 cations



开放 平台



feed存储

cache redis mysql

feed消息队列



流式计算



Feed 发表

信息流处理



其他 业务



Firehose



Data change event Fanout



Input Fanout



Fanout



feed mq



mcq



mcq



msg processor



worker



worker



worker



worker



多机房分发



worker (in)



worker (out)



Data Center 2



Hadoop / Spark



画像 标签



⼲⼴广告 Appli推荐 cations



开放 平台



feed存储

cache redis mysql

feed消息队列



流式计算



其他 业务



Firehose



Data change event Fanout



Input Fanout



Fanout



Feed 发表

信息流处理



feed mq



mcq



mcq



msg processor



worker



worker



worker



worker



分布式 多机房



多机房分发



worker (in)



worker (out)



Data Center 2



Hadoop / Spark



画像 标签



⼲⼴广告 Appli推荐 cations



开放 平台



feed存储

cache redis mysql

架构特点(1)



✓实时：处理时间 100ms 以内





✓性能



可扩展：⽆无状态设计，简单增加节点扩 容





✓可⽤用性：99.99%+，⾃自动failover，⽆无单点

架构特点(2)

✓统⼀一实时推送通道 — mcq & firehose



✓数据流 统⼀一数据流，职责分明，解决三 ⼤大需求

 ✓标准化格式，internal probuf 格式

firehose - 实时的业务数据流



Consumer!



Group



Consumer Consumer Producer Producer



✓ ⼀一对多(pub-sub) ✓ 实时数据流



Config! Service



broker



broker



broker



broker! (slave)



broker! (slave)



broker! (slave)



放⼤大

Broker



Memory! Queue



Offset! Magager

Topic! Magager



Cold! Data! Buffer



✓ 补推能⼒力

✓ 数据量⼤大，每秒 数万条

✓ 可靠性

✓ Fan-out

Storm⽐比较

‣ msg processor相对于storm没有调度 (nimbus)功能；



‣ 没有bolt的streaming串联功能，但可以通过 在任务中重写对应业务的mq消息间接实现

Databus⽐比较

‣ Databus基于数据库事件触发消息到总线；

 ‣ 我们使⽤用⾃自⾏行写⼊入消息到firehose的⽅方式

Kafka⽐比较

‣ feature基本类似，firehose更偏业务

 ‣ pub-sub/offset/at least once



‣ 都不⽀支持 timeline consistency，不保证时序

 ‣ 社交产品⼤大多数场景适合

实时数据流 - 总结



Feed Events



Queue



Application Application Application



‣ 罗⻢马不是⼀一天建成的

 ‣ ⾃自定义队列满天⻜飞的时代的痛苦

 ‣ 尝试过databus trigger⽅方式

 ‣ 需要具有抽象共性的意识

 ‣ Lambda architecture

多元化存储



数据类型

微博内容

微博列表

关系

⻓长微博 图⽚片/短视频 计数 (微博数 阅读数…）



特点

类型简单 海量访问

结构化列表数据 多维度查询

类型简单 ⾼高速访问

块数据 ⼩小⽂文件

结构简单 数据及访问量⼤大



存储解决⽅方案

关系型数据库 分布式Key - Value

关系型数据库 NoSQL

内存式 key-value key-list结构

分布式⽂文件系统

内存紧凑型 NoSQL



存储产品

MySQL HBase MySQL MySQL Redis

Redis

多元化存储



数据类型

微博内容

微博列表

关系

⻓长微博 图⽚片/短视频 计数 (微博数 阅读数…）



特点

类型简单 海量访问

结构化列表数据 多维度查询

类型简单 ⾼高速访问

块数据 ⼩小⽂文件

结构简单 数据及访问量⼤大



存储解决⽅方案

关系型数据库 分布式Key - Value

关系型数据库 NoSQL

内存式 key-value key-list结构

分布式⽂文件系统

内存紧凑型 NoSQL



存储产品

MySQL HBase MySQL MySQL Redis

Redis

列表型数据



数据类型



结构



单个List ⻓长度



规模



关注



{“uid”: “follow_uid1”, “follow_uid2”… “follow_uidn”}



1-3000 千亿级



粉丝



{“uid”: “fan_uid1”, “fan_uid2”… “fan_uidn”}



1-8000万 千亿级



发表微博列表



{“uid”: “feed_id1”, “feed_id2”… “feed_idn”}



1-100万+ 千亿级



转发微博列表 {“weibo_id”: “repost_id1”, “repost_id2”… “repost_idn”}



1-500万+ 千亿级



评论列表



{“weibo_id”: “cmt_id1”, “cmt_id2”… “cmt_idn”}



1-500万+ 千亿级

列表型数据



类型多

数据类型



结构



单个List ⻓长度



规模



关注



{“uid”: “follow_uid1”, “follow_uid2”… “follow_uidn”}



1-3000 千亿级



粉丝



{“uid”: “fan_uid1”, “fan_uid2”… “fan_uidn”}



1-8000万 千亿级



发表微博列表



{“uid”: “feed_id1”, “feed_id2”… “feed_idn”}



1-100万+ 千亿级



转发微博列表 {“weibo_id”: “repost_id1”, “repost_id2”… “repost_idn”}



1-500万+ 千亿级



评论列表



{“weibo_id”: “cmt_id1”, “cmt_id2”… “cmt_idn”}



1-500万+ 千亿级

类型多

数据类型



列表型数据



变⻓长/超⻓长



结构



单个List ⻓长度



规模



关注



{“uid”: “follow_uid1”, “follow_uid2”… “follow_uidn”}



1-3000 千亿级



粉丝



{“uid”: “fan_uid1”, “fan_uid2”… “fan_uidn”}



1-8000万 千亿级



发表微博列表



{“uid”: “feed_id1”, “feed_id2”… “feed_idn”}



1-100万+ 千亿级



转发微博列表 {“weibo_id”: “repost_id1”, “repost_id2”… “repost_idn”}



1-500万+ 千亿级



评论列表



{“weibo_id”: “cmt_id1”, “cmt_id2”… “cmt_idn”}



1-500万+ 千亿级

类型多

数据类型



列表型数据



变⻓长/超⻓长 ⼤大数据



结构



单个List ⻓长度



规模



关注



{“uid”: “follow_uid1”, “follow_uid2”… “follow_uidn”}



1-3000 千亿级



粉丝



{“uid”: “fan_uid1”, “fan_uid2”… “fan_uidn”}



1-8000万 千亿级



发表微博列表



{“uid”: “feed_id1”, “feed_id2”… “feed_idn”}



1-100万+ 千亿级



转发微博列表 {“weibo_id”: “repost_id1”, “repost_id2”… “repost_idn”}



1-500万+ 千亿级



评论列表



{“weibo_id”: “cmt_id1”, “cmt_id2”… “cmt_idn”}



1-500万+ 千亿级

列表访问效率

列表访问效率

列表访问效率

列表访问效率

列表访问效率

列表访问效率

关系数据库并⾮非为 list scan设计

通⽤用的⼆二级索引

通⽤用的⼆二级索引

count index [6, 12]

通⽤用的⼆二级索引

count index [6, 12]

Offset index [15, 8]

列表性能及成本



2012 ~

2009 shard-1









2012~ 2011



shard-2



shard-3

列表性能及成本



2012 ~

2009 shard-1









2012~ 2011



shard-2



shard-3

列表性能及成本



2012 ~

2009 shard-1



2014 2013



2012~ 2011



pool 1 ⾼高速

设备



shard-2



shard-3

列表性能及成本



2012 ~

2009 shard-1



2014 2013



2012~ 2011



pool 1 ⾼高速

设备



shard-2



shard-3

列表性能及成本



2012 ~

2009 shard-1



2014 2013



2012~ 2011



pool 1 ⾼高速

设备



shard-2



shard-3

列表性能及成本



2012 ~

2009 shard-1



2014 2013

shard-2



2012~ 2011

shard-3



pool 1 ⾼高速 设备

pool 3 廉价 设备

列表存储服务



接⼝口



saveList(id, offset, size)



loadList(id, offset, size)



存储! 策略层



⼀一致性



超⻓长列表 Sharding SLA(QoS) Metrics



Trace



加速层! ⼆二级索引



offset index



count index



存储! 引擎



MySQL



HBase

feed存储 - 总结

‣ 从各⾃自建设到可复⽤用的⽅方向发展

 ‣ 曾尝试mysql-proxy⽅方向，但业务⽅方需

求不强烈



‣ 类似超⻓长列表的服务得到了较好⽀支持

 ‣ 抽象共性问题并解决，⽽而不是增加熵

MySQL Cache Redis



feed展⽰示 过程



Read/write Through



⽤用户 feed-list

⽤用户 feed-list

⽤用户 feed-list

微博特征



关注关系

聚合

算法! (推荐、提权、排序)



⽤用户特征



反馈



反垃圾策略



Feed流 Timeline

⽇日志 Firehose

分析

⽤用户维度

MySQL Cache Redis



feed展⽰示 过程



Read/write Through



⽤用户 feed-list

⽤用户 feed-list

⽤用户 feed-list

微博特征



关注关系

聚合

算法! (推荐、提权、排序)



⽤用户特征



反馈



反垃圾策略



Feed流 Timeline

⽇日志 Firehose

分析

⽤用户维度

MySQL Cache Redis



feed展⽰示 过程



Read/write Through



⽤用⽤户用户维度

feed-list



关注关系



⽤用户 feed-list



聚合



⽤用户 feed-list



微博特征



算法! (推荐、提权、排序)



⽤用户特征



反馈



反垃圾策略



Feed流 Timeline

⽇日志 Firehose

分析

⽤用户维度

MySQL Cache Redis



feed展⽰示 过程



Read/write Through



⽤用⽤户用户维度

feed-list



关注关系



⽤用户 feed-list



聚合



⽤用户 feed-list



算法!

兴微博趣特聚征 类 (推荐、提权、排序)



⽤用户特征



反馈



反垃圾策略



Feed流 Timeline

⽇日志 Firehose

分析

feed展⽰示- 总结



做对的

✓ 成熟的feed推拉聚合 模型

✓ 成熟的⽤用户数据组织 ⽅方式



不⾜足的

๏ 基于⽤用户维度组织内 容⾼高效满⾜足兴趣阅读 的难度

๏ 信息识别及低质内容 鉴定的技术挑战

๏ 反垃圾算法的难度

总结与展望



feed 存储



• Key List • Key Value • SQL



缓存复制 proxy



feed 性能与可⽤用性



微博 feed



feed 消息队列



MQ firehose



Feed展⽰示 聚合、排序



• 趋势 • 降噪、提权 • 反垃圾 • 排序

Q&A



http://timyang.net



TimYang 微信公众号