Build High Performance Weibo Platform

@TimYang

Background

• Weibo introduction

• 140 Chinese characters

• With photo/video/comments/repost chain

Agenda

�����

�

�

��

�

12

3 4

Part 1

海量存储

每天近亿条新记录，大部分记录变更需要即时反映到业务系统(一致性)，如何解决？

MySQL

• 适合海量存储，可任意拆分扩展• 可靠

MySQL 拆分策略

• 仅按 id hash的问题

• 多索引，如关系• 二级索引，如 user_timeline index

MySQL 问题

• 单机容量限制、需要持续拆分• 访问速度需求• 用户• 关系，每秒 5 万次

MySQL + cache 问题

• 雪崩• 一致性• 数据类型不够，需要序列化

NoSQL?

• 单机思路• Redis

• MongoDB

• 分布式思路• Cassandra

• HBase

用好一款开源产品的前提条件是深入了解它的定位。

如何定位

• MongoDB

• Redis

• HBase

• Cassandra

Redis

• snapshot/vm/cache disk/aof

• string/hash/list

• Replication

定位

• 需要高速读写访问• 无高准确性需求• 能容忍短期不可用• 有list/set数据结构需求(optional)

Data Structure

• 计算和存储都依赖数据结构• RDBMS => JSON key value => binary

数据结构

• DB

• JSON/XML

• Binary

JSON 烦恼

• DB

• Cache

• Message Queue

• API

Binary Data Structure

• Numeric: varint, from 1 byte

• 字段名称并不传输，而是传输编号• 多语言：Java, C++, Python...

• 编解码高效

Data Structure

小即是美

Case Study

• 500万粉丝如何在内存中有效存储

• 变长• 动态变化

海量存储

• MySQL，可靠的落地存储

• NoSQL，必要的补充

• 海量存储，小即是美

Part 2

实时计算

一位明星用户可能有上百万粉丝，数据如何实时投递到所有用户?

实时性

• 异步处理• RAM化

一致性

• Timeline, 计数器，关系不是同一服务

• e.g. “有5条新评论”，但 comments_timeline 为空

时序问题

One Data Center

Region 1

Region 2

1001 1002 1003 1004 1005

1002 1001 1004 1003 1005

1001 1003 1002 1004 1005

Part 3

平台接口

游戏规则已经发生了变化，产品的竞争转变为平台和app生态圈之间的竞争

接口设计要素

• 安全• 隐私保护• spam

• 易用• 性能

性能

Part 4

服务治理

框架

• 规范及统一行为

性能

诊断

运维

• 容错• 灾难

小结

�����

("

��

��

��

'� �� )��& *%

����MySQL

Redis

Memcached

Timeline

(�

�#

���

� !

�+��

��$� ��

Q&A

@TimYang

http://timyang.net/