怀古游戏宅SIR1. 关注推送到底在解决什么问题：从“新内容产生”到“被用户看见”
我最早接触关注推送这个需求，是在做一个社区类App的时候。当时产品经理提了个需求，说得很简单：“用户关注了某个作者，这个作者发新内容了，用户的关注流里要能刷到。”听起来不就是“查一下这个作者发了什么，扔到粉丝的时间线里”吗？等真正动手做的时候才发现，这里面的门道远比想象中多。
先把问题的边界理清楚。关注推送本质上要解决的是一个“确定性分发”的问题：系统里面每时每刻都会产生大量的新内容，而每个用户只关心他主动关注的那些账号发布的内容。所以我们需要一条链路，把“作者发布内容”这一事件，准确地传递到“所有关注了这个作者的用户”的Feed流里。
这和“全站推荐流”有本质区别。推荐流的核心是不确定性——系统猜你可能喜欢什么，猜错了无所谓，顶多损失一次曝光。而关注流的核心是确定性——用户明确表达了他想看谁的内容，漏掉一条、推错一条，都是产品的信任危机。用户关注了某个作者，结果刷半天没看到新内容，第一反应不是“算法不行”，而是“这平台是不是把我的关注弄丢了”。
从应用场景来看，关注推送几乎覆盖了所有社交和内容产品：微博的关注页、Instagram的Following页、即刻的动态、知识星球的主题流、GitHub的Follower动态、甚至企业内部通知系统里的“我订阅的项目更新”。凡是存在“关注关系”和“内容更新”两个要素的系统，本质上都需要这样一条链路。如果你正在做的产品需要“用户能刷到自己关注的人的新动态”这个功能，那这篇内容就是写给你的。
我写的这套实现思路，不是套某个大厂的完整架构，而是我在百万级用户量级产品上踩过坑之后沉淀下来的实践经验。核心思路和大部分主流社交产品的早期方案一致：关注关系用关系型数据存储，Feed流用Cache加速读取，推送模式采用推拉结合。下面按模块逐个拆开讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 关注关系建模：一切推送的起点
关注推送的第一步，不是设计推送链路，而是把“关注关系”这个最基础的数据模型建好。这个环节看起来简单，但后续所有的推送逻辑、查询逻辑、计数逻辑都建立在这张表之上，一旦设计失误，后面改造的成本极高。
2.1 最基础的表结构怎么设计
最朴素的做法就是一张两列表：follower_id（关注者）和 followee_id（被关注者），再加一个创建时间。这样一条记录就表示“用户A关注了用户B”。我见过很多项目初期都是这么做的，也确实能跑。但当数据量上来之后，你会发现几个核心查询会变得很吃力：
- 查询“我关注了谁”：
SELECT followee_id FROM follow WHERE follower_id = ? - 查询“谁关注了我”：
SELECT follower_id FROM follow WHERE followee_id = ? - 查询“我是否关注了TA”：
SELECT id FROM follow WHERE follower_id = ? AND followee_id = ? - 查询“我关注的人里面，有哪些人发了新内容”：这个会稍微复杂，后面细说。
这四类查询覆盖了关注推送的全部前置条件。第一类决定了“我要拉取哪些人的内容”，第二类决定了“作者发内容时要推送给谁”，第三类是产品侧的交互校验（关注按钮的状态），第四类是后台做数据对账时用的。
在百万级用户量级，单表加索引其实就能扛住这四类查询。我的经验是：联合唯一索引（follower_id, followee_id）必须加，因为关注关系天然不允许重复；followee_id 单列索引也要加，因为反向查询同样高频。
2.2 关注/取关的实时性和一致性问题
有一个容易被忽略的细节：用户关注某个作者之后，应当“多久能看到这个作者的新内容”？这里有两个选择。
第一种，用户关注后，立即把该作者最近N条内容写到用户的时间线Cache里。好处是用户马上就能刷到历史内容，体验好；坏处是如果这个作者粉丝量很大，每次有人关注他都要做一次大的数据搬运，压力不小。
第二种，用户关注后，不主动填充历史内容，而是等用户刷新时间线时，把“我关注的作者”和“作者的最新内容”做一个实时合并查询。好处是逻辑简单、不用维护大量的历史缓存，坏处是如果用户关注了几百个账号，这几次查询拼接出的结果集会很大，响应时间会变长。
我做的时候用的是折中方案：普通用户关注时触发实时填充，但填充的上限是该作者最近50条内容；对于粉丝量超过10万的头部作者，则不触发填充，只在用户刷新时通过拉取模式补一次。这个阈值不是拍脑袋定的，是通过压测观察到的：当实时填充的写放大倍数超过某个量级时，缓存服务的CPU和内存都会出现明显尖峰。
2.3 分组关注：一个被经常忽略的扩展需求
如果你只做“关注”和“取消关注”两个操作，上面的表结构已经够了。但几乎所有产品后期都会被要求加“分组”功能——用户想把关注的人分成“朋友”“同事”“科技博主”等不同的列表，然后按分组刷Feed。
分组功能如果一开始不做预留，后面改造很痛苦。我的建议是在设计关注表时就加上group_id字段，允许为空，为空表示“不分组的默认关注”。当用户不给关注的人分组时，字段留空；一旦分组，就把对应的分组ID填进去。这样后续查询“某个分组下的内容”时，只需在Feed流查询条件中追加group_id = ?的过滤，不需要动底层的关注关系表结构。
3. 推送时机与事件链路：谁说有新内容，就必须被看见
关注关系建好之后，就要解决核心问题：作者发布了一条新内容，系统如何知道该通知谁？这就是“推送时机”和“事件链路”的范畴。很多新手在这里会犯一个直觉性的错误——以为关注推送是“写一段定时任务，每隔几分钟扫描一次所有作者有没有发新内容”。这种做法在用户量小的时候勉强能用，用户量一旦上来，全表扫描的代价会爆炸式增长。
3.1 事件驱动：让系统“主动”感知内容发布
正确的方式是事件驱动。内容服务在成功写入“内容表”之后，立刻往消息队列里发一条事件，消息内容至少包含：内容ID、作者ID、发布时间。这个事件就是整条推送链路的起点。
然后有一个消费者（Worker）专门监听这个事件。当它收到事件后，做的事情是：
- 根据作者ID，查出这个作者的粉丝ID列表。
- 根据粉丝ID列表，逐个把“内容ID + 作者ID + 发布时间”写入对应粉丝的Feed流存储里。
- 统计该事件处理结果，更新监控指标。
这里最核心的步骤是“查到粉丝列表”，也就是前面说的反向查询。如果作者只有几百个粉丝，这一步非常轻松，几千条记录而已。但如果作者是几十万粉丝的大V，查出来的粉丝列表可能有几十万条记录，逐条写入Feed流存储就是一个巨大的写入放大。
3.2 消息队列选型与可靠性
消息队列在这里承担的是一个“削峰填谷”和“失败重试”的作用。如果你所在的团队已经有Kafka或RocketMQ，直接用就好，不需要另起炉灶；如果没有，RabbitMQ也能胜任，但要做好消费端的高可用设计。
这里有一个关键点：事件通知不能丢，但可以延后。具体来说，内容发布是核心业务，推送是附属业务。如果推送链路挂了，不能让内容发布也跟着失败。所以事件的生产端要保证“先入库、再发消息”，且消息发送失败时要有本地补偿机制。
我踩过一个真实的坑：有一次消息队列的消费端因为代码Bug挂掉了，导致用户发布了内容但没有任何人能在关注流里看到。等我们发现问题时，已经过去了近一个小时。重启消费端后，积压的消息洪水般涌入，数据库连接被打满，出现了连锁反应。后来做了两个改进才彻底解决：一是消费端做了批量处理，每次从队列里拉取500条消息合并写入，减少数据库连接开销；二是增加了“积压数量”监控告警，超过阈值立刻电话通知值班人员。
3.3 推送的内容是“通知”还是“内容本身”
关于推送进Feed流的内容，业界有两种做法：
一是推送完整的内容ID列表。Feed流的存储里只存内容ID和发布时间，真正的内容展示时再来查内容服务。好处是内容更新（比如编辑了标题）后，Feed流里的显示会自动同步；坏处是每次刷Feed都要做一次内容查询，如果内容服务扛压能力不够，容易成为瓶颈。
二是推送内容快照。就是在推送时把内容的标题、封面图、摘要等关键字段一起存进Feed流存储。好处是读取时零依赖，刷Feed的速度极快；坏处是如果作者编辑了内容，已经推送到用户时间线里的快照不会自动更新，需要在编辑时额外触发一次更新操作。
我推荐的做法是主存ID、辅存快照。Feed流的主数据只存ID，但可以附带一个小的内容快照用于Feed列表的快速渲染。当内容被编辑时，通过事件触发更新Feed流里的快照字段。这样既能保证大多数场景下读取速度很快，又不会出现内容更新不同步的尴尬情况。这部分后面讲缓存结构时再细说。
4. 两种分发模式之争：推模型、拉模型以及它们的折中
关注推送绕不开的一个经典话题就是推模型和拉模型之争。先说结论：没有哪个模型是绝对正确的，只有适合你的业务场景的模型。我从入门到现在，见过太多团队在这个问题上反复横跳，关键是没搞清楚两种模式的本质差异和适用边界。
4.1 推模型：写时扇出，读时零成本
推模型（Fan-out on Write）的思路是：作者发布内容后，系统立即把这个内容推送到所有粉丝的Feed流里。粉丝读的时候，什么都不用做，直接从自己的Feed流里拉取即可。
本产品早期的微博、Twitter都偏向这个模式。它的核心优势是读路径极短——用户刷时间线时，只需要查一个预先聚合好的列表，不需要临时去查所有关注对象的动态再合并。在数据库这种“读多写少”的资源模型下，这种牺牲写、优化读的思路在大多数场景下是划算的。
但推模型的致命弱点是“明星问题”。如果一个作者拥有几百万粉丝，他发一条内容，系统就要给几百万个粉丝各写一条Feed记录。几百万次写入，只为一次内容发布，这个放大倍数是极其恐怖的。而且在现实场景里，大多数粉丝可能已经很久没打开App了，这些写入大概率是无效的。
4.2 拉模型：读时聚合，写代价小
拉模型（Fan-out on Read）则反过来：作者发布内容后，不做任何推送。粉丝刷新时间线时，系统动态查询“我关注的作者们”最近发布了哪些内容，合并排序后再返回给用户。
这种模式的优点是写路径几乎为零，内容发布只写一次内容表，没有扇出过程。同时它还天然支持“关注后立刻看到历史内容”——因为每次读取都是实时聚合的。而且当用户取关一个作者后，这个作者的内容自然不会再出现在他刷新的结果里，数据一致性很强。
代价就是读路径变长。假设一个用户关注了500个作者，每次刷新时间线时，系统都要查询500个作者最近的动态，再合并去重排序。如果内容服务的查询效率不高，这个合并动作甚至可能把数据库打挂。更麻烦的是，如果用户关注列表里有一个更新频率非常高的账号，每一次刷新都会拉回一大堆内容，造成网络和计算资源的浪费。
4.3 推拉结合：工业界的主流解法
真实的大规模生产系统中，几乎没人用“纯推”或“纯拉”，都是推拉结合。基本思路是：给普通用户用推模型，给头部大V用户用拉模型，然后在读路径上做合并。
具体来说：
- 普通用户（粉丝量小于阈值）：作者发内容后，走推模型，立即扇出到粉丝的Feed流里。
- 大V用户（粉丝量大于等于阈值）：作者发内容后，不执行扇出，只在内容服务里标记“这位大V有新内容”。当普通用户刷新Feed时，额外查询一次自己关注的“大V列表”，把他们最近的内容拉进来，合并到主Feed流里。
这样做的好处是：大部分内容仍然走推模型，读路径很快；而大V的发布不会被放大到几百万次写入，只需在读时通过一次额外查询把它们的内容补进来。Instagram早期就是这么做的，我在自己的项目里也验证过这个方案的可行性。
阈值怎么定？没有统一答案。我根据压测经验定的是10万粉丝：当一个作者的粉丝量超过10万，触发一次全量扇出的耗时已经超过1秒，并且会给消息队列和缓存带来明显的压力，这种情况下走拉模型更划算。这个阈值不是一个静态参数，需要根据你系统的吞吐能力定期压测调整。
5. 时间线的排序与可见性：不是越新越好，而是更合时宜
关注推送走到这里，已经能把“新内容”推给“关注的人”了。但真正让用户觉得“这个关注流好用”的，往往是排序和可见性这些细节。
5.1 纯时间倒序，还是介入推荐排序
做关注流的第一个选择：排序规则。我的强烈建议是——关注流初期一定要用纯时间倒序，不要加任何推荐因子。原因很简单，关注流的核心价值是确定性。用户明确知道他关注了谁，他期望看到的是“最新发布的内容按时间排列”。如果你在关注流里插入“你可能还喜欢”的推荐内容，用户对关注关系的信任感就会降低。
当然这不意味着永远不能升级。当产品发展到一定阶段，可以在关注流的下半部分增加“关注的人推荐内容”区块，但主信息流仍然保持时间倒序。这个做法在微博和Instagram上都能看到影子。
排序的存储设计，通常是在Feed流缓存里用一个有序集合（Sorted Set），成员是内容ID，分数是发布时间戳。这样在读取时按分数倒序就能拿到倒序的时间线，非常高效。如果用的是Redis，ZSet的ZREVRANGE命令天然支持这个需求。
5.2 可见性过滤：推送前必须做的一次体检
“可见性”是关注推送里最容易被忽略但后果最严重的环节。简单说，不是所有“新发布的内容”都有资格进入关注流。比如：
- 作者设置了“仅粉丝可见”，但某个用户虽然关注了他，实际上是取关后被重新关注，系统里的关注关系还没更新，导致权限判断出错。
- 作者发的内容包含了不合适的词，被安全系统过滤，但推送事件已经发出去了，粉丝还是能通过关注流看到被删掉的内容。
- 作者发布后秒删（尤其是误发），删除事件和发布事件到达消费端的时间顺序错乱，导致删除覆盖到了新内容上。
我处理这类问题的方案是：推送内容ID之前，先做一次可见性预检。具体就是在推送链路里增加一道过滤逻辑：检查内容的状态（正常、删除、违规）、检查作者的状态（正常、封禁）、检查内容对目标用户的可见权限（公开、粉丝可见、仅自己可见）。这道检查要在写入Feed流缓存之前完成，而不是在用户读取时才做。虽然会增加推送链路的耗时，但能把大多数“不该出现的内容”挡在门外。
5.3 取关后的历史内容：一个需要明确产品决策的细节
这个细节我很少在技术博客里看到有人展开讲，但它在实际产品中非常关键。用户取关了某个作者之后，之前推送到他Feed流里的该作者的内容，是保留还是删除？
技术上，保留是最简单的——缓存里已有的数据不需要动，反正用户刷新时最新的内容已经不在列表里了。但产品体验上有时候会让人困惑：用户取关后，往下翻还能看到这个作者以前发的动态，这会不会让用户觉得“我没取关成功”？
我当时和产品经理一起定了一个方案：取关事件触发时，清理当前用户Feed流缓存中该取关作者最近30天的内容记录。超过30天的内容因为已经被用户消费过，不处理。这个方案既照顾了体验（取关后几乎看不到对方内容），又避免了全量清理导致的大量缓存操作。技术上实现也不复杂：消费取关事件时，从用户的时间线ZSet里按作者ID遍历删除即可，遍历的时间复杂度可以接受。
6. 实时性与一致性：关注推送最容易被忽略的坑
推送链路的实时性目标，我在不同的产品里遇到过完全不同的要求。社区App可以接受几十秒的延迟，但即时通讯类的动态圈子要求秒级送达。这里的关键是：实时性是一个产品决策，不是一个技术指标。你需要在项目启动时就明确目标延迟，才能合理设计架构。我当时的经验是，先定“10秒内完成扇出”为目标，达不到再优化，不建议一开始就追求毫秒级。
6.1 最终一致性：推送链路不可能做到强一致
要明确一点：关注推送链路在分布式环境下，几乎不可能做到强一致。原因很简单，一条内容的发布流程涉及内容库、消息队列、缓存存储等多个组件，任何一个环节出问题都会导致数据的不一致。我们能做到的是“最终一致”。
最终一致有几个典型的场景：
- 作者发布内容后，扇出进程还没来得及把内容ID写入粉丝的Feed流，粉丝刷新了。此时粉丝看不到这条新内容，过几秒再刷才能看到。
- 用户取关了一个作者，但扇出进程还在处理该作者早前发布的推送事件，导致取关后仍然出现了该作者的一条内容。
- 用户关注了一个新作者，但该作者的“大V拉取列表”还没有更新，导致用户刷新时没有把该作者的内容拉进来。
这些不一致在大多数场景下是可以接受的，只要持续时间不长、不频繁发生，用户基本无感。但如果持续时间过长，就需要补偿机制。
6.2 消息队列的乱序问题及其处理
消息队列在推送链路中承担着事件传输的职责，但它不保证消息的有序性。Kafka同一个分区内可以保证有序，但如果你的发布和删除事件进入了不同的分区，或者消费者做了重试，就可能出现乱序。
最典型的乱序场景是：作者发布内容A后立刻删除内容A。发布事件和删除事件先后进入队列，如果删除事件的消费者先执行完，发布事件的消费者后执行，就会导致内容A先被清理，然后又被写入Feed流。最终用户看到的内容A是已删除的，点击进去是404。
我解决这个问题的方法是：在内容写入Feed流缓存之前，先检查内容服务的当前状态。如果内容状态已经被标记为删除，就跳过这次写入。这个检查只针对“删除”这类不可逆操作，不会对正常内容的写入性能产生明显影响。另外一种做法是给每个内容ID加上版本号，写入时比较版本号，过期的写入直接丢弃，但实现复杂度更高，适合对一致性要求更高的业务。
6.3 数据对账：定时任务兜底
不管前面做了多少防护，总会有一些消息丢失、超时、编程Bug导致的数据不一致。因此，我强烈建议在系统里设计一个定时补偿任务。
补偿任务的逻辑不复杂：每隔半个小时，扫描最近半小时内发布的内容ID，对每条内容检查“粉丝的Feed流中是否已经有这条内容”。如果发现某条内容的粉丝覆盖率低于某个阈值，就重新触发一次扇出。
这里有一个细节要提醒：补偿任务不能做全量扫描，否则会给数据库带来巨大压力。我当时的做法是使用内容服务自身的一个“最近发布内容索引表”，只扫描这个索引，并且只对“扇出状态为未完成”的内容做处理。这样补偿的代价非常可控。
7. 上线后的性能问题与缓存优化
前面讲的都是链路设计层面的事，最后一块是性能优化。关注推送链路里的性能问题，绝大多数都集中在“读路径”——也就是用户刷新时间线时，系统要快速返回用户的关注流内容。这个环节的体验直接决定了用户是否会频繁打开你的App，所以值得多花心思。
7.1 Feed流缓存的选型与结构设计
在实时关注推送链路里，Feed流缓存我建议用Redis的ZSet结构。每个用户维护一个ZSet，key可以是feed:{user_id}，成员是内容ID，分数是发布时间戳。这样用户刷新时间线时，只需一条ZREVRANGEBYSCORE命令就能拿到指定时间范围内的内容列表，性能非常高。
但ZSet也有一个问题：它不支持按作者ID做条件查询。比如“取关后清理该作者近30天内容”这个操作，ZSet原生命令里没有直接按成员条件删除的接口，只能先取全部成员，再在代码层过滤删除。所以我在上面的方案里强调“遍历删除”是一个可接受的代价，就是这个原因。
如果你们的Feed流读取量更大，可以再往前加一层CDN或多级缓存，但大多数产品做到Redis这一层已经足够了。在百万级用户、每个用户平均关注量几十到几百的这个规模下，一个中等配置的Redis集群就可以扛下绝大部分读压力。
7.2 分页方式：为什么不用offset
关注流的读取一定要用游标（Cursor）分页，不要用传统的offset分页。原因是时间线数据是动态变化的——用户上次看到的最后一条内容可能已经因为删除、取关等操作被移除了，如果使用offset分页，翻页时可能跳掉数据或重复出现数据。
游标分页的思路是：每次返回一批内容时，带上这批内容里最老的那条内容ID和一个时间戳。下一次翻页时，把时间戳作为参数传回来，查询“分数小于这个时间戳”的下一批内容。这样即使列表中间发生了数据变化，也不会影响分页的连续性。这个思路在微博、Twitter的API设计里都能看到，是关注流分页的标准解法。
7.3 热点问题：大V发布的连锁反应
最后聊一下大V发布内容时可能出现的性能问题。在推拉结合模型下，大V发布内容本身不会引发全量扇出，但粉丝刷新时总会有一个“额外查询大V列表最新内容”的过程。如果某个大V的粉丝量极其庞大（比如几百万），短时间内有大量粉丝同时刷新，会对大V内容查询接口和Redis产生访问峰值。
我处理这个问题的方法有两个：一是给大V列表查询增加较短时间的缓存（比如10秒），这10秒内同一个用户多次刷新时，只会查询一次大V列表；二是给大V的内容单独建一个ZSet缓存，key可以是bigv_feed:{author_id}，专门缓存大V最近发布的内容ID。粉丝刷新时，从自己主Feed流的ZSet中取数，再从关注的大V的独立ZSet中取数合并，这比每次都查内容数据库要快得多。
提示：大V的独立ZSet里的内容保留数量建议控制在100条左右，既能覆盖普通用户一周的活跃访问，又不会消耗太多内存。
8. 一些经验总结和后续演进方向
做关注推送这套系统，前后花了我近三个月的时间，从方案设计到上线压测，中间经历了多次返工。回顾整个过程，我把自己认为最值得记住的几条经验放在这里。
第一，关注关系模型一定要在项目初期就设计好，尤其是分组字段这种看起来“以后再说”的东西，后期补的成本远高于一开始就预留。第二，推拉结合的阈值不要一开始就拍死，最好基于压测结果动态调整，随着系统容量变化，这个阈值也会漂移。第三，可见性过滤和消息乱序处理必须前置设计，不要等到上线后出了安全事故再回来补。第四，监控告警不能只有系统层指标，还要有业务层指标——比如“内容发布后10秒内到达Fanout完成的比例”，这个指标比CPU、内存更能反映关注推送的真实健康度。
说完这些，顺便提一下这个方向还可以怎么演进。如果你做到后期，需要支撑更大规模，可以考虑把Fanout从“同步写入”改成“异步批量写入”，用批量合并的方式减少数据库的写入次数；也可以引入更精确的“活跃粉丝”判定，只给最近活跃的用户Fanout，不活跃的用户等他们回来看时再补拉取。这个策略在不少大厂里已经成为标准手段，但实现之前要先确认你们的业务接受“不活跃用户看到的内容会比实时晚一点”这个前提。
我当时在项目里没有立刻上这个优化，原因很简单：业务方明确需要“所有关注者都能实时看到”，而且系统容量当时还没到瓶颈。技术方案好不好，永远要放到实际业务的背景下做判断。
这套关注推送系统上线后，我收到过不少反馈，也有些用户说“为什么我刷不出新内容”。每次排查到最后，九成以上都不是推送链路本身的问题，而是App端拉取时间线时的缓存策略太激进导致的。所以也想提醒一下：后端把链路做对了，前端也别乱加缓存，否则再实时的推送也会被客户端缓存卡住半拍。