积分接口对接踩坑复盘：一次发帖延迟入账引发的同步策略调整

两个月前我们社区上线了发帖回帖积分奖励功能，最初设计很简单：发帖成功 → 调用积分接口 → 写入积分流水 → 前端弹出“+5积分”提示。看起来一条直线走完，但上线第一天就出问题了。

用户发帖后积分没有立刻到账，部分帖子甚至等了十几秒才显示积分变动。后台日志显示，积分接口响应时间平均在800ms左右，高峰期能到2秒。问题是发帖主流程在等积分接口返回后才提交事务，等于把积分系统的慢查询压力直接传导给了发帖操作。

第一版优化是改异步。发帖主流程提交成功后，把积分操作丢进消息队列，前端不再等待积分结果。但紧接着又踩了新坑：用户发完帖子立刻刷新个人中心，积分还没加上，就误以为奖励没生效，投诉接踵而至。

后来我们把方案调整为“本地事务优先 + 补偿同步”双轨制。核心思路是：发帖时先在本库积分表插入一条pending状态的流水，主流程立刻返回成功，前端看到的是本地流水里的“待入账”标识；后台Worker每隔几秒把pending流水批量推送给积分中心，确认后更新状态为done。

这个方案解决了两个痛点：一是发帖主流程不再被外部接口拖累，响应时间回到200ms内；二是用户在个人中心看到的积分是本地流水加pending的合计值，感知上积分是即时变化的。即使积分中心暂时不可用，本地流水也不会丢，等恢复后Worker会自动重推。

对接过程中还有几个细节值得注意。第一，积分接口的幂等键必须用发帖ID而不是用户ID加随机数，否则重复推送会导致积分翻倍。第二，本地pending流水要加一个超时标记，超过5分钟仍未确认的自动触发告警，方便人工介入。第三，回帖积分和发帖积分要分开两条流水记录，不要合并成一条，否则后续做积分明细查询时对账会很痛苦。

最后说下测试心得。模拟积分中心宕机是最有效的验证手段——把接口地址故意配错，然后连续发帖回帖，观察本地流水是否正确堆积、恢复后是否能自动补推。我们还写了个小脚本随机延迟积分接口响应，用来验证超时重试逻辑不会产生重复流水。

这套方案上线三周，发帖成功率稳定在99.9%以上，积分到账准确率100%，没有再收到用户关于积分延迟的反馈。如果你也在做类似的积分联动改造，建议先想清楚主流程和积分系统的耦合边界，异步补偿虽然多写点代码，但比硬同步省心太多。