![image](https://developer.qcloudimg.com/http-save/yehe-10178976/d1b65a2ddd338b82a0ba5f2cb1bbef4e.jpg)

## 写在前面

上一篇聊了Feed流的基本概念和分类，从这一篇开始我们进入正题——架构设计。

Feed流系统架构中最核心的决策是什么？不是选什么数据库，不是用什么缓存，而是数据分发策略的选择。简单来说就是：用户A发了条消息，怎么让他的粉丝看到？是主动推过去，还是等粉丝自己来拉，还是两者结合？

这个决策几乎影响了系统设计的方方面面——存储结构、分页方式、性能瓶颈、扩展性，全都跟它挂钩。所以这一篇我们重点把这个事情讲透。

## 1. Feed流系统面临的挑战

在讨论具体方案之前，先明确一下Feed流系统到底要解决哪些问题。只有理解了挑战，才能评估各种方案的优劣。

**实时性要求高。** Feed是实时消息，从产生到消费到推送，整个链路要尽可能快。用户发了条动态，粉丝刷新页面应该立刻能看到。这个"实时"不一定要求毫秒级，但秒级或者秒级以内是基本要求。

**数据量巨大。** 消息来源多样且数量庞大。一个大V发一条微博，可能要分发给上千万粉丝。每天产生的消息总量可能是亿级别的。这对存储系统提出了很高的要求。

**读写严重失衡。** 前面提到过，Feed流是典型的读多写少场景，读写比通常在10:1以上。这意味着系统在架构上要明显偏向读优化。

**数据一致性不能丢。** 消息发布出去后，必须保证所有关注者都能感知到。可以接受短暂延迟（最终一致性），但不能出现消息丢失。想象一下你发了条朋友圈，结果一半朋友看到了一半没看到，这在产品上是不可接受的。

这四个挑战是所有Feed流系统都要面对的，不同的分发策略就是在这些挑战之间做取舍。

## 2. 三种数据分发策略

### 2.1 读扩散（拉模式）

读扩散的思路很简单：用户查看Feed流的时候，系统实时去拉取他关注的所有人的最新消息，然后合并排序返回。

具体流程是这样的：

```
用户请求Feed流
  -> 获取用户的关注列表
  -> 遍历关注列表，从每个人的发件箱中拉取最新消息
  -> 合并所有消息，按时间排序
  -> 返回给用户
```

这种方式的好处是写入成本极低。用户发消息的时候，只需要写入自己的发件箱就行了，不需要管粉丝的事。不管你有100个粉丝还是1亿个粉丝，写入的开销都是一样的。

但问题也很明显——读取成本太高了。假设一个用户关注了200个人，那他每次刷新Feed流都要去拉取200个发件箱的数据，然后合并排序。如果这200个人里有些是大V，发件箱数据量很大，那这个读取延迟会非常感人。

而且还有一个分页的问题。用户往下翻页的时候，需要记住每个关注人拉到了哪个位置（write_last_id），翻页逻辑会变得非常复杂。这个后面讲分页的时候再详细展开。

读扩散适合什么场景？粉丝数量特别多的大V用户。因为大V的粉丝太多了，写扩散的成本太高，不如让粉丝自己来拉。

### 2.2 写扩散（推模式）

写扩散是读扩散的反面：用户发消息的时候，系统主动把消息推送到所有粉丝的收件箱中。粉丝查看Feed流的时候，直接从自己的收件箱读取就行了。

```
用户发布消息
  -> 消息写入发件箱
  -> 获取粉丝列表
  -> 将消息ID写入每个粉丝的收件箱
  -> 完成

用户请求Feed流
  -> 直接从自己的收件箱读取
  -> 返回
```

写扩散最大的优势就是读取性能极好。粉丝打开Feed流的时候，数据已经准备好了，直接从收件箱里取就行，不需要任何实时计算。分页也简单，收件箱里的数据本身就是排好序的。

但缺点也来了——写入压力大。一个普通用户有几百个粉丝还好，但如果是一个有5000万粉丝的大V呢？他每发一条消息，就要往5000万个收件箱里写数据。这个写入量是非常恐怖的。

写扩散适合什么场景？普通用户。大部分用户的粉丝数量在几百到几千之间，写扩散的开销完全可以接受，而且读取体验最好。

### 2.3 读写结合（推拉结合）

既然读扩散和写扩散各有优劣，那能不能结合起来用？

答案是当然可以，而且这也是业界最常用的方案。思路很简单：普通用户用写扩散，大V用户用读写结合。

具体来说，当大V发布消息的时候：
- 热粉丝（活跃用户）：写扩散，消息主动推送到他们的收件箱
- 冷粉丝（不活跃用户）：不推送，等他们上线查看Feed流的时候再通过读扩散去拉取

这样既保证了大V的热粉丝能实时看到新内容，又避免了向海量冷粉丝写扩散带来的性能压力。

判断一个用户是"热粉丝"还是"冷粉丝"，常见的做法有几种：
- 根据登录频率，比如最近7天登录过就算热粉丝
- 根据在线状态，当前在线的用户算热粉丝
- 根据互动行为，最近有过点赞、评论等行为的算热粉丝

```java
// 消息发布时的分发逻辑
public void publishMessage(User publisher, Message message) {
    // 1. 保存消息到发件箱
    messageRepository.saveToOutbox(publisher.getId(), message);

    // 2. 判断是否为大V用户
    if (isInfluencer(publisher)) {
        // 大V：只向活跃粉丝写扩散
        List<User> activeFollowers = followerService.getActiveFollowers(publisher.getId());
        for (User follower : activeFollowers) {
            inboxService.addMessage(follower.getId(), message.getId(), publisher.getId());
        }
    } else {
        // 普通用户：向所有粉丝写扩散
        List<User> allFollowers = followerService.getAllFollowers(publisher.getId());
        for (User follower : allFollowers) {
            inboxService.addMessage(follower.getId(), message.getId(), publisher.getId());
        }
    }
}
```

那"大V"的判断标准是什么？这个没有绝对的标准，要根据业务场景来定。一般来说，粉丝数量超过某个阈值（比如10万）就可以算大V了。也可以结合认证状态、内容质量等维度综合判断。

```java
public boolean isInfluencer(User user) {
    // 基于粉丝数量判断，阈值可以根据业务调整
    return user.getFollowersCount() > INFLUENCER_THRESHOLD;
}
```

## 3. 三种方案的对比

把三种方案放在一起对比一下：

| 维度 | 读扩散 | 写扩散 | 读写结合 |
|---|---|---|---|
| 写入成本 | 低 | 高（大V场景极高） | 中等 |
| 读取成本 | 高 | 低 | 低（热粉丝）/ 高（冷粉丝） |
| 读取延迟 | 高（实时计算） | 低（数据已就绪） | 中等 |
| 分页复杂度 | 高 | 低 | 中等 |
| 适用场景 | 大V用户 | 普通用户 | 大V + 普通用户混合 |

由于Feed流是读多写少的场景，大部分情况下写扩散是更好的选择。因为读操作远多于写操作，优化读性能带来的收益更大。只有当出现粉丝量级特别大的大V用户时，才需要引入读写结合来平衡写入压力。

## 4. 整体架构概览

确定了分发策略之后，我们可以看一下整体架构。下面这张图描述了一个典型的Feed流系统的核心组件和数据流向：

![Feed流系统架构](https://developer.qcloudimg.com/http-save/yehe-10178976/51de0479f0b3c409f0b817bc7d1611a6.png)

整个系统主要由以下几个核心组件构成：

**消息发布服务。** 处理用户发布的消息，将消息持久化到数据库，然后根据发布者的类型（普通用户/大V）选择合适的分发策略，将消息同步到粉丝的收件箱中。

**消息存储服务。** 管理消息内容和用户关系数据。消息内容存储在数据库中（发件箱），用户关系数据也需要持久化存储。

**Feed流查询服务。** 提供Feed流的查询接口。对于活跃用户，直接从收件箱读取；对于非活跃用户，还需要额外从关注的大V发件箱中拉取数据。

**缓存层。** 主要用Redis来实现。用户的收件箱用Redis的Sorted Set存储，提供高效的时间排序和分页能力。用户关系、活跃用户列表等热点数据也会缓存在Redis中。

**消息队列。** 用于解耦消息的发布和处理流程。用户发布的消息先进入消息队列，然后由后台消费者异步处理分发逻辑。这样做的好处是：一是提升系统的响应速度，用户不需要等待分发完成就能得到响应；二是削峰填谷，应对突发流量；三是失败可以重试，提高可靠性。

这些组件协同工作，构成了一个完整的Feed流系统。后面的文章会逐一深入每个组件的设计细节。

## 一个容易忽略的问题：消息修改和删除

在讨论分发策略的时候，大家往往只关注"发布"这个场景，但很容易忽略"修改"和"删除"。

写扩散模式下，消息发布出去后，每个粉丝的收件箱里都有这条消息的引用。如果发布者修改或删除了这条消息，怎么办？

最直观的做法是：修改或删除的时候，也做一次扩散，把变更同步到所有粉丝的收件箱。但这样做有两个问题：
- 和发布一样，大V场景下扩散成本太高
- 用户在修改/删除的扩散完成之前，看到的还是旧数据，存在时效性问题

更好的做法是：**不扩散修改和删除，而是通过读取时的回查来实现**。

具体来说，收件箱里存的不是完整的消息内容，而是消息ID。用户读取Feed流的时候，先拿到消息ID列表，然后回查数据库获取最新的消息内容。如果消息被修改了，回查时自然拿到的是最新版本；如果消息被删除了，回查时标记为已删除状态，过滤掉就行。

这种方式的好处是：修改和删除完全不需要扩散，零成本。代价是每次读取都要多一次回查操作，但这个开销是完全可以接受的。

这就是所谓的"软删除 + 懒删除"机制，下一篇讲数据模型的时候会详细展开。

## 6. 小结

这一篇重点聊了Feed流系统的三种数据分发策略。读扩散写入成本低但读取成本高，写扩散读取成本低但写入成本高，读写结合则是在两者之间取一个平衡。

对于大多数Feed流系统来说，推荐的方案是：以写扩散为主，对大V用户引入读写结合。这样既能保证大部分用户的读取体验，又能应对大V场景下的写入压力。

还有一个关键的设计原则：收件箱只存消息ID，不存完整内容。这样修改和删除就不需要扩散，通过读取时回查就能搞定。

下一篇我们会聊数据模型和存储设计——消息表怎么建、关注关系表怎么设计、收件箱用Redis怎么存。这些是整个系统的地基，地基打好了，后面的实现才会稳。

Feed流系统架构中最核心的决策是什么？不是选什么数据库，不是用什么缓存，而是数据分发策略的选择。简单来说就是：用户A发了条消息，怎么让他的粉丝看到？是主动推过去，还是等粉丝自己来拉，还是两者结合？

Feed流系统设计（二）：推还是拉？三种数据分发策略的取舍

软件开发工程师

架构设计

后端

网络与通信

本文深入解析Feed流系统架构设计的核心问题——数据分发策略，对比读扩散、写扩散和读写结合三种模式的优缺点。重点分析如何平衡实时性、数据量和读写性能，提出针对普通用户和大V的混合分发方案，并探讨消息修改删除的优化处理。为构建高性能Feed流系统提供关键设计思路。

数据一致性

消息队列

数据库

数据流

Redis

腾讯云大数据特惠新用户0.1折起


oceanus

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Feed流系统设计（二）：推还是拉？三种数据分发策略的取舍-腾讯云开发者社区-腾讯云

Feed流系统设计（二）：推还是拉？三种数据分发策略的取舍

Feed流系统设计（二）：推还是拉？三种数据分发策略的取舍

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐