一种集装箱码头跨服务信息通信和数据同步方法

技术领域

本发明涉及集装箱码头通信技术，更具体地说，涉及一种集装箱码头跨服务信息通信和数据同步方法。

背景技术

在应用微服务架构的集装箱码头生产管控系统(TOS)中，服务间存在数据隔离的问题，例如：在A服务操作了某数据后，在B服务上并不会同步知晓该数据的变化，从而导致B服务不能及时的对相关操作进行反应。如何实时监控数据的变化并在各个服务间相互通信是一项复杂的问题。工业软件系统要求稳定且可靠，这对于如何解决上述问题带来了局限性。

目前传统的方式使用消息中间件来实现服务间的通信以及数据同步，但是存在以下几个主要的缺点：

1)系统可用性降低：系统引入的外部依赖增多，系统的稳定性就会变差，一旦消息中间件宕机，就会对业务产生重大影响。

2)系统的复杂度提高：引入消息中间件以后系统复杂度会大大提高。以前服务之间可以进行同步调用，引入消息中间件以后会变成异步调用，数据链路会变得的更加复杂，并且会带来一系列的问题。

3)消息一致性的问题：因为是异步调用，不同服务之间相互隔离，有可能会出现A系统成功而B系统失败的问题。

4)如果网络变慢，消息中间件设置的缓冲区太小会导致客户端空闲，但如果网络正常运行，缓冲区太大会导致大量额外的延迟。

在不使用消息中间件来进行服务间通信的话，在服务的集群化部署下可能会产生数据重复消费的情况。目前传统的方式是使用分布式的任务调度平台来控制，这也不可避免的增加了服务对外部系统的依赖，也产生了一定的不确定性。

发明内容

针对现有技术中存在的上述缺陷，本发明的目的是提供一种集装箱码头跨服务信息通信和数据同步方法，能够替代各个服务中的消息中间件，并且能够保证服务间通信的准确性和及时性。

为实现上述目的，本发明采用如下技术方案：

一种集装箱码头跨服务信息通信和数据同步方法：

在每个服务中均内嵌一个监听器；

在每个服务中均内嵌一个可配置的定时任务；

在每个服务中均设置统一的接口，用于监听发送过来的事件；

统一每个服务的管理事件的发送时机；

将服务操作、redi s数据、本地缓存、本地磁盘数据预数据库进行同步。

较佳的，将服务操作、redi s数据、本地缓存、本地磁盘数据预数据库进行同步具体包括以下步骤：

S1、在前端系统触发数据变动的操作后，由服务统一对变化的数据进行处理，将处理好的数据保存至“事件日志”表中；

S2、定时任务根据设定时间执行一次，查询“事件日志”表中的数据变化，在读取数据后，先将本地缓存中的编号与redis数据中相应的对象编号进行对比，二者取其大；然后再与刚读取的数据编号进行对比，若刚读取的数据编号小，则不作操作，若刚读取的数据编号大，则将读取的数据进行处理；

S3、将读取的数据进行格式转换后保存至“事件日志”表中，并先修改本地缓存，再修改redis数据缓存，最后将数据发送出去；

S4、订阅了相关“事件对象”的服务接收数据，进行相应的处理。

较佳的，步骤S1具体包括：

在前端系统进行操作时，对应的服务会产生数据变化，在操作完成后对变化的数据进行处理、格式转换，调用公共的接口将处理好的数据保存至“事件日志”表中。

较佳的，数据在保存前还需进行二次处理和筛查：

遍历数据，每个“监听对象”数据均需对应“事件日志”表中的多条trigger数据，先判断trigger数据和“监听对象”数据是否为空，若二者满足一个为空，则直接跳过，进入下一个循环；若都不为空，则将trigger数据进行格式转换，存入“事件日志”表中。

较佳的，步骤S2中，每个服务的定时任务轮询的数据类型均是根据程序启动时读取的“监听对象”来确定；

为保证服务在集群化部署的情况下相同的服务同一时间只有一个定时任务能读取数据，采用redis分布式锁的方式，并且为了防止死锁或者数据写入过程成锁失效的问题，还采用了lua脚本的形式来给定时任务加锁、解锁、续期；即

若分布式锁存在，则本次定时任务不执行；若分布式锁不存在，判断“监听对象”的集合是否为空，若为空则本次定时任务不执行；若不为空，查询“监听对象”的集合是否在数据库中存在，若全部都不存在，则本次定时任务不执行；若部分存在，则删除不存在的“监听对象”后执行本次定时任务；若全部存在，执行本次定时任务，遍历“监听对象”，在“事件日志”表中查询出配置的小时内关于该对象的所有trigger数据。

较佳的，步骤S3具体包括：

遍历跳表，取出本地缓存中的值，将其定义为originValue；

首先更新本地缓存，将上一步的cacheTrigger数据中的最大编号更新到本地缓存，若发生异常，直接跳出循环，进入下一个循环；若未发生异常，则更新redis数据，若发生异常将本地缓存的值替换成originValue，并跳出当前循环；若未发生异常，则通过启动完成的监听器来发送消息。

较佳的，步骤S4具体包括：

每个服务都实现了接收消息的接口，按照程序启动时监听器中注册的“监听对象”的类型来实现消息的监听，从而对消息进行处理。

本发明所提供的一种集装箱码头跨服务信息通信和数据同步方法，能够替代各个服务中的消息中间件，并且能够保证服务间通信的准确性和及时性。同时还降低了不同系统间的耦合依赖，且能够保证跨服务的信息通信的及时性及准确性，从而替代消息中间件。

附图说明

图1是本发明集装箱码头跨服务信息通信和数据同步方法的流程示意图；

图2是本发明集装箱码头跨服务信息通信和数据同步方法的原理示意图。

具体实施方式

为了能更好地理解本发明的上述技术方案，下面结合附图和实施例进一步说明本发明的技术方案。

本发明所提供的一种集装箱码头跨服务信息通信和数据同步方法：

在每个服务中均内嵌一个监听器；

在每个服务中均内嵌一个可配置的定时任务；

在每个服务中均设置统一的接口，用于监听发送过来的事件；

统一每个服务的管理事件的发送时机；

将服务操作、redi s数据、本地缓存、本地磁盘数据预数据库进行同步。

结合图1和图2所示，本发明中将服务操作、redi s数据、本地缓存、本地磁盘数据预数据库进行同步具体包括以下步骤：

S1、在前端系统触发数据变动的操作后，由服务统一对变化的数据进行处理，将处理好的数据保存至“事件日志”表中；

S2、定时任务根据设定时间执行一次，查询“事件日志”表中的数据变化，在读取数据后，先将本地缓存中的编号与redis数据中相应的对象编号进行对比，二者取其大；然后再与刚读取的数据编号进行对比，若刚读取的数据编号小，则不作操作，若刚读取的数据编号大，则将读取的数据进行处理；

S3、将读取的数据进行格式转换后保存至“事件日志”表中，并先修改本地缓存，再修改redis数据缓存，最后将数据发送出去；

S4、订阅了相关“事件对象”的服务接收数据，进行相应的处理。

上述步骤S1具体包括：

在前端系统进行操作时，对应的服务会产生数据变化，在操作完成后对变化的数据进行处理、格式转换，调用公共的接口将处理好的数据保存至“事件日志”表中。

数据在保存前还需进行二次处理和筛查：

遍历数据，每个“监听对象”数据均需对应“事件日志”表中的多条trigger数据，先判断trigger数据和“监听对象”数据是否为空，若二者满足一个为空，则直接跳过，进入下一个循环；若都不为空，则将trigger数据进行格式转换，存入“事件日志”表中。

上述步骤S2中，每个服务的定时任务轮询的数据类型均是根据程序启动时读取的“监听对象”来确定；

为保证服务在集群化部署的情况下相同的服务同一时间只有一个定时任务能读取数据，采用redis分布式锁的方式，并且为了防止死锁或者数据写入过程成锁失效的问题，还采用了lua脚本的形式来给定时任务加锁、解锁、续期；即

若分布式锁存在，则本次定时任务不执行；若分布式锁不存在，判断“监听对象”的集合是否为空，若为空则本次定时任务不执行；若不为空，查询“监听对象”的集合是否在数据库中存在，若全部都不存在，则本次定时任务不执行；若部分存在，则删除不存在的“监听对象”后执行本次定时任务；若全部存在，执行本次定时任务，遍历“监听对象”，在“事件日志”表中查询出配置的小时内关于该对象的所有trigger数据。

上述步骤S3具体包括：

遍历跳表，取出本地缓存中的值，将其定义为originValue；

首先更新本地缓存，将上一步的cacheTrigger数据中的最大编号更新到本地缓存，若发生异常，直接跳出循环，进入下一个循环；若未发生异常，则更新redis数据，若发生异常将本地缓存的值替换成originValue，并跳出当前循环；若未发生异常，则通过启动完成的监听器来发送消息。

上述步骤S4具体包括：

每个服务都实现了接收消息的接口，按照程序启动时监听器中注册的“监听对象”的类型来实现消息的监听，从而对消息进行处理。

实施例

继续参考图1和图2所示，本实施例集装箱码头跨服务信息通信和数据同步方法，具体包括以下步骤：

S1、通过前端系统(C端)用户对码头的箱子或者进出闸等进行操作时，对应的服务会产生数据变化(参见图2中A)，在操作完成后程序会统一的对变化的数据进行处理、格式转换等，调用公共的接口将处理好的数据保存到“事件日志”表中，在入库前也需要将数据进行二次处理和筛查，因C端的每一次操作都可能产生多条数据变化，因此需要将多条数据遍历入库，具体操作如下：遍历数据，每一个“监听对象”都对应“事件日志”表中的多条数据(trigger)，因此先判断trigger数据和“监听对象”数据是否为空，若二者满足一个为空，则直接跳过，进入下一个循环；若都不为空，则将trigger数据进行格式转换，存入“事件日志”表中(参见图2中B)。

S2、定时任务会根据配置的时间对“事件日志”表进行轮询，每个服务的定时任务轮询的数据类型都是根据程序启动时读取的“监听对象”来确定。为保证服务在集群化部署的情况下相同的服务同一时间只有一个定时任务能读取数据，因此引入了redi s分布式锁的方式，并且为了防止死锁或者数据写入过程成锁失效的问题，采用了lua脚本的形式来给定时任务加锁、解锁、续期。若分布式锁存在，则本次定时任务不执行；若分布式锁不存在，判断“监听对象”的集合是否为空，若为空则本次定时任务不执行；若不为空，查询“监听对象”的集合是否在数据库中存在，若全部都不存在，则本次定时任务不执行；若部分存在，则删除不存在的“监听对象”后执行本次定时任务；若全部存在，执行本次定时任务，遍历“监听对象”，在“事件日志”表中查询出一个小时内(时间间隔可配置)关于该对象的所有数据(trigger)(参见图2中C)。

遍历上述数据(trigger)，根据对应的“监听对象”的ID，同时在redis中和本地缓存取出该对象的编号，比较二者大小取其大，将其定义为cacheKey，在遍历的过程中按“监听对象”的类型区分，分别取出所有编号大于cacheKey的trigger数据,将该数据定义为cacheTrigger(参见图2中D)。遍历上述数据(cacheTrigger)，将每一条数据进行处理、格式转换，并将处理完的数据插入跳表中(为保证数据的有序性，选择使用跳表)。

S3、在准备好上述跳表数据后，开始进行数据的更新和发送。遍历跳表，取出本地缓存中的值，将其定义为originValue。首先更新本地缓存，将上一步的数据cacheTrigger中的最大编号更新到本地缓存，若发生异常，直接跳出循环，进入下一个循环，保证数据的正确性(参见图2中E)；若未发生异常，则与上同理更新redi s的数据(参见图2中F)，若发生异常将本地缓存的值替换成originValue，并跳出当前循环，确保本地缓存数据的正确性；若未发生异常，则通过启动完成的监听器来发送消息(参见图2中G)。

S4、每个服务都实现了接收消息的接口，按照程序启动时监听器中注册的“监听对象”的类型来实现消息的监听,从而对消息进行处理(参见图2中H)。

综上所述，本发明降低了不同系统间的耦合依赖，且能够保证跨服务的信息通信的及时性及准确性，从而替代消息中间件。

本技术领域中的普通技术人员应当认识到，以上的实施例仅是用来说明本发明，而并非用作为对本发明的限定，只要在本发明的实质精神范围内，对以上所述实施例的变化、变型都将落在本发明的权利要求书范围内。