SNS 底层架构及动态体系

SNS底层架构及动态体系 杨含飞（少昊）淘宝网淘宝SNS架构师

提要 • SNS基本架构 • 动态体系设计 • 推/送？ • 数据模型 • 性能 • 权重 • 存储设计 • Cassadra • Mysql

SNS基本架构

动态体系

动态体系基本概念 • 消息发送队列（发件箱） • 消息接收队列（收件箱） • 热门用户

推送选择 • Pull • Push • 淘宝SNS方案

PULL

PUSH

推拉优缺点 • PULL • 实现简单 • 需要时读取相应的数据 • 牺牲查询性能 • PUSH • 实现复杂 • 对于不活跃的用户也推了数据 • 很好的查询性能

消息分发设计 • 数据模型 • 性能设计 • 权重设计

淘宝SNS推送机制

数据模型

数据模型 • 将Feed数据和用户消息索引分离 • 索引容量小，更易分发及Cache • 分发时只分发消息索引，更为轻量级 • Feed对象可以在不同用户间共享 • 不涉及Feed对象在用户间的迁移

性能设计 • Feed产生峰值1000/s • 分发写索引峰值10000/s • 平均分发好友数10 • Feed查询读索引峰值20000/s

异步化消息分发 • 通过MQ进行消息异步分发 • 分发过程只写Cache • Cache互备 • Cache索引备份到存储

Cache设计

一级Cache • 集成于应用内部 • 基于本地内存操作 • 需要进行服务器间状态同步 • 数据容量不大 • 数据变化不频繁

二级Cache • iCache • 用来缓存那些容量较少的分发索引数据 • 容量小，易压缩 • 可以完全存储于Cache中 • 读写频率非常高 • 不需要淘汰 • 可靠性要求高，双机互备。 • eCache • 用来存储Feed对象及其他对象数据 • 读的频率高 • 占用的容量大 • 在保证命中率的前提下进行淘汰及容量规划 • 可靠性要求低

iCache设计

iCache设计 • 元数据 • 活动索引 • 可重用索引 • 具有一定的容量（200） • 解决Cache容量问题

Feed权重 • 问题 • Feed多样性 • 信息过载 • 显示不友好 • 解决 • 权重机制 • 尽量显示重要信息

Feed特性 • 多样性 • 时效性 • 交互性

权重设计 • 内容权重 • 类型 • 交互 • 时间权重 • 随时间下降 • 随时间淘汰 • 分区设计 • 分区具有不同的内容和时间的权重比例 • 具有容量控制

Feed权重过程

存储设计 • Cassandra • MySql

Cassandra • 2台测试服务器 2客户端 • 16* E5520 @ 2.27GHz • 6磁盘 raid10 766G • 24GB内存 • 备份数2 • 写ConsistencyLevel为QUOUM(2) • 读ConsistencyLevel为ONE

Cassandra 读性能写性能

Cassandra特点 • 线性扩展 • 具有较好的备份机制 • 写性能非常好 • 读性能较差 • 相对来说不是特别成熟

Feed分发IO • 分发处理写索引10000/s • 查询读索引20000/s 活动索引读=20000*97%=19400/s （100%Cache命中）可重用索引读=20000*3%=600/s (32%Cache命中) 存储读=600*(1-32%)=408/s • Feed IO对存储写多读少 • 分发索引比较适合Cassandra特点

MySql存储 • 存储方案成熟 • 读写性能比较平衡，都在较好的水平 • 扩展相对比较困难 • 容量估算要求比较高 • 用来存储Feed消息对象及其他相关数据 • 基于ID进行Hash拆分

后续目标 • 基础平台 • 服务化 • 通用化 • 信息流通 • 平台化 • 互动化

Q&A

SNS 底层架构及动态体系