新浪微博技术架构分析

新浪微博在短短一年时间内从零发展到五千万用户，我们的基础架构也经历了几个版本的演进。本文将从架构演进的角度，分析微博在不同发展阶段面临的技术挑战与解决方案。

第一版架构：快速实现与推模式

第一版架构的核心目标是快速实现模块功能。从架构层面分析，微博产品主要需要解决「发表」和「订阅」的问题。

  • 消息模式：第一版采用的是推（Push）模式。例如，一个明星用户拥有 10 万个粉丝，当他发表一条微博时，系统会将这条消息攒成 10 万份，分别推送给粉丝。
  • 技术栈：典型的 LAMP 架构。
  • 存储引擎：使用 MyISAM 存储引擎，其优点是读取速度非常快。
  • 部署模式：采用 MPSS 模式（多端口/进程部署）。

关于部署模式的思考：
假设一个互联网应用包含三个单元，通常有两种部署方式：

  1. 分离部署：将三个单元分别部署在三台不同的服务器上。
  2. 全量部署（MPSS）：将这三个单元部署在每一台服务器上。

我们选择了第二种模式，主要解决了两个问题：

  • 负载均衡：每一个单元都有多个结点处理请求。
  • 防止单点故障：在模式一下，任何一个结点故障都会影响系统服务；而在模式二下，单个结点故障不会影响整体服务。

第一版遇到的问题

第一版上线后，用户增长迅速，但技术层面很快遇到了瓶颈：

  1. 发表延迟：尤其是明星用户发表微博时，由于粉丝量大，推模式导致严重的延迟。
  2. 资源争抢：处理明星用户发表时的延迟，可能会影响同一时间发表普通用户的体验。
  3. 数据规模：数据库表从一百万增长到一亿，单库单表模式无法满足需求，需要进行拆分。
  4. 锁表问题：高并发下出现锁表，考虑更改存储引擎。
  5. 发表过慢：同步处理流程过长，考虑引入异步模式。

第二版架构：模块化与异步优化

针对上述问题，第二版架构进行了模块化拆分与异步化改造。

1. 投递模式优化

推模式是延迟的首要原因。我们将用户分为有效用户和无效用户：

  • 策略：如果一个用户有 100 个粉丝，发微博时不需要推给所有粉丝。例如，只推送给当天登录过的「有效粉丝」。
  • 效果：大幅减轻了推送压力，减小了投递延迟。

2. 数据拆分与存储

随着用户量增多，数据拆分势在必行。

  • 拆分维度：互联网产品常用 UID 拆分，但微博用户访问特点集中在「最近内容」。因此，我们按照时间拆分（例如一个月一张表）。

  • 内容与索引分离：

    • 索引数据：如微博发表地址。
    • 内容数据：采用 Key-Value 方式存储，易于扩展。

  • 分页定位问题：如果索引按月拆分，用户访问第 5 页时很难定位记录所在表。

    • 解决方案：在索引上建立二次索引。记录每个月用户发表的偏移量（ID 范围），从而迅速定位记录。

3. 异步处理

发表操作涉及入库、统计索引、进入后台等繁重步骤。

  • 优化：采用异步模式。前端提示发表成功后，后台通过消息队列慢慢处理索引统计。
  • 工具：使用了新浪开源的 MemcacheQ，其 stats queue 指令对大规模部署运维非常有利。

架构演进驱动力：从 V2 到 V3

第二版改进后，用户和访问量仍在持续增长，新的问题随之出现：

  • 系统稳定性：单点故障可能导致雪崩。
  • 访问速度：国内网络环境复杂，不同地区访问图片、JS 等资源速度差异大。
  • 数据压力与峰值：MySQL 复制延迟、慢查询；热门事件（如世界杯）可能导致每秒发表量达到数百条。
  • 平台化需求：开放平台需要支持 Web 系统与 API 系统。API 客户端请求具有不间断性，且用户行为难以预测。

参考 Google 首席科学家的理念：「一个大的复杂系统，应该要分解成很多小的服务。」 例如在 Google.com 执行一个搜索查询，内部可能调动一百多个服务。因此，第三版架构的核心思路是：先有服务，才有接口，最后才有应用。

第三版架构：服务化与多机房部署

1. 分层架构

  • 基础服务层：分布式存储、去中心化、自动化操作。
  • 平台服务层：将微博常用功能封装成独立小服务。
  • 应用服务层：专门考虑平台各种应用的需求。
  • API 层：支撑第三方应用。

优势：平台服务与应用服务分离，实现模块隔离。即使应用服务访问量过大，也不会直接影响平台服务。

2. 核心引擎改进

  • 关注关系：改为多维度索引结构，性能极大提高。

  • 计数器优化：

    • 旧版：绝对计数，容易产生一致性问题。
    • 新版：基于偏移（Offset） 思路。例如用户原读 ID 为 10000，系统最新 ID 为 10002，则未读数为 2。这种技术基本不会出错。

3. 存储与部署

  • DB 冷热分离与多维度拆分：微博主业务按时间拆分，但如私信等业务按 UID 拆分更简单。
  • 去中心化存储：极大提高用户上传与查看图片的速度。
  • 多 IDC 动态内容更新：支持动态内容在多机房同时更新，这是国内比较新颖的实践。

高性能与高可用设计

目前新浪微博拥有五千万用户，最高发表速率超过 3000 条/秒，明星用户微博会被几百万用户同时读取。架构设计需解决高访问量、海量数据下的三个核心问题：易于扩展、低延迟、高可用与异地分布。

1. 扩展性设计

面对数十亿次外部网页及 API 接口需求，且微博用户请求无法 Cache 的特点，我们采取以下思路：

  • 模块去状态：任意单元支持任意节点。
  • 去中心化：避免单点及瓶颈。
  • 线性扩展：减少模块依赖。

2. 低延迟与实时性

实时性是微博的核心价值，核心原则是让数据离 CPU 最近，避免磁盘 IO。

淘宝核心系统专家余锋曾比喻："CPU 访问 L1 就像从书桌拿一本书，L2 是从书架拿一本书，L3 是从客厅桌子上拿一本书，访问主存就像骑车去社区图书馆拿一本书。”

Cache 设计策略：

  • Inbox：放在最快的地方，用户随时访问。

  • Outbox：

    • L1 Cache：存放最近发表的内容。
    • L2 Cache：存放中期内容，访问较少时可被剔除。
  • 内容体本地化（L0）：将明星发表等高概率访问的内容本地化。

3. 高可用性（HA）

业界指标参考：S3 为 99.9%，EC2 为 99.5%。微博平台目前承诺 99.95%（即一年故障时间小于 4.5 小时）。

  • 容量规划：提前进行规划。
  • 监控与入口管理：设置开关，在访问量过大时拦截服务。
  • 量化监控：监控指标尽量量化。例如延迟 30 秒是小问题，延迟 10 分钟则需立即采取措施。

  • 自动化运维：

    亚马逊 VP 曾指出：“监控系统确实特别好，可以立即告诉我们哪里有故障，但是有 20% 的概率人是会出错的。”

    大型系统应为自动化设计（发布、安装、启停）。参考 Google 工程师的做法：第一周处理线上业务与系统问题，随后将碰到的情况用程序解决，下次只需一个按钮即可处理。

多机房同步方案

在国内网络环境下，需考虑 IDC 灾难、机房检修或掉电等情况，每个服务单元需支持多机房部署。多机房部署不仅能容灾，还能提高用户访问速度。

1. 复制策略对比

  • Master/Slave：

    • 缺点：Master 中心化，异地访问慢；存在单点风险，切换需要人工干预且有时间窗口。

  • Multi-Master：

    • 特点：应用需避免冲突。微博用户通常只在一个地点发表内容，应用层可避免冲突。
    • 现状：最成熟的策略，但当时缺乏成熟产品。

  • Paxos：

    • 特点：强一致写，但延迟非常大。

2. 微博的解决方案

我们自行实现了多机房同步方案：

  • 流程：前端应用写入数据库 -> 消息代理（Message Agent）-> 广播到多个机房。

  • 优势：

    • 数据提交成功后即不丢失，应用无需关心同步细节。
    • 类似 Yahoo 的 YMB 消息代理产品，专为广域网设计，将多机房应用归到内部。

实时推送架构

针对 API 请求大部分为空返回（客户端轮询）的问题，我们改用推（Push）模式。

  • 技术特点：低延迟（发表到接收 1 秒内完成）、高并发长连接服务。

  • 架构流程：

    1. Receiver：接收数据。
    2. 引擎：获取用户关系，推送给相应粉丝。
    3. 唤醒操作：在接口处唤醒等待的客户端。
    4. 长连服务器：单台支持 10 万 + 并发连接。
    5. Stream Buffer：保存用户最近数据，用于断线重连后的数据补发（如断线半分钟，补发半分钟数据）。
  • 持久化：推送流程经过测试，持久化操作可在 100-200 毫秒内完成，确保数据不丢失且系统稳定。

平台安全架构

由于接口完全开放，需防范垃圾广告、刷粉丝等恶意行为。安全架构分为三个层面：

  1. 实时处理：根据频度、内容相似性判断是否为广告或垃圾内容。
  2. 离线纠正：针对潜伏行为（如几个月后开始发广告），事后清除以保证平台健康。

  3. 监控维度：保证内容安全。

    • 实时拦截可防止约 50% 的恶意行为。
    • 离线分析可防止约 40% 的恶意行为。

此外，接口安全还包含业务模块划分、安全层与权限层，为开发者营造公平环境。

总结

架构演进的本质是解决不同阶段的核心问题：

  • 第一版：解决发布规模问题。
  • 第二版：解决数据规模问题。
  • 第三版：解决服务化问题。

将复杂问题简单化，才能设计出易于扩展的大规模架构。

附录：用户规模对架构设计的影响

用户规模每上一个数量级，许多设计需要重新考虑。以下数字仅供理解「用户规模影响设计」，本身并无具体指导价值。

用户规模架构特征与建议
10 万级单服务器，前端、后端、Cache、DB 在一起。
百万级DB 和 Cache 单独部署服务器；DB 可按业务拆分（Sharding）；Cache 使用一致性 Hash 扩展；前端后端根据业务拆分，分配不同数量服务器。
千万级开始重视架构设计，配备专门技术架构师；需跨机房部署，前端增加反向代理加速，数据库异地使用 Slave 副本；后端拆分，系统内部需远程调用协议。
亿级架构更细分（增加数据架构师、Cache 架构师、分布式架构师）；DB Sharding 碰到瓶颈，考虑分布式数据服务；数据访问根据业务特点细分；具备专有开发、运维、测量、调优工具；所有服务地理多机房分布，具备 IDC 容灾设计；服务可降级。
说明：本文内容基于新浪微博早期发展阶段的架构分享整理（用户规模约五千万时期），部分技术选型（如 MyISAM、MemcacheQ 等）具有特定的历史背景，仅供参考学习架构演进思路。