跨系统类实时传输数据解决办法

跨系统类实时传输数据解决办法

目前常规的做法有下面2种

• 数据提供系统异步实时推送、同步实时推送
• 目标系统定时拉取

两者要看具体的业务场景，除了同步实时推送，其他的实现方式都可以归类为类实时，因为网络传输到目标系统处理逻辑，是需要时间的

技术名词解释

• 异步实时推送

数据提供系统的新增、修改、删除，在不影响自身逻辑的情况下，异步调用目标方接口，进行推送数据，记录对方处理的结果状态，有稍微的延迟，实现起来非常复杂，要考虑幂等性。如果对于有序修改的业务场景：如商品价格的多次修改，其中有一次失败，基于重处理的机制策略要求就非常高，系统实现太过复杂，运维成本巨大。

• 同步实时推送

数据提供系统的新增、修改、删除，在不影响自身逻辑的情况下，同步调用目标方接口，进行推送数据，要考虑幂等性，对方处理成功后，数据提供系统再提交事物，好处是及时性高，缺点是系统耦合性太高，有一方系统出问题就不能作业。

• 系统定时拉取

大家看到这个，有些人可能觉得太low了，有些人可能觉得太消耗目标系统资源了，还有及时性差、重复数据的问题，常规的做法确实存在这种情况，但是大家不得不承认：是真得好用，起码不会丢数据吧！！！

技术细节

异步同步推送实现复杂，同步推送系统之间的耦合性太高，两者要看具体使用场景，我个人建议不要再使用推送方案了，毕竟mysql主从同步都是从库拉主库的binlog数据，我们为什么还要使用这种不符合常规操作的技术方案，我推荐使用系统定时拉取方案，优点：及时性比较高，不会因为系统停机维护从而需要重新推送、重新拉取的操作。方便排除问题，不会因为网络原因导致无法传输数据。下面我就不贴具体代码了，简单的讲一下：

• 新建系统配置表

加入类型是为了支持更多的拉取任务，批次间隔时间是为了解决某个时间段数据量过大内存溢出的问题，目标系统一般会分批返回数据，很少出现全量给的。预警阈值是为了告知异常通知给管理员。

实现讲解

系统定时拉取数据一般是通过时间区间来获取的，第一次请求也存在拉取全量数据的情况，这个时候系统管理员可以按照需求来填写“开始时间”，进行数据初始化。批次时间可以根据自己系统内存处理数据量来设置大小，这里默认30分钟。

如果开始时间-结束时间（当前运行时间）<30分钟，就不需要分批累加开始时间了，如果处理成功，修改配置表状态为30（成功）开始时间替换成上次运行的结束时间，预警阈值置0。这里程序需要记录整个处理的时长，如果<2s，系统就动态休眠（2s-运行时长）,超过2s就不休眠，直接进行下一次任务。可以看出整个过程是阻塞式获取，及时性是非常好的。

处理数据时要注意先删后增，保证数据唯一性。

如果开始时间-结束时间（当前运行时间）>=30分钟,就需要把开始时间-结束时间（当前运行时间）拆分成多个时间段，每个时间段成功后就修改配置表开始时间加30分钟（提交事物），如果处理失败，后面不断阻塞式重试，并且配置表记录重试次数（开始时间不替换，保持上一次运行的值），达到预警阈值后，通知管理员处理异常。

小结

不要闭门造车，多看看行业做法