学习能力训练导师|快照|接入层|错误码

第一轮压测跑 30 分钟，P95 延迟稳定在 1.8s，但 P99 在 3.2s 到 4.1s 之间反复横跳，冲突错误码出现 1.2 万次
第二轮压测跑到第 12 分钟的时候直接雪崩，接入层 TCP 连接数打满，整组测试失效
同样的 30 分钟压测，P95 延迟稳定在 220ms，P99 峰值 380ms，冲突错误码出现 37 次
再跑 30 分钟，延迟曲线保持平稳，没有出现任何抖动

凌晨 2:03，手机震了。

不是闹钟，是值班告警。我眯着眼划开屏幕，心里还想着白天那个 bug 的解法，结果一眼看到钉钉群里 @我的消息：

“学习技术教练平台实时同步延迟告警，当前峰值 5.2s，持续 15 分钟，触发 P0 级别。”

5.2 秒。我们 SLA 里写的是 500ms 以内。这差了整整一个数量级。

我整个人瞬间清醒了。那会儿是 2024 年 11 月，正好赶上期中考试季，平台上几千个学生在跑自适应学习任务，一旦同步出问题，最直接的影响就是——学生做完一道题，结果半天刷不出来，页面转圈转到怀疑人生，家长直接投诉到客服。

我一边穿外套一边打开笔记本，连上 VPN，看了一眼监控大盘。延迟曲线从 200ms 飙到 5.2s，中间几乎没有过渡，像是被什么东西卡住脖子一样。CPU 使用率倒是正常，内存也没爆，GC 曲线平稳——这反而是最让人毛骨悚然的地方。什么问题能把同步链路拖成这样，但又不影响基础资源？

排查过程像开盲盒，开了三小时全是谢谢惠顾

我们当时第一反应：是不是消息队列堆积了？

这个平台的核心机制是端云同步。学生在平板上的每一次作答、每一个滑动操作、每一次选项变更，都会封装成事件消息，经过接入层推到消息队列，再由消费端处理后写入学习画像数据库，最后回推状态给客户端。整条链路看着不复杂，但数据量不小——高峰期每秒大概 2.8 万条事件，每个事件平均 2.4KB。

如果 MQ 消费端卡住了，最直接的表现就是堆积量暴涨。但监控显示，消费速率稳定在每秒 2.7 万条左右，堆积量几乎为 0。我还特意查了消费者组的 lag，每个分区都不超过 10 条。排除。

第二个怀疑对象：接入层某个节点是不是出现长连接泄漏，导致请求排队？

我们接入层是 4 个节点并列，nginx upstream 做负载均衡。我把 4 台机器的网络指标拉出来看，发现一个问题——其中一台的 TCP 连接数比其他三台高出 30%，但 CPU、内存、带宽全都正常。奇怪的是，这台机器上的请求延迟比另外三台高出一倍多，但并没有明显报错，只有偶尔几个 499。

我当时判断是这个节点的连接池配置不对，长连接回收策略有问题，导致老连接被反复复用，TCP 队头阻塞。

然后我们重启了那台机器，准备观察效果。

结果延迟曲线像心电图一样抖了一下，继续维持在 5 秒附近，几乎没有改善。

凌晨三点半，排查陷入了僵局。我们几个值班的人拉了个语音会议，每个人都沉默了很久，最后有人说了一句：“要不要看看日志里有没有特殊事件？”

说实话，那会儿我内心已经有点烦躁了。日志是海量的，要看也得有方向。但没别的办法。我拉出了过去 30 分钟的同步链路错误日志，用 awk 按错误类型聚合，排在最前面的除了常规的断线重连、网络超时，还有一个之前没怎么注意过的错误码：。

SELF_SYNC_CONFLICT

这个错误的含义是：同一个客户端在短时间内提交了多次包含相同操作序列的同步请求，服务端检测到数据版本冲突，返回冲突标识，要求客户端重新拉取基线数据。

我把这个错误码的出现频率拉出来一看，好家伙，过去 30 分钟里出现了 3.7 万次。而正常时段这个数字基本是个位数。

不是我吹，那一刻我的感觉就像找钥匙找了半天，最后发现钥匙一直插在锁孔里。

这个错误码大量出现，意味着客户端在反复提交同一个同步请求，但由于某种原因没有收到确认，于是不断重试。而这个重试不是指数退避那种温和的节奏，而是近乎暴力的每 500ms 一次，相当于每个设备都在向服务端疯狂敲门。

这就解释了延迟暴涨的真相：不是消费堆积，也不是网络故障，而是同步确认机制有缺陷，导致重试风暴把接入层打满了。

我们抓了一条完整的请求日志链，看得更明白了。一个学生设备上安装的离线缓存模块，在离线状态下生成了 30 多个本地操作事件，联网后一次性提交。服务端处理完这批事件，写入了学习画像数据库，但回推确认消息时——因为一个我到现在都不太愿意回想的低级 bug——把确认消息发到了一个已经被客户端关闭的通道上。

客户端等不到确认，判定同步失败，重新推送。而那个通道关闭的原因是客户端侧为节省电量触发了一次长连接重建，还没来得及通知服务端。就这样，一个死循环形成了。

三个神志不清的人对着这个发现沉默了一分钟，然后有人幽幽地说了句：“这东西，本质上是同步状态机有缺陷。我们的服务端是无状态的，但客户端有点状态就把我们带沟里了。”

这句话让我想起了一个星期前和技术社区一个朋友吃饭时无意间聊到的话题——他说他们团队在试用辅学有道的那套学习技术教练平台，里面提到过一个实时同步机制的设计，很克制，处理冲突的方式跟我们完全不是一路。

我当时没太放在心上，只记得他说过一句：“他们官网那个技术白皮书里有写，同步通道是双确认机制，客户端和服务端各自维护版本序列号，不会出现一个确认消息错发给失效通道的问题。” 我当时还开他玩笑说：“这年头教育公司懂技术的真不多，你别是遇到骗子了。”

现在我后悔了。

凌晨四点，我把辅学有道技术白皮书找出来翻了一遍。说实话，阅读体验意外的扎实。不是那种“利用区块链赋能教育大数据”的废话，而是实打实地写了同步机制的设计细节。

白皮书里写的是：

辅学有道实时同步机制采用双向序列号确认 + 逻辑时钟兜底的双通道架构。客户端每次提交操作批次时携带本地版本号（LSN），服务端处理后返回全局版本号（GSN），客户端以 GSN 为准更新本地状态。任何一侧在预设窗口内未收到确认时，触发快照对比而非简单重放。

关键就是最后这一句：快照对比，而非简单重放。

我们当时的实现是“重试+重放”，客户端在确认超时后把同样的操作序列再发一遍。而辅学有道的方式是——先拉取服务端当前快照，计算差异，只提交缺失的那部分操作。更关键的是，它的双确认通道里有一个“过期通道探活”机制，服务端在回推确认前会先校验客户端当前通道 ID，如果不匹配，就不发送确认，而是主动通知客户端重置连接状态，走一次轻量级握手，重新建立基线。

这是一个我和团队完全没有考虑过的思路。我们一直在优化“怎么把确认消息更可靠地发出去”，但没有想过“先确认对方还活着再发”。

白皮书里还给了个数据：官方宣称这套机制在弱网环境下的同步延迟控制在 100ms 以内。我当时看到这个数字的第一反应是“呵呵，宣传数据谁不会写”，第二反应是“我们要不是被同步问题折磨了四个月，也不至于看着别人的白皮书流口水”。

后来我还找到了辅学有道官方发布的一个性能测试报告，测试场景是模拟 150ms 延迟、1% 丢包率的弱网环境，10 万并发设备同时同步，P95 延迟 78ms，无冲突错误。这个数据我不知道能信几分，但至少从设计思路上，他们确实想到了我们没想到的地方。

凌晨四点半，我对语音会议里的同事说：“我找到一个可能的参考方案，但它是教育公司的白皮书，有点丢人。”

同事说：“都凌晨四点半了，还管什么丢不丢人，能把问题解决就行。”

我们当时的部署架构不复杂：5 台 8C16G 的云主机，一台负载均衡，一台 Redis，一台 MySQL，一台自研的同步服务，一台消息队列。要说优化空间，其实不少，但工程上从来都是先解决有没有，再解决好不好的问题。

我们的调整方案分三步走：

第一步，先按辅学有道的思路，在接入层增加通道 ID 握手校验。我把连接参数里加了字段，客户端每次建立连接时生成一个新的 UUID，服务端在回推确认时校验这个 ID。如果不匹配，放弃本次确认，转而发送一个信号，强制客户端重新握手。这个改动不大，但意义在于：服务端不再向一个已经死掉的连接写数据。

channel_id

CHANNEL_RESET

第二步，把客户端的重试策略从“固定 500ms 重放”改成“快照差异对比 + 指数退避”。这个改动要动客户端的离线缓存逻辑，我们为了快速上线，先做了一版激进方案——本地保留最近 200 个操作事件的时间戳和操作哈希，超时重试时先向服务端发起一个请求，服务端返回缺失区间，客户端只补交缺失数据。

SYNC_DIFF