用于分布式应用系统的数据传输系统和数据传输方法

摘要

本发明提供了一种用于分布式应用系统的数据传输系统，包括发送方和接收方，其中，所述发送方包括：数据拆分单元，用于将待发送的业务数据拆分为多个数据消息；消息生成单元，用于生成对应于所述数据消息的控制消息；数据发送单元，用于将所述数据消息和所述控制消息发送至消息中间件，以供接收方进行获取并按照所述控制消息来处理所述数据消息。本发明还提出了一种用于分布式应用系统的数据传输方法。通过本发明的技术方案，可以不依赖于具体的消息中间件，从而实现异步的、松耦合的分布式数据传输，具有良好的可移植性，能够有效降低系统实现的复杂性，尤其是解决了在大数据量和集群环境下的常见内存问题、并发问题。

说明书

技术领域

本发明涉及数据传输技术领域，具体而言，涉及用于分布式应用系统 的数据传输系统和数据传输方法。

背景技术

在分布部署的企业应用系统之间要进行通讯，存在着许多问题，其中 最重要的问题之一是这些软件系统之间由于从属不同企业组织、远距离等 原因而带来在运行状态、网络连接状态的独立性，这种独立性意味着这些 需要互相通讯的系统有可能并不是都同时处于运行状态或者连通状态（比 如停机维护等）。这类企业应用系统间的数据交换通常都具有数据量大、 通讯持续时间长等特点，因而在这样的场景中直接采用传统的面向连接的 通讯方案（如TCP、HTTP）实现企业应用系统间的业务数据交换会面临 很大复杂度和开发风险，因为通讯的双方的部署特性而无法一致地维持着 良好的连接性。

基于发布/订阅模型的消息通讯方案相对于传统的面向连接的通讯方 案，天然地具备了将通讯的发送、接收双方分离的特点，使得发送方和接 收方之间得到解耦：发送方将数据发送到特定的主题而不用管接收方何时 接收；而接收方可在任意合适的时候从其关注的主题中接收数据。

目前，典型的基于发布/订阅模型的消息通讯方案就是采用消息中间 件作为通讯基础设施，然而直接在消息中间件之上进行业务数据通讯仍面 临着诸多困难。消息中间件单一地以消息作为载体与业务数据和业务操作 的多样性之间形成矛盾，这种矛盾产生的问题包括：1、在消息流中区分 业务数据和业务操作的边界的问题；2、大数据量传输的事务问题；3、群 集部署的接收方的接收处理问题。

1、在消息流中区分业务数据和业务操作的边界的问题

典型的消息中间件对于一个消息的大小都是有限制的，一次业务操作 的数据通常都由于数据量大小的问题无法只用一个消息就完成传输，需要 分成多个消息进行。基于消息中间件都需要面临的一个问题就是将业务数 据分解为多个消息发送并能够在接收方重新组合，并且能够区分不同业务 操作发起的同一种业务数据类型的多次传输。这就是所谓业务数据边界和 业务操作边界，即一次业务操作和业务数据与承载了这些信息的多个消息 的对应关系。

在一次通讯过程中，发送方的业务数据会按照消息中间件定义的消息 格式生成一系列的消息并通过消息中间件发送出去，接收方订阅接收到消 息之后需要从大量的消息中重新识别出其中包含的业务数据和对应的业务 操作。

现有的在消息中区分业务数据和业务操作边界的方法就是：

（1）将业务类别标识符加到消息中，发送方在发送数据时，将消息 打上标识，并按顺序发送给消息中间件。

（2）接收方在从中间件订阅收到的每一个消息时根据消息中的标识 符对消息分类进行业务处理。

具体地，如图1所示，用户通过操作A将多个数据消息A1A2A3按 顺序发送至A系统，并通过操作B将多个数据消息B1B2B3按顺序发送 至A系统，然后由A系统按照预定的顺序，如采用A1B1A2B2A3B3将多 个数据消息发送至消息中间件。然后，B系统按照相同的顺序，比如 A1B1A2B2A3B3从消息中间件获取多个数据消息，并按照每个操作对应 的数据消息，分为A1A2A3和B1B2B3后分别用于处理A和处理B。

上述方法依赖于消息中间件的队列中消息顺序的保证，接收方对消息 的处理以顺序接收为前提。这种方式存在以下的限制或问题：

（1）发送方需要保证消息发送顺序而无法并发发送；

（2）接收方的处理以顺序接收为前提而无法支持并发接收处理；

（3）在每一个消息上的都需要加上了描述数据的业务属性以及相关 消息的标识符的业务边界识别方法增大了在网络传输中非业务数据的冗 余。

2、大数据量传输完整性问题

传输完整性是指将一个业务操作数据的多个消息一起发送出去，如果 全部消息都成功，则全部消息一起得到处理时，如果存在失败的消息，则 已经发送的消息最终会被忽略不做处理。

为了保证一次业务操作的数据都能完整地传输，现有的做法是将一次 业务操作的所有数据生成的全部消息都在同一个由消息中间件定义和提供 的事务中发送出去。然而这种依赖于消息中间件事务来保证完整性的方式 会受到内存的限制，如果数据量过大(如GB级以上)将会大量占用内存而 导致消息中间件的崩溃。

3、群集部署的接收方的接收处理问题

在企业应用中，以群集部署应用系统来分担单台服务器压力以提高整 个应用系统的吞吐量和处理能力是很常见的实施方案。在群集部署中，逻 辑上的一个应用系统在物理上是两个以上的运行于同一台服务器或者不同 服务器上的进程，应用系统的处理请求被按照某种特定的规则被均衡地分 配给不同的进程实例来处理。

按照问题1所述的现有的实现方法在群集部署的场景中，由于同一业 务操作的多个消息都可能会在同一个系统的不同进程实例接收并触发业务 处理。如果不加额外的进程间并行处理机制，系统的每一个进程实例都由 于无法收到完整的消息而未能完成业务处理。而要施加额外的进程间并发 控制的机制确带来不小的复杂度，同时也会增加系统实现风险和成本。

因此，需要一种新的数据传输技术，以期解决上述多个问题中的至少 之一。

发明内容

本发明正是基于上述问题，提出了一种新的数据传输技术，可以不依 赖于具体的消息中间件，从而实现异步的、松耦合的分布式数据传输，具 有良好的可移植性，能够有效降低系统实现的复杂性，尤其是解决了在大 数据量和集群环境下的常见内存问题、并发问题。

有鉴于此，本发明提出了一种用于分布式应用系统的数据传输系统， 包括发送方和接收方，其中，所述发送方包括：数据拆分单元，用于将待 发送的业务数据拆分为多个数据消息；消息生成单元，用于生成对应于所 述数据消息的控制消息；数据发送单元，用于将所述数据消息和所述控制 消息发送至消息中间件，以供接收方进行获取并按照所述控制消息来处理 所述数据消息。在该技术方案中，通过控制消息来对数据消息的传输进行 控制，从而脱离了对具体的消息中间件的依赖，有利于降低对系统实现的 复杂性。

在上述技术方案中，优选地，所述发送方还包括：标识添加单元，用 于为每个所述数据消息添加相应的唯一标识；其中，所述控制消息中包含 每个所述数据消息的唯一标识、所述多个数据消息的排列顺序以及对所述 多个数据消息的处理方式。在该技术方案中，通过为每个数据包添加唯一 标识，使得可以根据控制消息中记录的数据包的排列顺序、处理方式等信 息，对数据包进行妥善处理。

在上述技术方案中，优选地，所述数据发送单元采用非事务连接方式 向所述消息中间件发送所述数据消息和所述控制消息。在该技术方案中， 通过采用非事务连接方式进行消息发送，从而避免消息中间件因大数据量 而致内存崩溃，同时也避免对特定的消息中间件产生依赖。

在上述技术方案中，优选地，所述接收方还包括：消息获取单元，用 于从所述消息中间件中获取数据消息和控制消息；消息存储单元，用于对 所述数据消息和所述控制消息进行记录和存储；消息解析单元，用于对所 述消息存储单元中存储的指定控制消息进行解析，以获取所述指定控制消 息中包含的标识、排列顺序和处理方式；消息处理单元，用于将所述标识 与存储的数据消息的唯一标识进行匹配，以确定对应于所述指定控制消息 的指定数据消息，并根据所述排列顺序和所述处理方式，对所述指定数据 消息进行处理。在该技术方案中，接收方可以直接接收任意消息，然后根 据需要进行挑选和处理，而无需在接收的过程中进行数据包的选择等，避 免数据阻塞，提高数据传输效率。

在上述技术方案中，优选地，所述发送方还包括：信息添加单元，用 于在所述控制消息中添加触发指示信息；所述接收方还包括：事件触发单 元，用于根据从所述控制消息中解析出的触发指示信息触发指定的事件， 以处理所述控制消息对应的数据消息。在该技术方案中，通过添加触发指 示信息，使得接收方可以据此触发指定的事件，有利于数据处理的连续 性。

根据本发明的又一方面，还提出了一种用于分布式应用系统的数据传 输方法，包括：步骤302，发送方将待发送的业务数据拆分为多个数据消 息；步骤304，所述发送方生成对应于所述数据消息的控制消息；步骤 306，所述发送方将所述数据消息和所述控制消息发送至消息中间件，以 供接收方进行获取并按照所述控制消息来处理所述数据消息。在该技术方 案中，通过控制消息来对数据消息的传输进行控制，从而脱离了对具体的 消息中间件的依赖，有利于降低对系统实现的复杂性。

在上述技术方案中，优选地，所述步骤302还包括：为每个所述数据 消息添加相应的唯一标识；以及所述步骤304还包括：所述控制消息中包 含每个所述数据消息的唯一标识、所述多个数据消息的排列顺序以及对所 述多个数据消息的处理方式。在该技术方案中，通过为每个数据包添加唯 一标识，使得可以根据控制消息中记录的数据包的排列顺序、处理方式等 信息，对数据包进行妥善处理。

在上述技术方案中，优选地，所述发送方采用非事务连接方式向所述 消息中间件发送所述数据消息和所述控制消息。在该技术方案中，通过采 用非事务连接方式进行消息发送，从而避免消息中间件因大数据量而致内 存崩溃，同时也避免对特定的消息中间件产生依赖。

在上述技术方案中，优选地，所述步骤306之后，还包括：步骤 308，所述接收方从所述消息中间件中获取数据消息和控制消息，并对其 进行记录和存储；步骤310，所述接收方根据从指定控制消息中解析出的 标识，与存储的数据消息的唯一标识进行匹配，以确定对应于所述指定控 制消息的指定数据消息；步骤312，所述接收方根据从所述指定控制消息 中解析出的排列顺序和处理方式，对所述指定数据消息进行处理。在该技 术方案中，接收方可以直接接收任意消息，然后根据需要进行挑选和处 理，而无需在接收的过程中进行数据包的选择等，避免数据阻塞，提高数 据传输效率。

在上述技术方案中，优选地，还包括：所述发送方还在所述控制消息 中添加触发指示信息；以及所述接收方还根据从所述控制消息中解析出的 触发指示信息触发指定的事件，以处理所述控制消息对应的数据消息。在 该技术方案中，通过添加触发指示信息，使得接收方可以据此触发指定的 事件，有利于数据处理的连续性。

通过以上技术方案，可以不依赖于具体的消息中间件，从而实现异步 的、松耦合的分布式数据传输，具有良好的可移植性，能够有效降低系统 实现的复杂性，尤其是解决了在大数据量和集群环境下的常见内存问题、 并发问题。

附图说明

图1示出了相关技术中的数据传输的示意图；

图2示出了根据本发明的实施例的数据传输系统的框图；

图3示出了根据本发明的实施例的数据传输方法的流程图；

图4A示出了根据本发明的实施例的发送方将数据传输至消息中间件 的示意图；

图4B示出了根据本发明的实施例的接收方从消息中间件获取和处理 数据的示意图；

图5示出了根据本发明的实施例的发送方对业务数据进行拆分的示意 图；

图6示出了根据本发明的实施例的发送方生成的控制消息的构成示意 图；

图7示出了根据本发明的实施例的发送方发送数据的流程图；

图8示出了根据本发明的实施例的接收方接收数据的流程图；

图9示出了根据本发明的实施例的发送方和接收方双向传输数据的流 程图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附 图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不 冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是， 本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明 的保护范围并不受下面公开的具体实施例的限制。

图2示出了根据本发明的实施例的数据传输系统的框图。

如图2所示，根据本发明的实施例的数据传输系统200，包括发送方 202和接收方206，其中，所述发送方202包括：数据拆分单元2020，用 于将待发送的业务数据拆分为多个数据消息；消息生成单元2022，用于 生成对应于所述数据消息的控制消息；数据发送单元2024，用于将所述 数据消息和所述控制消息发送至消息中间件，以供接收方206进行获取并 按照所述控制消息来处理所述数据消息。在该技术方案中，通过控制消息 来对数据消息的传输进行控制，从而脱离了对具体的消息中间件的依赖， 有利于降低对系统实现的复杂性。

在上述技术方案中，优选地，所述发送方202还包括：标识添加单元 2026，用于为每个所述数据消息添加相应的唯一标识；其中，所述控制消 息中包含每个所述数据消息的唯一标识、所述多个数据消息的排列顺序以 及对所述多个数据消息的处理方式。在该技术方案中，通过为每个数据包 添加唯一标识，使得可以根据控制消息中记录的数据包的排列顺序、处理 方式等信息，对数据包进行妥善处理。

在上述技术方案中，优选地，所述数据发送单元2024采用非事务连 接方式向所述消息中间件发送所述数据消息和所述控制消息。在该技术方 案中，通过采用非事务连接方式进行消息发送，从而避免消息中间件因大 数据量而致内存崩溃，同时也避免对特定的消息中间件产生依赖。

在上述技术方案中，优选地，所述接收方206还包括：消息获取单元 2060，用于从所述消息中间件中获取数据消息和控制消息；消息存储单元 2062，用于对所述数据消息和所述控制消息进行记录和存储；消息解析单 元2064，用于对所述消息存储单元2062中存储的指定控制消息进行解 析，以获取所述指定控制消息中包含的标识、排列顺序和处理方式；消息 处理单元2066，用于将所述标识与存储的数据消息的唯一标识进行匹 配，以确定对应于所述指定控制消息的指定数据消息，并根据所述排列顺 序和所述处理方式，对所述指定数据消息进行处理。在该技术方案中，接 收方206可以直接接收任意消息，然后根据需要进行挑选和处理，而无需 在接收的过程中进行数据包的选择等，避免数据阻塞，提高数据传输效 率。

在上述技术方案中，优选地，所述发送方202还包括：信息添加单元 2028，用于在所述控制消息中添加触发指示信息；所述接收方206还包 括：事件触发单元2068，用于根据从所述控制消息中解析出的触发指示 信息触发指定的事件，以处理所述控制消息对应的数据消息。在该技术方 案中，通过添加触发指示信息，使得接收方可以据此触发指定的事件，有 利于数据处理的连续性。

图3示出了根据本发明的实施例的数据传输方法的流程图。

如图3所示，根据本发明的实施例的数据传输方法，包括：步骤 302，发送方将待发送的业务数据拆分为多个数据消息；步骤304，所述 发送方生成对应于所述数据消息的控制消息；步骤306，所述发送方将所 述数据消息和所述控制消息发送至消息中间件，以供接收方进行获取并按 照所述控制消息来处理所述数据消息。在该技术方案中，通过控制消息来 对数据消息的传输进行控制，从而脱离了对具体的消息中间件的依赖，有 利于降低对系统实现的复杂性。

在上述技术方案中，优选地，所述步骤302还包括：为每个所述数据 消息添加相应的唯一标识；以及所述步骤304还包括：所述控制消息中包 含每个所述数据消息的唯一标识、所述多个数据消息的排列顺序以及对所 述多个数据消息的处理方式。在该技术方案中，通过为每个数据包添加唯 一标识，使得可以根据控制消息中记录的数据包的排列顺序、处理方式等 信息，对数据包进行妥善处理。

在上述技术方案中，优选地，所述发送方采用非事务连接方式向所述 消息中间件发送所述数据消息和所述控制消息。在该技术方案中，通过采 用非事务连接方式进行消息发送，从而避免消息中间件因大数据量而致内 存崩溃，同时也避免对特定的消息中间件产生依赖。

在上述技术方案中，优选地，所述步骤306之后，还包括：步骤 308，所述接收方从所述消息中间件中获取数据消息和控制消息，并对其 进行记录和存储；步骤310，所述接收方根据从指定控制消息中解析出的 标识，与存储的数据消息的唯一标识进行匹配，以确定对应于所述指定控 制消息的指定数据消息；步骤312，所述接收方根据从所述指定控制消息 中解析出的排列顺序和处理方式，对所述指定数据消息进行处理。在该技 术方案中，接收方可以直接接收任意消息，然后根据需要进行挑选和处 理，而无需在接收的过程中进行数据包的选择等，避免数据阻塞，提高数 据传输效率。

在上述技术方案中，优选地，还包括：所述发送方还在所述控制消息 中添加触发指示信息；以及所述接收方还根据从所述控制消息中解析出的 触发指示信息触发指定的事件，以处理所述控制消息对应的数据消息。在 该技术方案中，通过添加触发指示信息，使得接收方可以据此触发指定的 事件，有利于数据处理的连续性。

图4A和图4B共同展现了本发明中进行数据传输的示意图。

实际上，本发明通过改善在消息中标识业务数据和业务操作边界的方 式、改善发送和接收处理机制的方式来解决问题，核心思想是将触发处理 的控制信息单点化，即控制信息由独立的消息传输，发送方唯一地以控制 消息的发送作为完整发送的标志而不依赖于通讯基础设施的事务，接收方 唯一地以收到控制消息作为触发业务处理的标志以解决集群环境下多点分 配的问题。其基本特征有：

（1）将消息通过加入的标识符分为两类：数据消息和控制消息。数 据消息加入具有唯一性的标识符，指示此消息包含的是业务数据。控制消 息加入唯一性的标识符指示此消息包含的是作为一次业务操作引发的传输 中包含的数据消息的唯一性标识符列表以及其它指示接收方如何处理的控 制信息。

（2）数据消息和控制消息各自分开独立发送，多个数据消息之间无 需保持顺序，数据消息与控制消息之间的先后不是必要因素，接收方需要 相应地进行一致的处理。

（3）接收方订阅接收到消息后，对于数据消息做存储和记录，不触 发业务处理，对于控制消息，则根据其中记录的业务操作相关的数据消息 的唯一标识符从存储记录中查找获取数据消息，并触发对应的业务处理过 程。

依照这三项实现的传输装置的基本构成包括：发送装置、接收装置、 消息存储装置。

（1）发送装置负责将业务数据分解成数据消息和控制消息发送到消 息中间件。

（2）接收装置负责在收到数据消息或控制消息后保存消息或触发业 务处理。

（3）消息存储装置负责存储消息和检索消息。

当然，对于本发明中的“消息中间件”，需要说明的是：本发明的通 讯机制是基于消息发布/订阅模型，但并不局限于特定的消息中间件，只 要是实现了消息发布/订阅模型的基础通讯设施都可以作为本发明的通讯 基础。

那么，基于上述原理，本发明的数据传输过程如下：

如图4A所示，将数据（DATA）传输至发送装置后，发送装置对数 据进行拆分处理，得到数据消息（如图4A中的D1、D2、D3）和控制消 息（如图4A中的TC），并将数据消息和控制消息发送至消息中间件。

如图4B所示，接收装置从消息中间件获取所有的数据消息和控制消 息后，存储至消息存储装置中；然后，根据控制消息中记录的信息，确定 相应的数据消息，以对其进行处理。

下面针对图4A和图4B所示的本发明的数据传输方案，做出进一步 的解释。

1、在消息中标识和识别业务数据和业务操作边界的方法

将消息标识为数据消息和控制消息两类是本发明最主要的特征之一， 也是整个传输机制的实现基础。控制消息整个传输机制中的核心，发送方 以发出的控制消息标识了数据传输的完整性，接收方以收到控制消息作为 进行业务处理的触发点。

构成控制消息的核心要素包括：

a、能够表示消息类型为控制消息的标识符；

b、能够表示数据关联的业务类型或操作类型的标识符；

c、能够表示包含业务数据被分解生成的数据消息的唯一标识符的列 表。

此外，控制消息还可以加入其它的信息，例如：消息的有效期、是否 允许部分处理、处理超时时长、是否顺序处理。

构成数据消息的核心要素是表示数据消息唯一性的标识，此外，也可 以根据实现的需要加入其它必要信息。

举例如下：

如图5所示，一份需要发送的业务数据共计有1280KB，每个消息的 大小最大限制为512KB。这样，这份数据需要分成3个数据消息进行发 送，为每个数据消息进行唯一编号，以字母“D”开头，分别编为D1、 D2、D3。对应生成的控制消息的标识符以“TC”开头编号为“TC001” 以唯一标识此次发送操作，TC001中同时包含了一个数据消息ID列表 “D1,D2,D3”，表示此次发送操作共包含了3个数据消息及其唯一编号。

在示例中为了便于描述而使用简单字符作为消息的唯一性标识符，在 实际实现中可以采用全局唯一标识符（GUID）或者其它更复杂的或带有 业务属性信息的唯一标识符，亦或者是某些消息中间件创建消息时生成的 编号。

此外，图5中作为示例仅描述了包含最核心要素的控制消息和数据消 息的结构，实际实现中可以根据需要加入其它的内容，比如业务数据是一 段用户数据，发送方希望接收方收到数据后触发“用户信息更新”事件， 由事件响应程序处理这些数据，那么如图6所示，可以以类似的方式加入 额外的控制标识符PROC_TYPE：EVENT和EVT_TYPE： UPDATE_USERS。

2、发送装置的数据发送机制及其实现

发送装置负责按照标识和识别业务数据和业务操作边界的方法将业务 数据分解成多个数据消息并生成相应的控制消息发送到消息中间件。发送 装置的基本工作步骤主要包括：a、将业务数据分解成多个数据消息；b、 根据数据消息列表生成控制消息；c、通过消息通讯基础设施发送数据消 息和控制消息。

具体地，发送装置的数据传输过程包括：

步骤702，获取业务数据。

步骤704，生成数据消息。

步骤706，生成控制消息。

步骤708，逐个发送数据消息。

步骤710，判断所有的数据消息是否全部发送成功，若是，则进入步 骤712，否则结束。

步骤712，发送控制消息。

发送装置的核心是将数据消息和控制消息分开发送。

在发送数据消息时，多个数据消息采用串行发送还是并行发送可以根 据实际需要来实现，均属于本发明的传输机制允许的实现方案。

在基于典型的消息中间件实现时，数据消息的发送不需要采用消息中 间件的事务型连接进行发送，这样可以避免消息中间件因大数据量而致内 存崩溃，同时也避免对特定的消息中间件行程。采取非事务连接方式向消 息中间发送能够使得基于本发明的机制下可以支持极大数据量的传输，支 持的最大数据量(Sm)收到两个因素的限制：每个消息的最大尺寸（Sa）， 控制消息在消息最大尺寸下能够记录的数据消息的标识符的最大个数 （N），Sm=Sa*N，可以一般性地认为N等于Sa除以每个标识符的大 小（Si），那么Sm=Sa*Sa/Si。

假设，消息中间件允许的每个消息最大尺寸为1MB，每个数据消息 的标识符大小为32Byte，则Sm=1MB*1MB/32Byte=32GB；如果 消息中间件允许的每个消息的最大尺寸为5MB，则Sm=5MB*5MB/ 32Byte=800GB。此外，如果辅以数据压缩手段还可以成倍地提高最大 数据量。

3、接收装置的数据接收机制及其实现

接收装置是配合发送装置实现的发送过程而实现数据接收。数据接收 包含两个基本过程：

a、数据消息的接收：从消息中间件将数据消息读取出来，通过消息 存储装置进行记录和保存。

b、控制消息的接收：从消息中间件将控制消息读取出来，通过消息 存储装置进行记录和保存之后，根据控制消息中记录的数据消息标识符列 表，通过消息存储装置检索出数据消息，按照控制消息中指定的数据顺序 和处理方式触发对应的业务数据处理过程。

接收装置执行数据传输的具体过程包括：

步骤802，收到消息，包括数据消息和控制消息。

步骤804，保存消息。

步骤806，判断当前是否为控制消息，若是，则进入步骤808，否则 结束。

步骤808，按标识符列表检索存储的数据消息。

步骤810，判断是否收到全部数据消息，若是，则进入步骤812，否 则结束。

步骤812，处理数据消息。

以图6所示的控制消息为例，当收到控制消息TC001时，则通过消 息存储装置检索消息标识符列表中的D1、D2、D3数据消息是否已经收 到，如果已经收到，则触发UPDATE_USERS事件，将D1、D2、D3数 据消息的内容作为事件参数传递。

对于未收到时需要进行的处理可以根据实际情况实现，例如可以等待 重试，或者抛弃处理，或者触发某类约定的错误等等，但这些并不是本装 置的必要要求。

从消息中间件接收消息的具体编程实现是需要调用具体消息中间件提 供的API实现的，由选用的消息中间件决定。例如，对于实现了JMS的 消息中间件，则按照JMS定义的MessageConsumer进行监听和接收消 息。

4、消息存储装置的消息存储机制及其实现

消息存储装置需要满足对消息的存储和按标识符检索的功能，在实现 上可以有许多实现方式可以选择，例如基于文件系统存储、基于数据库存 储等，同时还需要考虑其它技术因素，例如集群环境因素、数据库压力状 况等。例如在集群环境下，如果采用基于文件系统的消息存储装置实现， 则需要将存储位置单点化，提供存储的文件系统必须是各个集群节点都能 共同访问到网络文件系统。

符合本发明的消息存储装置需要实现最基本的两点：

1、能够按照消息标识符保存消息；

2、能够按照消息标识符检索到已保存的消息。

以文件系统存储为例，需要将消息标识或者由标识符生成的格式字符 作为文件名保存，在检索时按消息标识符或者由标识符生成的格式字符作 为文件名进行磁盘文件查找。

以数据库存储为例，保存消息的数据表最基本的需要消息标识符列 (char/varchar类型)和消息内容列(blob类型)两个列分别保存消息标识符和 消息内容。

此外，消息存储装置的独立实现并非是实现本发明的必要的要素，其 功能也可以与消息接收装置合并在一起进行实现。

5、双向传输的实现

本发明的装置中，一个消息发送装置和一个消息接收/存储装置构成 了一个单向传输单元。要实现双向传输只需要将此单向传输单元再反向部 署一套即可，即需要传输双方中的每一方都同时具有消息发送装置和消息 接收/存储装置。具体地，如图9所示，展现了一个具备双向传输能力的 系统装置。

以上结合附图详细说明了本发明的技术方案，本发明技术方案与现有 的应用消息中间件的技术最大区别之处是，本技术方案提出一套基于消息 发布/订阅模型的数据传输的机制，该机制的核心是建立在本方案提出的 对业务数据和业务操作的边界标识方法以及与之对应的发送、接收处理机 制，并不依赖于具体的消息中间件厂商，在上层应用和通讯基础设置之间 维持了独立性，给应用系统提供了一套更加通用、灵活和更具移植性的分 布式通讯解决方案。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于 本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精 神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明 的保护范围之内。