简介：在社交、社区和即时通讯后端开发中，时间线（Timeline）是承载数据流的核心数据结构。无论是朋友圈的好友动态、微博的关注Feed、消息中心的系统通知，还是IM的会话消息，其本质都是按时间排序的事件流分发与消费。理解推模型（Fanout On Write）与拉模型（Fanout On Read）的适用边界，是设计高并发读写系统的关键。推模型读路径轻但写放大严重，拉模型写放大为零但读时合并代价高，实际业务常采用推拉结合策略。通过抽象Timeline事件、游标分页、幂等去重及可插拔分发策略，可以将不同业务场景统一到同一套数据流建模体系中。本文从基础概念出发，剖析Timeline抽象库如何覆盖Feed流、通知推送与IM通讯的共性，帮助后端工程师设计出可扩展、可运维的时序数据流系统。 这几年做社交、社区、内容类后端项目，我几乎每隔一段时间就要在一个新项目里把时间线逻辑重新写一遍。朋友圈点了发布，粉丝要立刻拉到动态；微博大V发一条内容，百万级粉丝刷新要看得到；后台做消息推送，需要按标签把通知推到一批用户收件箱；IM要保证两个人之间的消息有序到达且不丢不重。这四类业务看起来天差地别，但落到代码层面其实是同一个问题：数据流的分发。我做的这个Java抽象库，就是把Timeline模式里“数据流如何建模、如何分发、如何被消费”的部分抽出来，让业务层只需要关心自己的关系链和业务语义。
这篇文章我会直接把整个抽象库的设计思路、核心接口、分发机制，以及它如何同时适配朋友圈、微博、消息推送、IM通讯这四类场景讲清楚。代码层面会给出一个最小可用实现，并把我在真实业务里踩过的坑一并说出来。适合正在设计feed流、消息中心、通知系统，或者单纯想理解时序数据流如何抽象的Java后端工程师阅读。
1. Timeline 模式：为什么要做一个“抽象库”而不是直接写业务
1.1 每家企业都在重复造同一个轮子
我见过不少项目组做动态feed流的方式：产品经理说要做“关注页”，后端就在用户表旁边加一张follow关系表，再写一条SQL把关注对象的最新内容查出来，然后按时间排序。第一版能跑，等数据量上来就开始出问题：SQL越写越重、缓存不知道怎么设计、分页越翻越慢。这时候才会有人意识到，“关注页”背后其实是一套独立于业务的时间线系统。
同样的剧情会在做通知中心、私信模块、广播消息时再演一遍。区别只是表名从follow变成tag、从friend变成conversation，排序逻辑和分发逻辑几乎一模一样。
我做这个抽象库的初衷很直接：把这些场景里公共的部分沉淀下来，让业务代码只表达“谁产生了什么数据、应该流向哪些接收者”，而不去关心接收者手里的时间线是怎么构建和持久化的。
1.2 抽象库的边界在哪里
很多工程师一听“抽象库”就往框架方向想，但这套东西不是Spring Boot Starter，也不是要接管全公司的数据存储。它的边界非常克制：
- 不管业务关系链怎么存：关注关系在MySQL还是在图数据库，跟这个库无关。
- 不管业务事件长什么样：朋友圈的图文、IM的文本消息、推送的告警通知，都是payload。
- 管的是Timeline本体：一个接收者手里那条有序数据流如何追加、如何读取、如何游标分页。
- 管的是数据流之间的分发：一条业务数据从生产者产生后，按照什么规则被复制到一批接收者的Timeline里。
这个边界很重要。如果库管太多，业务方会因为它不够灵活而放弃；如果管太少，又退化成一张表，没有抽象价值。Timeline抽象库的核心价值就两个词：建模和分发。
1.3 这个库解决了什么具体问题
第一个问题是语义统一。业务方不再需要各自定义一套“查询好友最新动态”的接口，而是统一理解成“读取某条Timeline的某个区间”。
第二个问题是写入链路的复用。无论数据来自发帖、发消息、发通知，统一走一个Dispatcher入口，分发的规则由业务方传入，但分发的过程、幂等、重试、游标推进由库来处理。
第三个问题是让容量评估变得可计算。一旦业务方理解了自己用的是推模型还是拉模型，就能算出“一次发布会产生多少份写放大”，这在架构设计阶段非常有用。
2. 朋友圈、微博、推送、IM 的底层共性
2.1 四种场景的形态对比
先把四种典型场景放在一张表里看，它们的表象差异会非常清楚：
| 场景 | 数据生产者 | 接收者范围 | 时间线维度 | 实时性要求 | 主要读写特点 |
|---|---|---|---|---|---|
| 微博/关注feed | 被关注的作者 | 粉丝集合 | 用户聚合流 | 秒级 | 读多写多，大V写放大极端 |
| 朋友圈 | 好友 | 好友集合 | 用户聚合流 | 秒级 | 好友数有上限，关系闭合 |
| 消息推送 | 系统/运营 | 标签、用户组 | 用户通知流 | 分钟级可接受 | 批量写入为主 |
| IM通讯 | 对话参与者 | 会话内成员 | 会话消息流 | 毫秒级 | 严格有序，实时性要求高 |
表里的“时间线维度”很关键。微博和朋友圈的用户时间线是由多个生产者聚合而成的；消息推送的时间线是由系统单方面写入的；IM的时间线则是按会话维度存储的，会话双方共享同一条流。
2.2 被业务表象掩盖的三个共同点
如果把表里的差异剥掉，剩下三个在所有场景里都成立的事实：
- 每个接收者最终看到的都是一个按时间排序的列表。微博用户看到的是关注对象的动态列表，用户看到的是好友动态列表，手机用户看到的是通知列表，聊天窗口里看到的是消息列表。
- 列表的构建都逃不开“发件箱/收件箱”模型。生产者先产生一条数据放进自己的发件箱，再通过某种机制被复制或关联到接收者的收件箱。区别只是复制是写入时做还是读取时做。
- 读取端都需要稳定的游标分页。用户下拉刷新、上滑翻页，本质都是在时间线上移动游标。
我在设计这个库时，就是围绕这三条共性来建模的。业务场景的差异通过“分发策略”和“时间线类型”两个扩展点来消化，而不是靠堆接口。
2.3 产品语义差异怎么映射到统一模型
这里最容易走偏的做法是：为了统一，强行让IM和微博共用同一套代码路径，结果两边都别扭。我的做法是保留“事件”和“分发策略”的抽象，允许业务定义自己的category和DispatchStrategy，不同的策略对应不同的数据流向。
产品层面的“朋友圈好友动态”、“微博关注流”、“通知中心”、“聊天会话”都是Timeline的实例，只是它们的生产者、订阅关系、分发时机不同。用户在UI上看到的是不同的页面，在系统里看到的是同一种数据结构。
3. 推模型、拉模型：时间线系统绕不开的路线之争
3.1 推模型（Fanout On Write）的适用边界
推模型的核心思路是：生产者在写入时就把数据复制到所有接收者的收件箱里。以朋友圈为例，你发一条动态，系统立刻把它写到每个好友的收件箱时间线里；好友刷新时直接读自己的收件箱，不需要实时聚合。
推模型的优势是读路径极轻。一个用户刷新自己的时间线，只需要按游标顺序从自己的收件箱取数据，不管关注了多少人，读取成本都只和自己的数据量相关。适合朋友圈这种关系链闭合、每个用户好友数有限（通常几千以内）的场景。
但推模型有一个绕不开的天花板：写放大。假设一个用户有500个好友，他发一条动态要写500份；如果一个千万级粉丝的大V也走推模型，发一条内容就要写千万份，这在任何存储系统里都不可接受。所以朋友圈能用推模型，微博不能完全用推模型。
3.2 拉模型（Fanout On Read）和延迟合并
拉模型的核心思路是：生产者只写入自己的发件箱，接收者读取时再实时聚合自己订阅的多个发件箱。微博的关注feed流就是典型：大V发一条微博只写一次，粉丝刷新时去读取自己关注的作者列表，再拉取每个作者的最新内容合并排序。
拉模型的优点是写放大为零，代价是读放大。一个用户关注了300个作者，每次刷新都要拉300个发件箱的最新内容再在内存里合并排序，读取延迟和发件箱数量成正比。为了缓解这个问题，业界一般会加缓存、并行拉取、做多级合并。
拉模型还有一个隐含问题：时间线牺牲了绝对的有序性。因为数据是读取时实时归并的，如果在聚合过程中某个作者又发了新内容，用户可能在同一页里看到“新一条”插在中间，导致游标分页变得复杂。
3.3 抽象层必须同时支持两者
很多自研时间线系统容易犯的错误是：选了一种模型就写死，后面想切换只能重写。我在抽象库中把“分发策略”作为接口暴露出来，推模型和拉模型是两种可插拔策略：
- 推模型对应写入时立即fanout到目标收件箱；
- 拉模型对应写入时只写生产者发件箱，读取时由
TimelineReader触发实时聚合。
实际业务往往是推拉结合的。大V走拉模型，普通用户走推模型；热点事件可以用“预聚合”的方式定期把热门作者的动态批量分发到粉丝收件箱；IM则因为数据量小但实时性要求高，通常直接走推模型。
抽象层不替业务做决策，它只负责提供两种能力，并把“分发后数据一致”的保障做好。具体哪条流用哪种模型，由业务在创建Timeline时通过配置声明。
4. 核心抽象设计：从接口到分发机制
4.1 一页纸讲清整体模型
这套库的逻辑可以用一句话概括：业务事件从生产者进入Dispatcher，Dispatcher根据订阅/策略把事件路由到一批目标Timeline上，使用者通过Reader从Timeline里按游标读取有序事件。
结合发件箱/收件箱模型看：
- 每个生产者也拥有一条“发件箱Timeline”，记录他产生的所有事件；
- 每个接收者拥有一条“收件箱Timeline”，记录他需要消费的事件；
- Dispatcher负责把发件箱的事件，按规则复制到接收者的收件箱。
读路径上不需要考虑数据从哪里来，只需要面对自己的收件箱。
4.2 最小接口集定义
我设计的核心接口只有四个，这也是整个库的心脏：
public interface Timeline { String timelineKey(); void append(TimelineEvent event); TimelinePage read(Cursor cursor, int limit); } public interface TimelineEvent { String eventId(); long timestamp(); String producerKey(); int category(); byte[] payload(); } public interface Dispatcher { void publish(TimelineEvent event, DispatchStrategy strategy); } public interface TimelineReader { TimelinePage read(String timelineKey, Cursor cursor, int limit); }Timeline接口定义一条时间线的最小行为：追加事件和读取事件。TimelineEvent是所有业务载荷的通用包装，eventId用于全局幂等，timestamp用于排序，producerKey标明来源，category用于区分业务类型，payload携带具体业务内容。
我没有把“删除”和“修改”放进接口里，因为时序数据流的核心语义是append-only。业务层面的“删动态”“撤回消息”应该通过追加一条“删除标记事件”这种方式表达，而不是物理删除历史事件。这个设计决策帮我避开了很多分布式场景下的数据一致性问题。
4.3 分发规则的表达：DispatchStrategy
分发策略是整个库扩展性最强的地方。它本质上是一个“给定一个事件，计算出需要投递到哪些Timeline”的函数。我用接口表达：
public interface DispatchStrategy { List<String> resolveTimelineKeys(TimelineEvent event); }推模型就是返回一批接收者收件箱的key；拉模型就是返回空列表（因为不需要复制）。但为了支持拉模式聚合，我还需要另一种能力：读取一个Timeline时，除了自身存储的事件，还需要合并其他Timeline的事件。所以TimelineReader有另一个聚合方法：
public interface TimelineReader { // 聚合读取：读取主timeline，并合并sources里的事件 TimelinePage mergeRead(String timelineKey, List<String> sourceTimelineKeys, Cursor cursor, int limit); }这样微博场景的读取逻辑就变成：用户的收件箱里可能只有普通用户主动推送来的事件，大V的事件不提前推送，而是读取时通过mergeRead动态合并大V的发件箱。
4.4 Cursor 游标为什么不是数字而是对象
早期我做时间线分页，直接用pageNum/pageSize或者lastId，都遇到过问题。lastId如果用的是数据库自增id，一旦数据迁移或者多库合并，顺序就不可靠；用offset深翻页则性能越来越差。
这个库里的Cursor设计成一个包含位置信息的对象：
public class Cursor { private final long timestamp; private final String lastEventId; private final boolean forward; public static Cursor start() {...} public static Cursor from(long timestamp, String lastEventId) {...} }timestamp定位时间位置，lastEventId防止同一毫秒内有多条事件时出现跳过或重复；forward表示向后翻页还是向前拉新。读取时先按timestamp过滤，再处理相同时间戳的事件，用eventId做排序和去重。这套游标模型在IM场景里同样成立，配合eventId的全局唯一性，可以做到不丢不重。
4.5 幂等和去重：分发链路上的基石
分发本质上是一个“复制”过程。只要涉及复制，就一定会遇到重复：网络重试、消费者重放、生产者重发，都可能导致同一条事件被追加两次。我在Timeline.append()实现里强制按eventId做唯一性约束。
在内存实现里，这个是ConcurrentHashMap加TreeSet的组合；在Redis实现里，用SETNX保证同一个timelineKey + eventId只写入一次；在MySQL实现里，timeline_key + event_id建唯一索引。这套幂等逻辑是跨所有存储实现公用的，业务方不需要关心重试问题，只管把事件交给Dispatcher就行。
5. 用这套抽象把四个场景各接一遍
5.1 模拟微博关注流：拉模型为主，推模型为辅
// 大V发布一条微博：走拉模型，只写大V自己的发件箱 String bigV = "user-10001"; TimelineEvent event = SimpleEvent.builder() .eventId(UUID.randomUUID().toString()) .timestamp(System.currentTimeMillis()) .producerKey(bigV) .category(Category.FEED) .payload(json.getBytes(StandardCharsets.UTF_8)) .build(); dispatcher.publish(event, event -> Collections.emptyList());普通粉丝读取关注页时：
// 粉丝user-20001读取时间线：先读自己的收件箱，再merge大V的发件箱 List<String> bigVOutboxes = followService.getFollowedBigVOutboxKeys("user-20001"); TimelinePage page = reader.mergeRead( "user-20001", // 自己收件箱 bigVOutboxes, // 大V发件箱列表 cursor, 20 );普通用户发布时走的还是推模型，DispatchStrategy返回所有粉丝的收件箱key。只有大V才切换策略，避免写放大。这样一套接口，两种策略就都接上了。
5.2 模拟朋友圈：典型推模型
朋友圈的场景是最契合推模型的：关系链闭合、好友数有上限。假设用户user-30001发了一条动态，他的好友列表直接从关系服务查出来：
List<String> friendIds = relationService.friendIdsOf("user-30001"); dispatcher.publish(event, evt -> friendIds.stream() .map(fid -> "inbox:" + fid) .collect(Collectors.toList()));每条动态都被复制到所有好友的收件箱。好友刷新时读取inbox:{uid}，天然有序，不需要任何实时合并。这也是朋友圈产品体验流畅的原因之一：读路径轻到几乎没有计算量。
朋友圈场景还有一个独有的需求：谁可以看。这类“可见性过滤”不适合放在时间线查询链路里做实时过滤，因为会拖慢读路径。我的做法是把可见性条件编码进分发阶段：如果一条动态是“仅部分好友可见”，那么DispatchStrategy返回的收件箱列表直接排除不可见好友。过滤提前到写入路径，读取端完全无感知。
5.3 模拟消息推送：按标签批量分发
消息推送和社交feed最大的区别在于：接收者集合不是“关系链”而是“标签或分组”。运营选一个标签，系统把通知发给这个标签下的所有用户。
String tagId = "tag:promotion-2024"; List<String> userIds = tagService.userIdsByTag(tagId); dispatcher.publish(event, evt -> userIds.stream() .map(uid -> "notice:" + uid) .collect(Collectors.toList()));这个场景的写放大规模通常是百万级。所以推送场景下我更推荐异步分发：Dispatcher只把事件写入一个待分发队列（比如用内存队列或消息队列），真正的fanout由后台worker批量执行。抽象库的Dispatcher接口本身就是异步实现和同步实现可以替换的，业务方按吞吐量要求选即可。
推送时间线还需要处理“过期失效”问题。比如一条优惠券通知，活动结束后再展示没有意义。我一般会追加一条“过期标记事件”而不是物理删除通知，客户端收到标记事件后做本地隐藏。这样可以保留完整历史，也避免物理删除在分库分表场景下的麻烦。
5.4 模拟IM通讯：会话维度的消息流
IM场景和前面三个都不一样：它不强调“一对多广播”，而是“一对一会话双方共享一条有序流”。所以IM的时间线key不是用户维度，而是会话维度。
String conversationKey = "conv:user-40001:user-40002"; TimelineEvent event = SimpleEvent.builder() .eventId(snowflake.nextIdStr()) .timestamp(System.currentTimeMillis()) .producerKey("user-40001") .category(Category.IM) .payload("在吗？".getBytes(StandardCharsets.UTF_8)) .build(); dispatcher.publish(event, evt -> List.of(conversationKey));会话双方读取时都读conv:user-40001:user-40002这一条时间线，通过游标做增量拉取。IM场景对顺序要求非常严格，所以timestamp应该由服务端生成，不能信任客户端时间；eventId用雪花算法生成，保证全局唯一且趋势递增。
IM的幂等逻辑比社交场景更重要。用户弱网重试、客户端重发消息，同一个eventId会被追加多次，Timeline层的唯一索引会兜住重复写入，客户端只需要按eventId做去重即可。这也是我把eventId设计成接口必填字段的原因。
5.5 一个内存版最小实现
为了让这套抽象不悬空，我写了一个内存版实现，逻辑足够简单，适合二次开发和理解核心流程：
public class InMemoryTimeline implements Timeline { private final String key; private final NavigableMap<Long, List<TimelineEvent>> events = new TreeMap<>(); public InMemoryTimeline(String key) { this.key = key; } @Override public String timelineKey() { return key; } @Override public synchronized void append(TimelineEvent event) { events.computeIfAbsent(event.timestamp(), k -> new ArrayList<>()) .add(event); } @Override public synchronized TimelinePage read(Cursor cursor, int limit) { // 游标过滤 + 按 eventId 排序 + 截断 limit List<TimelineEvent> result = events.tailMap(cursor.timestamp(), false) .entrySet().stream() .flatMap(e -> e.getValue().stream()) .filter(e -> isAfter(e, cursor)) .sorted(Comparator.comparing(TimelineEvent::timestamp) .thenComparing(TimelineEvent::eventId)) .limit(limit) .collect(Collectors.toList()); if (result.isEmpty()) { return TimelinePage.empty(); } TimelineEvent last = result.get(result.size() - 1); return new TimelinePage(result, Cursor.from(last.timestamp(), last.eventId())); } }这段代码里最容易被忽略的是tailMap(cursor.timestamp(), false)的边界条件。游标记录的是“上一次读取的最后一条事件”，下回读取要从这个时间点的后面开始，所以用false表示不包含当前时间戳。相同timestamp的多条事件，则通过eventId字符串排序保证全局顺序稳定。
6. 从抽象到落地：缓存、分页、热点这些坎儿
6.1 存储选型不能一套打天下
很多人拿到这个库首先问：Timeline数据应该存哪里？我的经验是分场景：
- 社交feed流：推荐Redis的Sorted Set，
ZADD按时间戳写入，ZREVRANGE按游标读取，天然支持按分值范围分页。数据量大可以做冷热分层，旧数据下沉到MySQL或者对象存储。 - IM会话流：推荐用类Cassandra的宽表存储，或者直接用成熟的IM存储，保证多端同步的可靠性。内存库结合消息队列也可以做前置层。
- 消息推送：推送的读频率远低于写频率，但一次性写入量大，适合用MySQL批量插入加Redis缓存热点数据。
存储实现和抽象接口是解耦的。我始终把Timeline、Dispatcher、TimelineReader作为接口，存储细节全部放在实现类背后。这样业务在早期用内存实现验证模型，数据量上来之后无缝切换到Redis或数据库实现，不需要改业务代码。
6.2 时间线分页：游标比Offset可靠得多
用offset做时间线分页的问题其实不只是性能。你在offset翻页的时候，如果前面插入了新数据，整页内容会整体后移，用户会看到重复或不连续的内容。游标分页不会受这个影响，因为它锚定的是“上一次读到的位置”，新数据来了只会出现在游标之后。
IM场景的增量同步更是离不开游标。客户端每隔几秒拉一次新消息，带上的就是上次同步的游标。服务端只需要返回游标之后的事件，天然做到“只拉增量”。
我在实际使用中养的的习惯是：把游标序列化成不透明字符串下发给客户端。客户端不解析、不修改，每次原样返回。这样服务端可以自由演进游标内部结构，不用考虑兼容性。
6.3 大V热点的缓解手段
拉模型虽然解决了大V的写放大问题，但把压力转移到了读路径：百万粉丝同时刷新，大V的发件箱会被反复读取，这个key会成为热点。
我常用的缓解手段有三个：
- 本地缓存：在应用层加大V发件箱的短时本地缓存，比如几百毫秒到一秒，能挡住大部分重复请求。
- 时间片拆分：把大V的发件箱按小时拆成多个子时间线，读取时并行拉取。这样单个key的压力就分散了。
- 多级合并缓存：热门关注的“聚合结果”可以预计算，按秒级更新，粉丝直接读预聚合结果而不是实时合并。
这些手段都符合抽象库的接入方式：缓存逻辑写在TimelineReader实现里，业务层完全无感。这也是接口抽象带来的额外好处，调优可以发生在框架内部，不必层层传递。
6.4 时间戳统一用服务端时间，别信客户端
时间线排序最怕的就是时间错乱。客户端本地时间可能被用户修改，也可能因为时区问题产生偏差。如果服务端容忍客户端时间戳直接参与排序，就会出现“新消息排在旧消息后面”这种严重事故。
我的规则是：所有进入Timeline的事件的timestamp必须在服务端生成，客户端传的时间只作为业务字段保存，不参与时间线排序。IM场景尤其要注意这一点，服务端收到消息后立即打点，再交给Dispatcher分发。
6.5 关于持久化、备份和迁移的提醒
内存版实现适合做验证，不能直接上生产。接MySQL实现时，建议timeline_key、event_id、timestamp建联合索引或唯一索引；接Redis实现时，要注意RDB和AOF的配置，因为纯内存版在宕机时会丢数据。IM场景如果允许少量丢失可以做异步刷盘，但如果要求严格不丢，需要引入可靠消息队列和多副本存储。
我见过一个项目因为没给timeline数据做备份，误删一条大V发件箱记录后，几十万粉丝的时间线同时缺了那条内容，排查了整整一下午。从那以后我所有Timeline实现类都会默认加上“事件追加审计日志”，写一条真实数据之前先写一条审计记录，万一出问题可以靠审计日志重放恢复。
7. 一次实际集成把我坑醒的教训
最后说一个我自己犯过的错误，算是给这个抽象库做一次“现实检验”。
之前把一个消息中心业务迁到这套模型上，初期只考虑了“写入、读取、游标”三个动作，没想过“大V发件箱被粉丝并发拉取”的压力。上线后运营做了一次全量推送，目标用户300万，推送事件全部走了推模型，瞬间把存储写入打满，数据库慢查询暴涨。后来我把策略改成：运营推送走异步批量分发，同时普通用户走推、大V类账号走拉，问题才缓解。
另一件事是eventId的生成规范。最开始有的业务方用时间戳加随机数拼eventId，并发一高就出现重复，幂等校验直接把合法事件挡在外面。后来统一要求必须用雪花算法或者UUID，每个事件的eventId全局唯一，幂等逻辑才真正可靠。
根据我个人的经验，这套Timeline抽象最大的价值不是省了那几张表的代码，而是逼着业务方在写第一行代码之前就把“数据从哪来、流向谁、怎么排序、怎么分页”这四个问题想清楚。越早理清数据流，后期越少返工。如果你也正在设计feed流或者消息系统，建议先画一张数据流图，再套这套抽象，能少踩不少我踩过的坑。
本文还有配套的精品资源，点击获取
