Twitter的Timeline是怎样服务数亿用户的？

Twitter的Timeline服务通过写扩散（Fanout）机制、分层存储架构、混合拉取与推送模式，结合对读写路径的针对性优化，实现了对数亿用户的高效服务。以下是具体技术实现方案：

Twitter采用写时扩散策略处理推文分发，核心逻辑如下：

• 推文写入阶段：

  用户发布推文后，系统首先将推文存储在Redis集群中（每条推文在3台机器上备份），确保数据高可用性。

  通过查询社交关系数据库（Flock）获取该用户的粉丝列表，将推文ID、发送方ID及标志位写入所有粉丝的时间线中。例如，拥有2万粉丝的用户发布推文时，系统需执行2万次插入操作。

• 时间线存储：

  每个用户的主页时间线以Redis List形式存储，最多容纳800条推文。活跃用户（30天内登录过）的时间线完全驻留内存，非活跃用户的时间线在首次访问时重建。

  推文内容本身存储在MySQL中，时间线仅保存ID，读操作时通过multiget命令批量获取内容，减少内存占用。

优势：读操作复杂度为O(1)，仅需从Redis集群定位用户时间线即可快速返回，支撑30万QPS的读请求。代价：写操作复杂度为O(N)，粉丝量大的用户（如名人）发布推文时，需执行千万级插入操作，可能导致延迟。

为平衡性能与成本，Twitter采用多级存储策略：

• 内存层：

  活跃用户的时间线完全驻留Redis内存集群，确保低延迟访问（响应时间仅几十毫秒）。

  推文索引（如搜索功能）存储在内存中的EarlyBird（定制版Lucene），加速搜索响应。

• 磁盘层：

  非活跃用户的时间线在首次访问时重建，从MySQL中查询关注列表并合并推文，重建后的时间线写入Redis缓存。

  推文内容长期存储在MySQL中，通过分库分表和读写分离应对海量数据。

• 缓存策略：

  Redis集群作为一级缓存，存储时间线ID列表；T-bird服务作为二级缓存，存储推文内容。

  对热门推文实施预热缓存，避免冷启动延迟。

Twitter结合两种模式优化用户体验：

• 拉取模式：

  主页时间线：用户主动刷新时，系统从Redis集群拉取时间线ID列表，再通过multiget获取推文内容，最后过滤违规内容（如法国过滤纳粹相关内容）。

  搜索功能：推文写入时由Ingester进行词法分析并索引至EarlyBird，读请求由Blender合并所有分片结果后返回，复杂度为O(N)，但因索引在内存中，响应时间仍控制在几百毫秒。

• 推送模式：

  针对移动端和实时性要求高的场景，Twitter运行全球最大的实时事件推送系统（速率达22MB/s）。

  客户端通过Socket连接推送服务，系统在150ms内完成推文推送，支持100万个并发连接（如TwitterDeck应用）。

为解决名人推文扩散延迟问题，Twitter实施读写路径平衡策略：

• 写时优化：对粉丝量超过阈值（如5000）的用户，系统默认延迟其推文的写扩散，仅将推文存储在用户个人时间线中。
• 读时合并：当粉丝访问时间线时，系统动态查询关注列表，合并个人时间线与关注对象的推文，构建完整视图。
• 效果：显著降低写操作负载，但可能增加读延迟（需额外查询社交关系）。Twitter通过预加载关注列表和并行查询优化这一过程。

• 高并发读请求：

  通过Redis集群水平扩展支撑30万QPS的读请求，集群规模随用户增长动态调整。

  对热点数据实施多副本存储，避免单点瓶颈。

• 写操作延迟：

  对名人推文采用异步批处理，将大量插入操作拆分为多个小批次执行。

  优化Flock数据库查询性能，使用缓存减少社交关系查询次数。

• 数据一致性：

  接受“最终一致性”模型，允许时间线在推文发布后短暂延迟显示（通常在5秒内）。

  通过版本号和冲突检测机制处理并发写操作。

• 用户规模：数亿活跃用户，3100万粉丝的用户（如Lady Gaga）发布推文后，系统需在5分钟内完成全量推送。
• 请求量：时间线读请求达30万QPS，写请求约6000QPS（写扩散优化后降至4000QPS）。
• 存储规模：每天处理4亿条推文，Redis集群存储数十亿条时间线记录，MySQL存储数百PB推文数据。

Twitter的Timeline服务通过写扩散降低读延迟、分层存储平衡性能与成本、混合推送提升实时性，结合对大V用户的特殊优化，成功支撑了数亿用户的高并发访问。其核心思想是以读优化为导向设计系统架构，通过空间换时间（冗余存储）和计算下推（写时预处理）实现规模化扩展。