本篇主要记录一个主从延迟导致的一个数据问题：

问题描述：

一个正常的发货操作，复核时采集了序列号，但是发货后回传给上游的时候，缺少序列号采集的数据。

问题分析过程：

看到这个问题时，只知道没有把序列号回传给上游，我们先去看了数据库有没有采集序列号的数据，发现有，说明确实采了且采成功了，然后我们去看了有关该订单的相关日志记录，没有发现明显异常报错的地方，单子也正常的在我们系统中出库，只是没有回传给上游。
所以我们就把关注点放到了客户操作的复核场景，我们先去确认了当时的复核场景，客户走的是拣货后直接批量发货，我们推测：批量发货时由于遇到了序列号商品，提示需要采集才能发货，此时用户去操作采集，采集完成后应该就立即发货了。按照我们的推测，这一系列的操作是没问题的，而且业务库的表数据也正确，为什么会出现这个问题呢？
我们思考了，代码执行回传的流程，订单发货后，会插入一个用于回传上游数据的job，插入后应该会立即执行，对比了表数据时间，确实是立即执行的，插入时间和发货时间相等（精确到秒），job执行成功的更新时间比插入时间晚1s，这个时候我们想到我们业务操作读取数据的走的是都是从表，系统使用了主从库，主库用于修改插入，从库用于查询（主要），只有特殊的业务场景才会查主库，经过排查，job查询的确实是从库，既然是从库就会有主从延迟的可能，经过请教公司前辈，我们的主从延迟在1s左右。
为什么验证我们的分析，只需要修改job的状态，自动再回传一次应该就会包含序列号的信息，在修改之前，也咨询了上游开发，重复回传不影响数据，修改后，再次回传的数据确实包含了序列号信息，到此问题分析出来了。

问题修复思路：

这个业务场景，并不需要立即回传信息给上游，所以我们可以将job的执行，延迟2~5s。