CN115209360A - 基于对象的聚合容器数据传输方法和装置 - Google Patents

Abstract

本发明公开了一种基于对象的聚合容器数据传输方法，包括如下步骤：(1)对业务对象进行拆分，基于业务对象产生多种消息类型，将消息与产生该消息的业务对象关联起来；(2)当业务对象状态发生变化的时候，调用对象聚合容器OAC的包装接口，将该业务对象包装进OAC中，对变化的OAC进行调度处理，所述调度处理包括发送和接收。本发明提供了一种基于对象的聚合容器数据传输方法，采用方式二至少投递一次的通信策略可以让业务模块感知到类似方式三的投递效果，并且避免了缓存的开销，使得整个系统完全自适应式的响应网络中的任何事件变化，让CPU及其内存消耗都保持在稳定且合理的状态中。本发明还公开了相应的基于对象的聚合容器数据传输装置。

Description

基于对象的聚合容器数据传输方法和装置

技术领域

本发明属于数据通信技术领域，更具体地，涉及一种基于对象的聚合容器数据传输方法和装置。

背景技术

站在某个组件的角度，当它需要与其它组件进行通信的时候，一般涉及两种通信方式，一种是点对点通信，另外一种是点对多点通信。点对多点的通信方式可以看成多个点对点通信的特殊形式，或者一种组播的通信方式。无论是哪种通信方式，消息投递方式一般有以下几种策略。

①最多一次：这种方式下，消息发送端仅发送一次，不管对方是否接收成功，绝对不会重复发送。

②至少一次：这种方式下，消息发送端设置一个最大重传次数，在发送消息后如果固定时间内没有收到对方回应则重传该消息，超过重传次数后停止发送。

③正好一次：这种方式下，消息发送端仅发送一次，且消息接收端仅消费一次。

方式三从理论上来说是不现实的，所以一般在工程实际应用中都采用方式一或者方式二。而对于通信技术领域，方式一属于不可靠消息传递，一般是不会采纳的，为了尽可能的保证消息的可靠投递，使用最多则是方式二。除此之外，消息接收端接收消息的顺序需要与消息发送端的发送顺序保持一致，例如消息发送端的序列是M1、M2、M3，那么消息接收端的顺序也必须是M1、M2、M3。

当采用方式二进行消息投递的时候，实际还面临另外一个问题，当消息发送方因为某个事件的频繁变化触发了某种类型的消息不断通告。如果消息接收方因为种种原因没有来得及处理该消息，或者处理了该消息的响应信息没有能够及时传递到消息发送方，消息发送方由于要采取重传机制，必须缓存每一次变化的消息，当超出缓存空间大小后，后续产生的消息则无法再投递。除此之外，在业务实际处理过程中，存在某些具有事务特性的消息集，如果能实现以事务的原子性的处理方式对消息进行批处理，则可以大幅度提高整体处理性能。

发明内容

针对现有技术的以上缺陷或改进需求，本发明提供了一种基于对象的聚合容器数据传输方法，让系统能够完全自适应式的响应网络中的任何事件变化，并且让CPU及其内存消耗都保持在稳定且合理的状态中。

为实现上述目的，按照本发明的一个方面，提供了一种基于对象的聚合容器数据传输方法，包括如下步骤：

(1)对业务对象进行拆分，基于业务对象产生多种消息类型，将消息与产生该消息的业务对象关联起来；

(2)当业务对象状态发生变化的时候，调用对象聚合容器OAC的包装接口，将该业务对象包装进OAC中，对变化的OAC进行调度处理，所述调度处理包括发送和接收。

本发明的一个实施例中，OAC变化链上维护两个指向OAC的游标对象，一个是OAC变化游标CCC，另外一个是OAC同步游标CSC，CCC表明当前需要进行发送处理的OAC，CSC表明消息接收端已同步处理的OAC，每个游标对象由两个值组成，一个是容器ID(CID)，另外一个是对象索引OID，CID+OID唯一标识某个OAC内的某个业务对象。

本发明的一个实施例中，消息由两部分组组成，一部分是控制消息，另外一部分是业务消息，业务消息是由业务模块向消息处理模块注册相应的回调接口进行构造，控制消息则是消息处理模块在调用业务对象状态转换为消息的回调接口前写入的，控制消息中除了填写具体实现必须的字段之外，还需要将标识OAC内某个具体业务对象的CID+OID写入。

本发明的一个实施例中，所述步骤(2)中发送处理包括：发送方按照OAC变化的时间顺序逐一访问各个OAC，对包装进该OAC的各个业务对象进行处理，将业务对象当前状态转换为消息，投递到消息传递通道上进行真正发送。

本发明的一个实施例中，所述步骤(2)中接收处理包括：接收方在收到具体某个消息的时候，首先取出控制消息中的CID+OID，根据CID查找本地的OAC是否存在，如果不存在则根据CID创建新的OAC；然后调用业务的消息接收处理函数，业务在消息处理函数中根据业务消息的key查找到已经存在的业务对象或者基于key创建新的业务对象，业务对象创建完成后，再调用本地OAC关联接口将业务对象与控制消息中的CID+OID关联，即将业务对象包装进本地OAC中。

本发明的一个实施例中，在消息发送端，通过CID+OID的索引方式将业务对象与消息关联起来，当业务对象状态发生变化后，如果存在原有关联的CID+OID，先进行解除关联，然后再关联新的CID+OID；消息发送过程中将关联当前业务对象的最新CID+OID填入控制消息中随着业务消息一起投递到消息接收端；消息接收端在根据业务消息匹配到本地业务对象后再调用本地OAC关联接口将业务对象与控制消息中携带的CID+OID关联起来。

本发明的一个实施例中，还包括变化同步与整体同步：消息发送端将数据同步到消息接收端，分为变化同步与整体同步，消息发送端和消息接收端都处于正常在线的情况下，当有对象状态发生变化的时候，这种同步方式称为变化同步，消息发送端和消息接收端当任意一方掉线后重新上线的情况下，这种同步方式为整体同步。

本发明的一个实施例中，消息发送端在掉线后重新上线的情况下基于掉电前的[CID:OID]递增，对掉电前的[CID:OID]进行持久化处理，重新上线后从磁盘恢复掉电前的[CID:OID]。

本发明的一个实施例中，所述步骤(1)中将消息与产生该消息的业务对象关联起来，包括：在业务对象指定内存大小的基础上增加4个字节用于存储CID+OID，对现有内存分配及其释放接口进行封装，新接口为OAC对象内存分配接口和OAC对象内存释放接口；申请内存的新接口中，如果业务传入的内存大小为N个字节，实际内部分配为N+4个字节，返回业务对象内存地址为实际分配的内存地址正向偏移4个字节；释放内存的新接口中，业务传入的内存地址需要负向偏移4个字节找到实际的内存首地址，然后再进行释放。

按照本发明的另一方面，还提供了一种基于对象的聚合容器数据传输装置，包括至少一个处理器和存储器，所述至少一个处理器和存储器之间通过数据总线连接，所述存储器存储能被所述至少一个处理器执行的指令，所述指令在被所述处理器执行后，用于完成上述的基于对象的聚合容器数据传输方法。

总体而言，通过本发明所构思的以上技术方案与现有技术相比，具有如下有益效果：

本发明提供了一种基于对象的聚合容器数据传输方法，采用方式二至少投递一次的通信策略可以让业务模块感知到类似方式三的投递效果，并且避免了缓存的开销，使得整个系统完全自适应式的响应网络中的任何事件变化，让CPU及其内存消耗都保持在稳定且合理的状态中。

附图说明

图1是本发明实施例中基于对象的聚合容器数据传输方法的流程示意图；

图2是本发明实施例中业务对象内存地址改造示意图；

图3是本发明实施例中新业务对象包装进OAC示意图；

图4是本发明实施例中新业务对象从源端同步到目的端示意图；

图5是本发明实施例中业务对象更新后从源端同步到目的端示意图；

图6是本发明实施例中业务对象删除后从源端同步到目的端示意图；

图7是本发明实施例中数据老化流程示意图；

图8是本发明实施例中OAC空洞场景示意图；

图9是本发明实施例中OAC空洞处理示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。

本发明是一种基于对象的聚合容器数据传输技术，为此定义了以下技术术语。

BDO:Business Data Object，业务对象。

BDS:Business Data Source，业务数据源端。

BDT:Business Data Target，业务数据目的端。

OAC:Object Aggregated Container，对象聚合容器。

OACC:OACClass，对象聚合容器类。

CID:ContainerIdentification，容器ID。

OID:Object Index，对象索引。

CCL:Container Change List，容器变化链表。

CCC:Container Change Cursor，容器变化游标。

CSC:Container Synchronous Cursor，容器同步游标。

EOS:End Of Synchronous，同步结束标记。

同时为了更好的描述本发明内容，引用了以下专业术语。

ACL:Access Control List，访问控制列表。

LSP:LabelSwitchPath，标签交换路径

如图1所示，本发明提供了一种基于对象的聚合容器数据传输方法，包括：

(1)对业务对象进行拆分，基于业务对象产生多种消息类型，将消息与产生该消息的业务对象关联起来；

(2)当业务对象状态发生变化的时候，调用对象聚合容器OAC的包装接口，将该业务对象包装进OAC中，对变化的OAC进行调度处理，所述调度处理包括发送和接收。

本发明基于对象的聚合容器数据传输技术可以分解为四方面内容，分别是基于对象、对象聚合容器、数据可靠传输以及变化同步与整体同步。四个方面构成整个系统，缺一不可，下面对此简要说明。

(1)基于对象

现在的市面上有大量的消息中间件技术，广泛应用于各种互联网的应用场景中，它们的技术基础无一例外的都是消息队列(Message Queue，MQ)。作为一种中间件技术，为了具备广泛的适用性并且与具体业务解耦，它的消息与产生该消息的具体业务逻辑实质上是完全独立的。这在服务器或者桌面系统的环境中没有什么太大的问题，因为这些环境受限于CPU和内存的资源相对较少，即使出现单机的资源瓶颈问题，也可以通过分布式或者集群的方式进行水平扩展。但是对于嵌入式环境的底层通信技术领域，由于受制于单机CPU及其内存资源的限制，在具体的通信设备产品中都会明确本产品支持的各种业务最大上限规格。例如最大的接口数量，最大的ACL(Access Control List，访问控制列表)表项，最大的LSP(LSP:LabelSwitchPath，标签交换路径)数目，最大的路由表条目数等。因此，与消息中间件消息与业务完全解耦的技术路径相反，需要将消息与业务进行适当的耦合，将消息与产生该消息的业务对象关联起来。一个业务对象只能产生特定的一种消息类型，如果要产生多种消息类型，建议对业务对象进行拆分。

(2)对象聚合容器

一般情况下，当某个业务对象的状态发生变化后会立即将该状态信息以消息的形式发送到其它组件，当该业务对象状态再次发生变化的时候会重复上面的过程，如此反复。当业务对象与消息类型关联起来后，业务对象本身的状态变化会触发新的消息通告，但是如果业务对象在极短时间状态变化很快，那么理想状态是仅仅通告当前最新状态即可，前面的状态消息都可以忽略。例如某个接口状态变化为的时间序列为UP、DOWN、UP、DOWN，产生的消息序列为M1(UP)、M2(DOWN)、M3(UP)、M4(DOWN)。如果M1(UP)的消息还没有发送，那么M2(DOWN)的消息可以替换掉M1(UP)，以此类推，最后仅仅发送M4(DOWN)。

为了满足上述要求，本技术引入了对象聚合容器OAC，将一系列需要将状态转换为消息的业务对象都包装进OAC中。当业务对象状态发生变化的时候，调用OAC的包装接口，将该业务对象包装进OAC中。对象聚合容器类OACC会首先查看当前拥有最大CID的OAC内是否还有剩余的空间可以包装该业务对象，如果有则将业务对象包装进去，如果没有则分配一个新的OAC，该OAC的CID在当前最大的CID基础上递增(每个OAC有一个CID，CID是单调递增的，新创建的OAC在原来的最大CID基础上+1)，再把该业务对象包装进新的OAC中。可以看到一个OAC可以包装多个业务对象，OAC具体可以包装多少个业务对象，可以根据实际的业务场景动态调整。

(3)可靠传输技术

当消息源端一个业务对象的状态发生变化，需要转换为表示业务对象状态的具体消息发送到消息接收端。这里实际面临以下几个具体的问题，消息具体什么时候发送，发送的时候如何保证消息能够迅速投递到接收端，如何确认当前消息已经被接收端处理，如何保证接收端处理消息的顺序与发送端发送消息顺序保持一致，下面将逐一进行分析。

当业务对象状态发生变化的时候，一般的处理方式是将状态转换为消息，并调用消息发送接口立即发送。这种方式使用起来较为简单，但是面临较大的不确定性，例如消息接收端目前可能并不在线，消息发送端的缓存空间超限等问题。业务要针对上述的各种不确定性场景进行特殊处理，无疑增加了业务处理逻辑的复杂性。因此，这里采用了一种异步的处理方法，当业务对象状态发生变化的时候，并不直接转换为消息调用接口进行发送，而是触发一个业务状态变化的事件，具体来说就是调用OAC的包装接口，将该业务对象包装进OAC中，最后由消息处理模块主调度程序对变化的OAC进行调度处理。

消息处理模块发送方调度程序按照OAC变化的时间顺序逐一访问各个OAC，对包装进该OAC的各个业务对象进行处理。具体来说就是将业务对象当前状态转换为消息，投递到消息传递通道上进行真正发送。消息处理模块在OAC变化链上维护了两个指向OAC的游标对象，一个是OAC变化游标CCC，另外一个是OAC同步游标CSC。CCC表明当前需要进行发送处理的OAC，CSC表明消息接收端已同步处理的OAC。每个游标对象由两个值组成，一个是容器ID(CID)，另外一个是对象索引OID，CID+OID唯一标识某个OAC内的某个业务对象。

消息处理模块具体转换的消息由两部分组组成，一部分是控制消息，另外一部分是业务消息。业务消息是由业务模块向消息处理模块注册相应的回调接口进行构造，而控制消息则是消息处理模块在调用业务对象状态转换为消息的回调接口前写入的。控制消息中除了填写具体实现必须的字段之外，重要的是需要将标识OAC内某个具体业务对象的CID+OID写入。

消息处理模块的接收方在收到具体某个消息的时候，首先取出控制消息中的CID+OID，根据CID查找本地的OAC是否存在，如果不存在则根据CID创建新的OAC。然后调用业务的消息接收处理函数，业务在消息处理函数中会根据业务消息的key查找到已经存在的业务对象或者基于key创建新的业务对象，业务对象创建完成后，再调用本地OAC关联接口将业务对象与控制消息中的CID+OID关联，即将业务对象包装进本地OAC中。

上述处理的过程简要介绍：

在消息发送端，通过CID+OID的索引方式将业务对象与消息关联起来，当业务对象状态发生变化后，如果存在原有关联的CID+OID，先进行解除关联，然后再关联新的CID+OID。消息发送过程中将关联当前业务对象的最新CID+OID填入控制消息中随着业务消息一起投递到消息接收端。消息接收端在根据业务消息匹配到本地业务对象后再调用本地OAC关联接口将业务对象与控制消息中携带的CID+OID关联起来。经过以上的处理过程，消息发送端的业务对象状态与消息接收端的业务对象状态就完全一致且紧密关联。

消息保序处理过程简要介绍：

消息发送端发送消息的顺序是按照[CID:OID]的形式单调递增的，[m:n]代表第m个OAC中第n个业务对象。假设每个OAC可包装的业务对象数目最大为N，从OAC为m1开始发送，那么可以形成以下的发送顺序[m1:0]、[m1:1]…[m1:N-1]、[m2:0]、[m2:1]…[m2:n]一定是满足条件的严格单调递增形式，消息处理模块应该以上述相同的严格单调递增的序列接收消息。消息接收方会判断消息的连续性向发送方进行正常的确认消息(Acknowledge，ACK)，或者ACK的重传消息(ReSend)。正常的ACK又分为两种情况，立即ACK及其延迟ACK。当接收到一个完整的OAC消息发送立即ACK，当本轮调度接收的最后一个消息处于OAC中间的时候，进行延迟ACK。例如当连续接收到消息[m1:0]…[m1:N-1]后进行立即ACK，ACK内容为最后一个消息的[CID:OID]，这里是[m1:N-1]。如果继续接收消息[m1:0]…[m2:N-1]，仍然进行立即ACK，内容是[m2:N-1]。如果继续接收消息[m3:0]…[m3:n]。[m3:n]已经是当前处理的最后一个消息了，但是n并不等于N-1，那么启动延时回复定时器，定时器超时后进行延时ACK，ACK内容是[m3:n]。当超时定时器没有结束前又继续接收到了后续的[m3:n+1]、[m3:n+2]，则立即取消延迟回复定时器，进行立即ACK，ACK内容为[m3:n+2]。假设消息接收端接收到了[m3:n+2]，而不是预期的[m3:n+1]，取消超时ACK定时器，并立即回复ACK(ReSend)，内容为[m3:n]，要求消息发送端对[m3:n]后面的消息进行重传。立即ACK一定是[*:N-1]的形式，表明一个完整的OAC报文均正常按序列接收，反之则不一定。

消息从发送端到接收端通过ACK进行确认消息是否投递成功，而从消息接收端到消息发送端的ACK不会再由发送端回应消息确认是否投递成功，如果这样做那么整个消息就会不断反复无法终结了。但是从消息接收端到消息发送端的ACK实际也有可能会丢失，这里采用一种简单的处理方式，ACK消息发送之后就不再关注了。消息接收端设置一个当前已发送但未确认的OAC数目，假设默认值为M，由于每个OAC内包装的对象数据的默认值是N，那么未确认的对象数据则为M*N条。假设当前消息接收端回复确认的ACK为[m+3:N-1]，而消息发送端收到的确认的ACK为[m:N-1]，那么消息发送端可以发送到最大位置则是[m+M:N-1]，到达该位置后将停止发送，并且启动重传定时器。重传定时器超时后从上一次确认的ACK位置进行重新发送。这里重新从[m+1:0]开始发送，消息接收端会重复接收已经收到且回复ACK的消息(ACK丢失了)，这种情况下，消息接收端不会再将该此消息投递给业务模块，而是直接忽略该消息，并且立刻回复上一次返回的ACK消息，这里可能是[m+3:N-1]。当消息发送端接收到该消息后，可以确认从[m+1:0]到[m+3:N-1]这部分消息实际已经被消息接收端处理了，但是重传仍然需要保持单调递增的流程，但是在后续的消息中仅仅携带消息头，而不携带具体的消息体(因为消息接收端判断重复并不会投递给业务模块进行处理)，这样可以降低通道的资源开销，同时保证整个流程的连续性。

(4)变化同步与整体同步

消息发送端将数据同步到消息接收端，可以分为变化同步与整体同步两大类场景。消息发送端和消息接收端都处于正常在线的情况下，当有对象状态发生变化的时候，这种同步方式称为变化同步。消息发送端和消息接收端当任意一方掉线后重新上线的情况下，这种同步方式为整体同步。为了保证对象消息的严格保序性，消息发送端在掉线后重新上线的情况下可以基于掉电前的[CID:OID]递增，因此需要对掉电前的[CID:OID]进行持久化处理，重新上线后从磁盘恢复掉电前的[CID:OID]。

以下具体说明本发明技术方案的实施过程：

业务对象内存改造

需要将业务对象与具体的消息关联起来，对原有的业务对象内存进行简单改造。如图2所示，将原有的业务对象的内存进行简单改造，在业务对象指定内存大小的基础上增加4个字节用于存储CID+OID。为了达到上述的目的，需要对现有内存分配及其释放接口进行封装，新接口为OAC对象内存分配接口和OAC对象内存释放接口，申请内存的新接口中，如果业务传入的内存大小为N个字节，实际内部分配为N+4个字节，返回业务对象内存地址为实际分配的内存地址正向偏移4个字节。释放内存的新接口中，业务传入的内存地址需要负向偏移4个字节找到实际的内存首地址，然后再进行释放。

消息发送端新增业务对象处理流程

如图3所示，总共有9个业务对象，3个OAC，CID分别为1～3，每个OAC的大小为4，其中业务对象1～8被包装进了CID1及其CID2的OAC中，CID1和CID2的OAC都处于饱和状态。对象9包装进了新的CID3的OAC，该OAC还剩下3个对象位置，目前处于不饱和状态。当业务对象使用OAC的内存分配接口申请内存后，CID+OID默认为0，表示当前对象没有包装进任何OAC中，将对象包装进OAC后，该业务对象所在的OAC位置CID+OID会自动填写到内存头的前4个字节中。当业务对象包装进OAC后就表示该业务对象需要进行一次对象状态数据同步，如图4所示，表示业务对象1～4从业务数据源端发送到业务数据目的端的示意图。需要注意的是，将对象包装进OAC与将OAC中的对象转换为消息发送到远端是在各自独立的调度中完成的。

消息接收端新增业务对象处理流程

业务对象的目的端在接收到CID+OID为[m:n]的消息的时候，由于[m:n]并没有携带上一次的CID+OID信息，属于全新的业务对象消息，于是该消息直接投递给具体的业务进行处理，业务模块根据消息内容中的关键字在模块内数据结构中进行查找，没有找到则调用OAC的内存分配接口申请新的本地业务对象数据内存。然后调用OAC业务对象关联接口将本地业务对象与接收到的CID+OID关联起来。该过程类似于消息发送端将业务对象包装进OAC更新CID+OID的处理流程。至此，源端的业务对象与目的端的业务对象的CID+OID则完全保持一致。

消息发送端更新业务对象处理流程

如图5所示，业务对象1已经投递到目的端了，此时对象1的数据状态发生了变化，需要同步更新状态到目的端，为了保证所有对象变化的严格保序性，业务对象进行了一次新的OAC包装。对象内存的前4个字节的CID+OID字段并不是固定不变的，每次业务对象状态发生变化，需要进行数据传输的时候，会从原有OAC中移除，包装进新的OAC中，从而将对象内存头的CID+OID更新为新OAC的位置。OAC2中还需要记录当前[2:3]位置的对象的上一次OAC位置[1:0]，在消息传输的时候在消息头中除了携带当前CID+OID[2:3]之外，同时携带上一次CID+OID[1:0]，用于在目的端实现快速查找业务对象数据。

业务对象的目的端在接收到CID+OID为[2:3]的消息的时候，由于[2:3]携带了上一次的CID+OID信息[1:0]，属于业务对象更新消息，消息处理模块根据[1:0]进行本地快速查找数据于是该消息直接投递给具体的业务进行处理，业务模块根据消息内容中的关键字在OAC中快速查找业务对象，找到后将本次消息内容及其业务对象指针传递给具体的业务模块，业务模块可以根据对象指针中的业务关键字与消息中的业务关键字进行匹配是否一致，如果不一致则业务模块重新根据消息中的业务关键字在模块内数据结构中进行查找，找到正确的本地业务对象后，然后调用OAC业务对象关联接口将本地业务对象与接收到的新的CID+OID关联起来。

消息发送端删除业务对象处理流程

如图6所示，业务对象的删除流程与业务对象更新流程基本是一致的，都需要将业务对象从原有OAC移动到新OAC中。区别在于，业务对象删除的时候由于对象内存已经释放，仅仅在新OAC中记录了该业务对象的上一次OAC位置，同时在消息发送的时候只有消息头，没有消息体，表明这是一次业务对象的删除消息。消息处理模块直接根据消息头中的上一次的CID+OID在OAC中进行快速查找，找到相应的本地业务对象后，调用业务删除函数并传递该业务对象指针进行处理。

数据老化流程

数据老化是针对数据源端重启或者永久下线的情况下，数据目的端需要将从数据源端接收的数据进行更新和删除的处理过程。

如图7所示，数据源端重启前，数据目的端有12个对象数据，分布在3个OAC中，CID分别为1～3。当数据源端重启后，数据源重新同步了新的数据对象，其中数据对象3，8，9三个对象没有更新，同时新增了对象13，更新和新增的对象重新部署在新的OAC中，CID为4～6，因此需要对原有OAC中的3，8，9三个对象进行老化处理。

数据老化处理流程中，有两个关键处理点，第一个是确定原数据与新数据的边界，第二个是正式执行老化处理的时间点。新旧数据的边界由数据目的端在检测到数据源端下线的最大CID+OID确定，当检测到数据源端下线的时候，(*，CID+OID]区间为旧的数据，(CID+OID，*)区间为新的数据。执行老化处理的时间点需要由数据源端进行协助，当数据源端同步完所有的数据后，需要一个特殊的空数据节点EOS标识数据同步已完成，数据接收端收到EOS标记后，立即对(*，CID+OID]区间中的数据对象进行删除处理。

数据重新同步流程

数据重新同步流程是针对数据目的端下线后重新上线的情况下，数据源端需要将所有已经同步的OAC对象重新发送到数据目的端的处理过程。数据源端针对每个目的端维护了两个游标，分别是CCC及其CSC，当数据源端检测到数据目的端下线后，CCC及其CSC均保持当前指向状态不再发生变化。当数据源端检测到数据目的端重新上线后，则重置CCC及其CSC到OAC链表的头部，重新对所有OAC对象进行数据同步处理。

OAC空洞处理流程

数据源端在对象数据同步过程中，由于对象删除或者更新都会迁移到新的OAC中，因此会出现部分OAC存在不饱和的状态，如图8所示。不饱和状态本身对功能没有任何影响，但是会消耗掉部分内存资源，OAC利用率不高。解决这种情况的办法是在后台周期性的对OAC变化链进行扫描，当某个OAC的利用率低于某个阈值的时候，对OAC内有效对象显式触发一次伪更新。

正常的对象更新会将对象移动到最新的OAC中将对象的控制数据及其状态信息同步更新到目的端。伪更新与上述更新流程是一致的，区别在于伪更新仅同步对象的控制数据，而不更新对象状态，这种处理方式对业务是透明的，由整个消息处理系统完成，不会造成业务对系统资源的不必要消耗。如图9所示，基于50％的阈值规则，CID1、CID2和CID4的空洞需要处理，处理完成后由4个OAC压缩为3个OAC，从而降低了OAC的资源消耗。

点对多点组播处理流程

点对多点的组播处理流程和点对点的整体流程是保持一致的，数据源端对每个目的端维护了CCC及其CSC两个游标。假设总共有N个目的端，每个目的端的游标为CCC[n]，CSC[n]，总共有2N个游标，其中n代表其中一个目的端，其它所有数据处理流程和单播流程完全一致。

原子消息集合处理流程

数据库事务中有一个关键特性叫原子性，它表示在数据库的操作过程中，事务中的操作要么全做，要么全不做。实际业务的处理逻辑中也会存在大量的这种情况，在传统的消息处理系统中，业务对每条消息的响应方式都是独立的，假设消息N需要经过某几个处理步骤，那么消息N+1也需要经过与消息N相同的处理步骤。这种处理看似合乎逻辑，但是性能会受到较大影响。如果这些相同的处理步骤中可以同时处理多条消息，那么整体性能必然会有较大的提升。

原子消息集合处理实现了类似事务的原子性特点，消息发送端将一系列具有相关关系的对象变化打包在一个较大的OAC中，整个OAC就是一个事务的包装。消息发送端首先创建一个事务OAC，然后将该事务包含的对象逐一包装到该OAC中，所有对象包装完成后，开始发起事务消息集同步，消息处理系统会将整个OAC的对象状态作为一个整体消息发送到消息接收端。消息接收端首先会收到一个事务开始的控制消息，然后才是业务对象状态变化消息，最后才是事务结束的控制消息。消息接收端识别到这是一个事务消息集的时候，不再独立处理每一条消息，而是在收到事务结束后再集中进行统一处理。

进一步地，本发明还提供一种基于对象的聚合容器数据传输装置，包括至少一个处理器和存储器，所述至少一个处理器和存储器之间通过数据总线连接，所述存储器存储能被所述至少一个处理器执行的指令，所述指令在被所述处理器执行后，用于完成上述基于对象的聚合容器数据传输方法。

本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于对象的聚合容器数据传输方法，其特征在于，包括如下步骤：

(1)对业务对象进行拆分，基于业务对象产生多种消息类型，将消息与产生该消息的业务对象关联起来；

(2)当业务对象状态发生变化的时候，调用对象聚合容器OAC的包装接口，将该业务对象包装进OAC中，对变化的OAC进行调度处理，所述调度处理包括发送和接收。

2.如权利要求2所述的基于对象的聚合容器数据传输方法，其特征在于，OAC变化链上维护两个指向OAC的游标对象，一个是OAC变化游标CCC，另外一个是OAC同步游标CSC，CCC表明当前需要进行发送处理的OAC，CSC表明消息接收端已同步处理的OAC，每个游标对象由两个值组成，一个是容器ID(CID)，另外一个是对象索引OID，CID+OID唯一标识某个OAC内的某个业务对象。

3.如权利要求2所述的基于对象的聚合容器数据传输方法，其特征在于，消息由两部分组组成，一部分是控制消息，另外一部分是业务消息，业务消息是由业务模块向消息处理模块注册相应的回调接口进行构造，控制消息则是消息处理模块在调用业务对象状态转换为消息的回调接口前写入的，控制消息中除了填写具体实现必须的字段之外，还需要将标识OAC内某个具体业务对象的CID+OID写入。

4.如权利要求2或3所述的基于对象的聚合容器数据传输方法，其特征在于，所述步骤(2)中发送处理包括：

发送方按照OAC变化的时间顺序逐一访问各个OAC，对包装进该OAC的各个业务对象进行处理，将业务对象当前状态转换为消息，投递到消息传递通道上进行真正发送。

5.如权利要求2或3所述的基于对象的聚合容器数据传输方法，其特征在于，所述步骤(2)中接收处理包括：

接收方在收到具体某个消息的时候，首先取出控制消息中的CID+OID，根据CID查找本地的OAC是否存在，如果不存在则根据CID创建新的OAC；然后调用业务的消息接收处理函数，业务在消息处理函数中根据业务消息的key查找到已经存在的业务对象或者基于key创建新的业务对象，业务对象创建完成后，再调用本地OAC关联接口将业务对象与控制消息中的CID+OID关联，即将业务对象包装进本地OAC中。

6.如权利要求2或3所述的基于对象的聚合容器数据传输方法，其特征在于，在消息发送端，通过CID+OID的索引方式将业务对象与消息关联起来，当业务对象状态发生变化后，如果存在原有关联的CID+OID，先进行解除关联，然后再关联新的CID+OID；消息发送过程中将关联当前业务对象的最新CID+OID填入控制消息中随着业务消息一起投递到消息接收端；消息接收端在根据业务消息匹配到本地业务对象后再调用本地OAC关联接口将业务对象与控制消息中携带的CID+OID关联起来。

7.如权利要求1或2所述的基于对象的聚合容器数据传输方法，其特征在于，还包括变化同步与整体同步：消息发送端将数据同步到消息接收端，分为变化同步与整体同步，消息发送端和消息接收端都处于正常在线的情况下，当有对象状态发生变化的时候，这种同步方式称为变化同步，消息发送端和消息接收端当任意一方掉线后重新上线的情况下，这种同步方式为整体同步。

8.如权利要求7所述的基于对象的聚合容器数据传输方法，其特征在于，消息发送端在掉线后重新上线的情况下基于掉电前的[CID:OID]递增，对掉电前的[CID:OID]进行持久化处理，重新上线后从磁盘恢复掉电前的[CID:OID]。

9.如权利要求2或3所述的基于对象的聚合容器数据传输方法，其特征在于，所述步骤(1)中将消息与产生该消息的业务对象关联起来，包括：

在业务对象指定内存大小的基础上增加4个字节用于存储CID+OID，对现有内存分配及其释放接口进行封装，新接口为OAC对象内存分配接口和OAC对象内存释放接口；申请内存的新接口中，如果业务传入的内存大小为N个字节，实际内部分配为N+4个字节，返回业务对象内存地址为实际分配的内存地址正向偏移4个字节；释放内存的新接口中，业务传入的内存地址需要负向偏移4个字节找到实际的内存首地址，然后再进行释放。

10.一种基于对象的聚合容器数据传输装置，其特征在于：

包括至少一个处理器和存储器，所述至少一个处理器和存储器之间通过数据总线连接，所述存储器存储能被所述至少一个处理器执行的指令，所述指令在被所述处理器执行后，用于完成权利要求1-9中任一项所述的基于对象的聚合容器数据传输方法。

Images