适用场景：多端消息同步（IM 聊天、多设备通知、跨实例状态同步、数据变更同步）；核心目标：多端最终一致、消息不丢、时序可控、区分已读 / 未读。下面按大类拆解，包含原理、优缺点、适用场景、典型组件。
一、拉取模式（Polling 轮询）
原理
客户端主动向服务端定时请求增量消息，服务端记录客户端同步位点（offset/seq），每次请求带上位点，返回位点之后新增消息。
位点：序列号 seq、时间戳 ts、版本号 version。
分为：短轮询（固定间隔）、增量轮询（只拉增量）。
特点
✅ 实现最简单；服务端压力可控；弱网友好；故障恢复容易 ❌ 实时性差；轮询间隔越小，服务端 QPS 越高；空轮询浪费资源
典型场景
后台管理消息、低实时通知、小程序 / APP 非核心消息；早期 IM 方案。
二、长轮询（Long Polling）
原理
客户端发请求，服务端hold 住连接不立即返回；当有新消息到达，或超时时间到，才返回结果。客户端收到后立刻再次发起请求。
本质：拉取的优化版，HTTP 协议下最常用的半实时方案。
特点
✅ 相比轮询实时性大幅提升；兼容 HTTP，穿透防火墙；不需要升级协议 ❌ 连接管理开销；服务端需要维护大量挂起连接；连接断开需要重连 + 位点续传
典型场景
网页端 IM、客服系统、消息通知；钉钉网页版早期、部分客服系统。
三、流式长连接（WebSocket / QUIC Stream）
原理
建立一条持久双向连接，服务端有消息直接推送 (Push)到客户端；客户端维护本地同步位点，用于断连重连后回溯拉取丢失消息。
标准 IM 主流方案：WebSocket 推送实时消息 + 断连后增量拉取兜底。
核心流程：
客户端鉴权建立 ws 连接
服务端消息投递到连接
客户端 ack 确认收到
断连重连 → 携带本地最大 seq，拉取断线期间消息
特点
✅ 实时性最好；双向通信；开销低；支持二进制消息 ❌ 连接保活、心跳、断线重连逻辑复杂；网络环境差容易断连；部分防火墙拦截
典型场景
移动端 IM、实时聊天（微信 / 抖音 IM 底层思路）、实时弹幕。
四、基于消息队列的同步方案（服务间同步，再推客户端）
多用于服务集群内部消息分发，再结合上面长连接对外推送给端。
原理
业务产生消息写入 MQ（Kafka/RocketMQ/RabbitMQ）；
按用户 ID 做分区，保证单用户消息有序；
同步服务消费 MQ，投递到对应客户端长连接；
位点保存在 MQ offset + 数据库用户同步游标。
特点
✅ 削峰；消息持久化；集群水平扩展；消息可回溯；多消费者广播 ❌ 架构重；需要处理重复消费、消息有序、延迟；运维成本高
典型场景
大规模 IM 中台、直播消息、多服务之间事件同步。
五、状态同步方案（状态机同步，适合状态类消息而非离散消息）
和消息同步有区别：不是同步一条条消息，而是同步对象状态。
原理
维护对象版本号，客户端拉取最新状态 / 增量补丁；服务端记录状态快照 + 变更日志（oplog）。
差分同步：只下发变更 diff，不推全量
CRDT / OT：协同编辑类，无主从，多端本地合并冲突
特点
✅ 适合协同文档、画布、在线房间状态；带宽小 ❌ 不适合聊天这种离散时序消息；冲突合并逻辑复杂
典型场景：飞书文档、在线白板、房间成员状态同步
六、变更数据捕获 CDC（数据库层面同步）
原理
监听数据库 binlog/wal（MySQL binlog、PG wal、openGauss wal），捕获数据变更，转成消息同步给其他端 / 其他库。
多用于：服务内部数据同步，一般不直接推给终端用户。 组件：Canal、Debezium、Flink CDC、SeaTunnel。
✅ 业务无侵入；自动捕获增删改；适合多库数据同步 ❌ 时序、过滤、事务完整性处理麻烦；不适合面向 C 端实时消息推送
七、Event Snapshot + 增量回放（事件溯源式同步）
原理
所有变更作为事件持久化，每个用户有独立事件流；客户端保存已同步事件 ID；上线时：
先拉最新快照（快速拿到当前状态）
再拉快照之后增量事件回放，补齐消息。
✅ 时序极强；可任意回溯；审计友好；适合强一致性业务 ❌ 存储成本高；回放事件消耗算力；快照管理复杂
场景：金融消息、审批流、企业 IM 历史消息同步
八、多端同步扩展模型：读扩散 / 写扩散
这个是消息存储分发模型，经常和上面传输方案组合使用，IM 领域核心选型点
1）写扩散（写多副本）
发送消息时，一次性写入所有接收者的消息队列 / 消息表。
优点：接收方拉取消息逻辑简单，读性能好
缺点：写放大，群聊人数多时写压力爆炸
适用：私聊、小群
2）读扩散（写单副本）
消息只存一份，接收方读取时，根据关系列表自己过滤。
优点：写压力小，大群友好
缺点：读压力大，每次读需要计算可见消息
适用：超大群、直播间弹幕
工业界常用混合：私聊写扩散，大群读扩散。
方案对比总表
工业界标准成熟组合方案（最推荐做 IM 多端消息同步）
WebSocket 实时推送 + 服务端 seq 位点 + MQ 做消息分发 + 写扩散私聊 / 读扩散大群 + 断线增量拉取兜底 + ACK 去重
在线：websocket 推送消息，客户端返回 ack，服务端标记已投递
断连重连：客户端携带本地最大 seq，拉取断线区间消息
持久化：消息落库，维护每个用户同步游标
多端：同一账号多设备共用一套 seq 流，实现多端消息一致、已读状态同步
核心通用问题（所有方案都要考虑）
消息有序：单用户消息保证顺序，多用户之间不保证；用分区 / 单流 seq
消息去重：幂等，消息携带 msgId，客户端做去重表
已读同步：已读回执上行，更新服务端游标；多端同步已读位点
弱网：心跳保活、自动重连、断点续拉、消息本地缓存
消息丢失：投递 ack 机制、消息持久化，不丢在内存
消息积压：限流、丢弃、降级、MQ 堆积告警
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢