CN113254448A - 一种数据记录方法及系统 - Google Patents

Abstract

本发明提供了一种数据记录方法及系统，方法包括：通过数据更新层将应用系统的记录数据封装为符合统一规范的数据包结构；通过消息处理层将所述数据包结构封装为统一格式的消息；通过接口处理层发送所述消息到指定的存储设备。本发明采用了分层设计结构方案，分为数据更新层、消息处理层、接口处理层，进一步地，还包括记录调度层，能够满足不同项目设计需要，记录模块内部耦合度低、灵活性强，便于修改和扩展。

Description

一种数据记录方法及系统

技术领域

本发明属于电数字数据处理技术领域，特别涉及一种数据记录方法及系统。

背景技术

对于大型软件项目尤其是工业嵌入式软件项目来说，由于系统功能逻辑极为复杂且往往缺乏部署高性能数据库或在线维护终端的条件，故其本身的记录功能直接决定了故障定位和产品维护能力。另外，随着系统硬件接口、功能分配、使用场景、甚至资源占用和性能要求的差异，系统的数据记录软件往往需要调整，导致不同项目记录软件部分不能复用，导致开发效率低下和人工浪费。

一般地，大型软件系统中的记录功能部分必不可少，其主要是对系统设备的基础信息、运行信息、异常/故障信息及维护信息等进行记录，传输和存储。记录数据用于产品诊断、故障分析、故障重现和数据挖掘等，在软件整体结构中有着举足轻重的地位。

现有技术中，数据记录软件设计方式存在以下问题：

软件的记录功能部分和软件其它部分（应用系统部分）是强相关的，需要依赖记录功能部分指定的形式和内容转存相关数据，与应用系统的应用逻辑耦合性较高，导致记录功能的修改会影响软件应用逻辑。

软件的记录功能对于不同类型数据的记录接口和处理方式往往是针对特定应用系统定制化开发的，无法实现代码复用，造成记录功能的软件和维护工具等的重复开发。

记录数据的协议格式不能满足多样化需求，往往通过多种协议方式实现不同类型内容的记录，缺乏一致的设计规范。如应用系统的版本数据与通信接口数据的结构不同，为了记录版本数据和通信接口数据需要采用不同的协议格式进行数据记录，最终记录数据处理较繁杂。

数据记录功能不能与应用系统功能同步开发，需等应用系统的开发后期再根据记录功能的需求修改应用系统的软件，导致记录功能开发滞后甚至影响整体开发进度。

因此，亟需一种通用、高效的数据记录方案。

发明内容

针对上述问题，本发明提供了一种通用模块化一种数据记录方法及系统，通过对数据记录功能进行分析和抽象，使用分层设计思想，将软件项目中的数据记录功能拆分为记录调度、数据更新、协议处理、接口限制等主要功能集合，提出一种通用、高效的数据记录方案。该设计方法整体采用模块化思想，不侵入既有或新开发应用系统逻辑，与应用系统软件耦合性低，满足敏捷开发要求，极大地提高了开发效率同时降低了成本。

本发明提供一种数据记录方法，包括：

通过数据更新层将应用系统的记录数据封装为符合统一规范的数据包结构；

通过消息处理层将所述数据包结构封装为统一格式的消息；

通过接口处理层发送所述消息到指定的存储设备。

进一步地，在消息处理层将消息进行转义后封装为数据帧，在接口处理层以数据帧形式发送到指定的存储设备。

进一步地，所述通过数据更新层将应用系统的记录数据封装为符合统一规范的数据包结构包括：

在数据更新层定义数据包结构规范；

数据更新层从应用系统的记录数据获取接口获取符合数据包结构规范的数据包数据；

所述应用系统的记录数据获取接口满足数据包结构规范。

进一步地，数据更新层将待发送的数据包结构存储至第一队列；

消息处理层从所述第一队列中数据包结构以生成所述消息。

进一步地，所述通过数据更新层将应用系统的记录数据封装为符合统一规范的数据包结构包括：

设置符合统一规范的数据包结构，所述数据包结构包括更新标记，所述更新标记用于记录数据包结构是否满足更新条件；

当所述更新标记满足指定条件时，设置数据包结构的数据值，并将该数据包结构存储至第一队列。

进一步地，通过消息处理层将所述数据包结构封装为统一格式的消息包括：

将待发送的多个数据包结构按照数据包长度排序；

采用双索引遍历排序后的数据包，选择使得消息满足最大传输单元要求的多个数据包，封装为消息。

进一步地，通过消息处理层将所述数据包结构封装为统一格式的消息包括：

获取待发送一个或多个的数据包结构；

计算单个数据包结构生成的消息长度是否超出最大传输单元的要求，若是，则丢弃该数据包；

计算所有待发送的数据包结构组成的消息是否满足最大传输单元的要求，若满足，则将所有待发送的数据包封装为一条消息；若不满足，则：

对待发送的数据包结构按长度排序，采用双索引指向排序后的数据包结构，移动索引，选择若干个数据包以使得消息长度满足最大传输单元的要求。

进一步地，所述消息处理层将待封装的消息存储至第二队列；

所述接口处理层从第二队列获取消息输出到指定的存储设备。

进一步地，所述接口处理层从第二队列获取消息输出到指定的存储设备包括：

所述接口处理层根据接口吞吐量限制和/或阻塞时间限制，控制每次输出的消息的数量。

进一步地，方法还包括：

通过记录调度层控制执行状态机变化，根据状态机变化控制数据更新层的执行；

所述状态机包括未知状态、配置记录状态和数据记录状态。

进一步地，通过记录调度层控制执行状态机变化，根据状态机变化来控制数据更新层的执行包括：

设置默认状态为未知状态；

按指定条件等待后，由默认状态转入配置记录状态，执行记录系统启动前加载的配置项；

当配置项记录成功后，由配置记录状态转入数据记录状态，控制数据更新层开始记录应用系统的记录数据。

本发明还提供一种数据记录系统，包括：

数据更新模块，用于将应用系统的记录数据封装为符合统一规范的数据包结构；

消息处理模块，用于将所述数据包结构封装为统一格式的消息；

接口处理模块，用于发送所述消息到指定的存储设备。

进一步地，系统还包括：

记录调度模块，用于控制执行状态机变化，根据状态机变化来控制数据更新层的执行；

所述状态机包括未知状态、配置记录状态和数据记录状态。

本发明还提供一种数据记录系统，所述系统包括至少一个处理器以及至少一个存储器；

所述存储器存储执行上述数据记录方法的计算机程序，所述处理器调用存储器中的所述计算机程序以执行上述数据记录方法。

本发明的具有以下优点：

（1）采用了分层设计结构方案，分为数据更新层、消息处理层、接口处理层，进一步地，还包括记录调度层，能够满足不同项目设计需要，记录模块内部耦合度低、灵活性强，便于修改和扩展。优化的实施方案还具有以下优点：

（2）记录协议格式定义的消息和数据包两级结构形式，统一、灵活、适应性强。

（3）记录协议的方式及支持本地存储也支持传输及记录硬件分布式的结构。

（4）数据记录方案的数据更新层设计实现了系统其它部分和记录模块的弱耦合。

（5）数据记录方案的消息处理层设计实现了数据消息传输和存储的限制下的消息优化生成，既满足了传输、存储接口限制又能最大限度的输出记录数据。

（6）数据更新层、消息处理层、接口处理层均通过队列接口实现“隔离”，满足“外开内闭”设计原则，能够更加灵活的实现功能扩展或通过参数调整实现软件复用。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所指出的结构来实现和获得。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了根据本发明实施例的一种数据记录方法流程示意图；

图2示出了根据本发明实施例的记录调度层的状态机转化关系示意图；

图3示出了根据本发明实施例的生成消息的流程图；

图4示出了根据本发明实施例的接口处理层发送消息的流程；

图5示出了根据本发明实施例的一种数据记录系统结构示意图；

图6示出了根据本发明实施例的另一种数据记录系统结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地说明，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供数据记录方法，采用模块化设计，用于满足不同项目需要和不同接口限制，实现了记录功能代码复用，能够快速高效开发记录功能。本发明实施例中，记录功能用于记录其他应用软件，如工业嵌入式软件的执行逻辑过程，便于对问题进行历史追踪和定位。本发明实施例的记录方法可以通过软件方式或者软件与硬件结合的方式实现，为了区分本发明构思的主体—数据记录方法和被记录的目标，将被记录或待记录的软件成为其他部分软件或应用系统。本发明的记录功能可以实现为记录功能模块、数据记录系统、记录功能软件等。示例性地，应用系统可以是轨道交通领域的软件系统，如列控系统、联锁系统。

如图1所示，采用模块化设计的数据记录方法主要将记录功能划分为数据更新层、消息处理层和接口处理层。进一步地，还可以包含记录调度层。该记录调度层不是必须的，记录调度层依据实际软件需求可以不设置，在这种情况下，启动记录功能后，直接按照数据更新层、消息处理层和接口处理层的调度顺序，执行数据记录即可。

本发明实施例的数据记录方法包括：

通过数据更新层将应用系统的记录数据封装为符合统一规范的数据包结构；

通过消息处理层将所述数据包结构封装为统一格式的消息；

通过接口处理层发送所述消息到指定的存储设备。

其中，消息在消息处理层进行转义并封装为数据帧，在接口处理层以数据帧形式发送到指定的存储设备。

不失一般性地，统一规范是指满足相同的预定规则，如数据包都包含指定字段和数据区等。统一规范的数据包结构可以通过相应的接口和程序的数据结构定义。统一格式的消息是指满足相同指定规则的消息，如包含指定长度的指定消息部分。本发明实施例中，统一规范的数据包结构是指生成或传输不同的数据包时，其结构可以满足相同的预定规则，但并非限定所有数据包必须采用同一种结构。统一格式的消息也是一样，本发明实施例中示例性地对一种格式进行说明。

本发明实施例将记录数据按照记录协议分装为两层结构，通过不同的模块（层）实现记录数据逐层封装并进行发送，方便针对不同的记录类型或数据发送要求调整数据记录方法的实现，而不至于修改整体的记录功能，从而能够适应多种场景的记录数据生成和传输。数据记录的每个环节之间也实现松散耦合、独立控制，逻辑清晰，便于每层充分利用资源，进行优化。

下面首先对两层结构的通用记录协议进行示例性说明。两层结构协议包括消息层和数据包层，应用系统待记录数据均以数据包的形式封装进消息中，再将消息进行帧转义形成数据帧，最终记录内容以数据帧的形式发送、传输、存储，完成数据记录功能。

数据帧结构

数据记录数据以帧的结构发送和记录，帧由帧头(0x7E)、帧内容、帧尾(0x7F)组成，帧结构如下所示：

帧内容中若出现与帧头（0x7E）、帧尾（0x7F）、转义字符（0x7D）相同的字符，应对其进行转义，转义规则如下：

帧内容即为转义后的原始消息，一帧数据的帧内容只包含一条消息，转义后的数据可以通过帧头和帧尾完整提取，通过将数据帧的帧头、帧尾和转义字符进行转义，实现数据帧与实际传输方式和接口“隔离”，能极大简化相关处理逻辑。帧头、帧尾作为数据帧的界定符，所以实际按照流或数据报传输或者直接存储后，可以根据帧界定符恢复原始数据帧。

消息结构

消息是本协议中输出数据的最小单位，消息结构包括消息头、消息内容、消息尾三部分组成。其中消息头至少包含消息ID（NID_MESSAGE）和消息长度（L_MESSAGE），还可以包括自定义部分。消息头的自定义部分可根据实际项目需要扩充或修改描述字段，示例性地，自定义部分包括：设备型号、系统周期号、系统时间和UTC时间；消息内容是数据包的集合，还包括补齐字节（PADDINGS），数据包是系统要记录的实际数据；消息尾包括序号(N_SEQ)和帧校验序列（CRC_CODE），用于检验消息经过发送、传输、存储等过程后的相对顺序及完整性。消息结构的格式如下表：

数据包结构

数据包结构包括两部分，数据包头和数据包内容，其中数据包头包括包ID(NID_PACKET)、包长度（L_PACKET），包ID应该具有唯一性，且不同数据包之间的包ID必须不同。数据包内容可以按需填充，分为两种，第一种数据包内容对于字段变量记录的表达结构如下，数据包内容根据需要包括多个字段：

协议格式中的非自定义字段（字段1-字段n）的占位比特数可以根据实际情况调整用于减小协议开销或增加扩展能力。

第二种数据包内容为通信数据或缓存区，对于通信数据或缓存区记录的数据包结构如下：

示例性地，数据包结构中的通信数据可以是其他系统设备接口的原始通信数据，如一个200字节的TCP包。传输时，可以直接装载为数据包内容；缓存区可以是在FLASH或内存中加载的一个参数文件，如140字节的参数文件，传输时，可以按照字节程度将整个文件装载到数据包内容中。

本发明实施例的通用数据记录协议格式，能够满足不同类型数据、不同传输、存储接口记录的需要。由于采用了两级结构，消息能够携带不同数量的数据包，与固定记录长度数据相比，这种“变长”结构比极大优化了记录过程的开销和资源使用。

下面结合数据记录协议格式，对本发明实施例中采用数据更新层、消息处理层、接口处理层和记录调度层实现数据记录的过程做详细说明。采用模块化设计的数据记录方法实现为软件（记录模块）时对外提供两个接口：主逻辑接口和数据输出接口，前者调用执行整个记录逻辑，后者用于传输（主要用于分布式存储场景，将记录数据传输到指定的存储设备）或存储记录数据。

（1）记录调度层

本层通过记录调度层根据存储设备状态和不同记录内容的记录要求，控制数据更新层执行记录。示例性地，通过调用下层（数据更新层）控制接口实现调度整个数据记录功能的执行，用于满足对应用系统不同阶段记录要求的数据记录，记录调度层通过控制执行状态机变化来控制数据更新层执行记录。示例性地，在分布式场景，应用系统的执行设备和记录数据的存储设备的启动时间不一致，且需要区分启动时的记录数据和运行时的记录数据，在这种情况下，一种典型的数据记录调度层状态机结构如下：如图2所示，状态机包括未知状态（Unkown State）、配置记录状态（Config Record State）和数据记录状态（DataRecord State）。考虑存储设备启动延时，设置默认状态为未知状态；按指定条件等待后，由默认状态转入配置记录状态，对系统启动前加载的配置项进行记录，其中按指定条件等待为等待指定时延或者等待直到接收到存储设备启动成功的通知；当配置项记录成功后，由配置记录状态转入数据记录状态，否则（当配置未完成或者配置超时或者配置失败）不进行数据记录，保留在配置记录状态。示例性地，如图1所示，记录模块主模块计算状态机，当状态转为数据记录状态时，记录调度层控制数据更新层开始记录应用系统的记录数据，具体地，可以通过记录调度层的调度状态机的接口调度数据更新层的相关接口来执行数据记录或者通过变量等方式通知数据更新层可以开始执行数据记录。状态机转到数据记录状态后自动保持该状态，直到状态机被重置，如记录模块重启后将自动设置为未知状态，即重置为未知状态。或者根据记录过程需要控制状态机重置为未知状态。

（2）数据更新层

本层负责所有要记录数据获取以及更新检查及标记，只有本层标记更新的数据，才会通过经过后续层（消息处理层等）处理，最终被记录下来。如图1所示，数据获取包括从应用系统的记录数据获取接口获取数据；检查更新包括记录模块根据应用系统设计需要确定更新时机来处理更新标记。记录模块的功能包括两部分，“检查更新”和“执行更新”。“检查更新”为根据记录模块的记录需要设置更新机制，获取应用系统提供的更新时机，如周期或事件，当更新时机满足记录模块指定的更新机制时，设置指定数据包结构的更新标记为指定的待更新状态。记录模块的“执行更新”功能根据更新标记的状态处理待更新的数据包结构。通过更新标记能够实现更新时机、更新需求的灵活调整，而不影响更新执行的逻辑，记录模块对于数据记录的更新具有自主调节控制的能力，并与应用系统松耦合。

关于记录数据获取，数据更新层将应用系统的记录数据封装为符合统一规范的数据包结构，具体包括：在数据更新层定义数据包结构规范，示例性地，可以通过定义协议中的数据包结构接口；从应用系统的记录数据获取接口获取符合数据包结构规范的数据包数据；所述应用系统的记录数据获取接口满足数据包结构规范，以C语言为例，应用系统的记录数据获取接口返回的数据结构是数据更新层定义的数据包结构的超集。数据更新层代码举例以C语言为例，按照设计思路，C++，C#等也可设计类似代码，本发明实施例语言选择不做限制。

下面对数据更新层和被记录的目标应用系统的接口设计进行示例性说明。

记录模块和其他部分（即其他应用软件部分或应用系统的软件部分）之间采用单向标记耦合，由其他部分定义并声明各自独立的记录结构，作为其应用系统的一部分；而记录模块只需引用其他部分提供的只读接口，即可获取数据，然后按照协议由消息处理层生成数据帧。从而实现了其他部分与记录模块内容解耦，记录模块的开发不会影响其他应用软件部分。

对于其他部分数据记录接口定义举例如下：

通过上述步骤，系统软件中其他部分将完成自身的记录数据的结构的定义（用于获取数据包结构）、赋值以及提供一个记录数据获取接口，记录模块通过该接口获取记录内容。

记录模块检查是否更新数据包结构。

记录数据的更新检查依赖于记录模块自身定义的数据包结构，该结构严格按照协议定义，而软件其他部分的结构定义可以是协议的超集。协议的更新检查方式根据数据存储的需要进行设计，如：周期更新，满足指定条件时更新和数据变化时更新等方式。标记为更新的数据包结构变量，其引用会被压入第一队列，不失一般性地，第一队列为环形队列，用于和下层（消息处理层）实现对接。示例性地，标记数据包结构为待更新数据的方式为设置更新标记为指定值，如布尔值True。

记录模块数据获取接口定义举例如下：

数据包结构包括更新标记，更新标记用于记录数据包结构是否满足更新条件，判断更新标记满足指定条件时，设置数据包结构的数据值，并将该数据包结构存储至第一队列。不失一般性地，第一队列为环形队列。数据更新层将待发送的数据包结构存储至第一队列，消息处理层从所述第一队列中数据包结构以生成消息。

（3）消息处理层

消息处理层将一个或多个的数据包结构封装在一条消息中，将消息转义生成数据帧。

本层与上层（数据更新层）可通过环形队列实现层与层之间的接口通信，将其更新的数据包结构按照协议及传输接口、存储接口卡的限制要求，按照最大处理能力进行消息字节流生成和处理。考虑到某些系统接口传输和存储能力的限制，如：底层使用数据链路层协议需要对数据帧进行拆分时有拆分能力限制。需要根据底层最大传输单元(MTU)来生成消息。

在消息处理层配置消息最大长度L_MAX_MESSAGE,这个长度就是记录模块生成消息的最大长度，通过对所有待发送数据包列表进行遍历检查，将待发送的多个数据包结构按照数据包长度排序，采用双索引遍历排序后的数据包，选择使得消息满足最大传输单元要求的多个数据包，封装为消息。当待发送的数据包结构总量超过限制时，选择符合要求的若干数据包结构立即完成当前消息，并开始生成下一条消息，处理剩下的待封装数据包结构。特别的当单个数据包本身已经超过MTU时，应该在协议中加以限制。

如图1所示，生成消息的过程可能涉及数据包排序和再次拆分，考虑长度限制的情况下生成消息，将消息转义后生成数据帧，存储至第二队列，不失一般性地，第二队列为环形队列，以便接口处理层从第二队列获取消息输出到指定的存储设备。

如图3所示，生成消息的过程包括一下步骤：

在数据更新层更新数据包结构ID值和比特长度，生成数据包（数据包结构）待发送列表，即第一队列；

在消息处理层：

获取待发送一个或多个的数据包结构，即从第一队列中获取数据包；

计算单个数据包消息最大值，具体为，计算单个数据包结构按照协议封装后的长度，生成的消息长度是否超出最大传输单元的要求，若是，则丢弃该数据并执行相应错误处理；即，存在单包消息超过MTU限制时，丢弃该数据包，实现对第一队列中获取的数据结构的筛选。丢弃该数据包是指消息处理层不对该数据包进行封装为消息的操作。进一步地，还可以对该数据包进行再拆分，拆分为满足MTU限制的数据包结构后再次压入第一队列进行处理。

对获取的数据包结构进行筛选后，计算所有待发送的数据包结构组成的消息是否满足最大传输单元的要求，若满足，则将所有待发送的数据包生成一条消息，进行转义后形成数据帧；若不满足，则：

为了尽可能快的将所有数据包发送出去，每条消息中尽可能多装数据，本发明实施例中对待发送的数据包结构按长度，具体为比特长度排序，采用双索引指向排序后的待压入消息的数据包结构，移动索引，选择若干个数据包以使得消息长度满足最大传输单元的要求。具体地，先移动其中的第一索引，判断双索引之间的若干（大于等于1）数据包总长度是否满足最大传输单元的要求且达到总长度最大，若满足，则将这些数据包生成一条消息，若不满足，则继续移动索引直至满足，确定用于生成消息的数据包后，将另一个索引即第二索引也移动到与第一索引相同位置。

（4）接口处理层

接口处理层和消息处理层可通过第二队列的环形队列接口完成通信，消息处理层将产生的转义后的数据帧立即压入第二队列，第二队列产生数据帧后，接口处理层立即从第二队列中取出数据帧，存放在临时存储的记录队列中，然后将临时存储中的待发送消息根据发送限制确定本次调用发送的消息数量，如图1所示。考虑到记录模块每次执行可能产生多条数据帧，而且存储传输接口可能由另外的任务和线程调度，第二队列在这里起着“异步”、“削峰”及“解耦”作用，数据帧生成和发送独立。

需要说明的是，本发明实施例中，消息处理层和接口处理层之间可以通过环形队列、数组、接口函数等等方式通信，环形队列只是一种较优的接口方式，能够灵活地控制队列对象（数据包、数据帧）的压入和取出，便于基于双索引进行多个对象选择并能够快速计算环形队列是否已经满了，以便与前后层模块之间协调对象的生产和消费。

接口处理层根据接口吞吐量限制和/或阻塞时间限制等，控制每次输出的消息的数量。接口处理层的数据输出接口根据接口吞吐量限制或阻塞时间限制等，控制每次输出的消息条数，否则临时缓存在记录模块中。具体地，在接口处理层配置连续发送最大消息字节数L_MAX_SEND_BYTES及最大执行时间T_MAX_SEND_TIME。

如图4所示，接口处理层发送消息的过程包括以下步骤：

开始执行本次消息发送；

判断记录队列是否为空，如果为空，则结束本次消息发送，等待下次周期触发的消息发送；

如果不为空，判断本次消息发送是否满足吞吐量和阻塞时间等限制，吞吐量为最大消息字节数，阻塞时间为最大执行时间；如果满足，则发送一条消息（具体为发送包含消息的数据帧），发送消息的时候记录发送的字节数；之后，继续判断记录队列是否为空，进行下一条消息的发送。

如果不满足吞吐量和阻塞时间等限制，则结束本次消息发送，等待下次周期触发的消息发送。

本发明实施例的数据记录方法提出了模块化设计方案和统一的协议设计，通过分层结构实现了数据记录模块和应用软件的弱耦合，能够支持不同项目记录软件快速开发和统一，能够适应不同接口和存储方式。

统一的记录协议格式可以降低软件维护成本，模块化的软件设计使得用户仅需根据不同项目提供的记录需求修改记录调度层和数据更新层；且由于记录模块和应用系统弱耦合，记录模块可以和应用实现同步开发。另外，记录模块的消息处理层和接口处理层均通过环形队列实现跨层接口，功能内聚扩展灵活，易于代码复用，仅通过修改配置参数即可满足记录要求，极大提高了开发和维护效率。

基于相同的发明构思，本发明实施例还提供一种数据记录系统，如图5所示，系统包括：

数据更新模块，用于将应用系统的记录数据封装为符合统一规范的数据包结构；

消息处理模块，用于将数据包结构封装为统一格式的消息；

接口处理模块，用于发送消息到指定的存储设备。

进一步地，系统还包括记录调度模块，用于控制执行状态机变化，根据状态机变化来控制数据更新层的执行。其中，状态机包括未知状态、配置记录状态和数据记录状态。

该数据记录系统各个模块的具体实现方式可以根据本发明任意实施例方法获得，不再赘述。

在本发明的方法可以是由计算机或嵌入式程序控制的系统来实现。因此，与之相对应地，本发明的实施例中还提供了一种数据记录系统，如图6所示，系统包括至少一个处理器以及至少一个存储器；存储器存储执行以上本发明任意实施例方法的计算机程序，处理器调用存储器中计算机程序以执行本发明任意实施例方法。

进一步地，存储器可与一个或多个处理器通信连接，存储器中存储有可被一个或多个处理器执行的指令，指令被一个或多个处理器执行，以使一个或多个处理器能够实现本发明的方法。

尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (14)

1.一种数据记录方法，其特征在于，包括：

通过数据更新层将应用系统的记录数据封装为符合统一规范的数据包结构；

通过消息处理层将所述数据包结构封装为统一格式的消息；

通过接口处理层发送所述消息到指定的存储设备。

2.根据权利要求1所述的数据记录方法，其特征在于，在消息处理层将消息进行转义后封装为数据帧，在接口处理层以数据帧形式发送到指定的存储设备。

3.根据权利要求1所述的数据记录方法，其特征在于，所述通过数据更新层将应用系统的记录数据封装为符合统一规范的数据包结构包括：

在数据更新层定义数据包结构规范；

数据更新层从应用系统的记录数据获取接口获取符合数据包结构规范的数据包数据；

所述应用系统的记录数据获取接口满足数据包结构规范。

4.根据权利要求1所述的数据记录方法，其特征在于，

数据更新层将待发送的数据包结构存储至第一队列；

消息处理层从所述第一队列中数据包结构以生成所述消息。

5.根据权利要求4所述的数据记录方法，其特征在于，所述通过数据更新层将应用系统的记录数据封装为符合统一规范的数据包结构包括：

设置符合统一规范的数据包结构，所述数据包结构包括更新标记，所述更新标记用于记录数据包结构是否满足更新条件；

当所述更新标记满足指定条件时，设置数据包结构的数据值，并将该数据包结构存储至第一队列。

6.根据权利要求5所述的数据记录方法，其特征在于，通过消息处理层将所述数据包结构封装为统一格式的消息包括：

将待发送的多个数据包结构按照数据包长度排序；

采用双索引遍历排序后的数据包，选择使得消息满足最大传输单元要求的多个数据包，封装为消息。

7.根据权利要求6所述的数据记录方法，其特征在于，通过消息处理层将所述数据包结构封装为统一格式的消息包括：

获取待发送一个或多个的数据包结构；

计算单个数据包结构生成的消息长度是否超出最大传输单元的要求，若是，则丢弃该数据包；

计算所有待发送的数据包结构组成的消息是否满足最大传输单元的要求，若满足，则将所有待发送的数据包封装为一条消息；若不满足，则：

对待发送的数据包结构按长度排序，采用双索引指向排序后的数据包结构，移动索引，选择若干个数据包以使得消息长度满足最大传输单元的要求。

8.根据权利要求1所述的数据记录方法，其特征在于，

所述消息处理层将待封装的消息存储至第二队列；

所述接口处理层从第二队列获取消息输出到指定的存储设备。

9.根据权利要求8所述的数据记录方法，其特征在于，所述接口处理层从第二队列获取消息输出到指定的存储设备包括：

所述接口处理层根据接口吞吐量限制和/或阻塞时间限制，控制每次输出的消息的数量。

10.根据权利要求1-9中任一项所述的数据记录方法，其特征在于，还包括：

通过记录调度层控制执行状态机变化，根据状态机变化来控制数据更新层的执行；

所述状态机包括未知状态、配置记录状态和数据记录状态。

11.根据权利要求10所述的数据记录方法，其特征在于，通过记录调度层控制执行状态机变化，根据状态机变化来控制数据更新层的执行包括：

设置默认状态为未知状态；

按指定条件等待后，由默认状态转入配置记录状态，执行记录系统启动前加载的配置项；

当配置项记录成功后，由配置记录状态转入数据记录状态，控制数据更新层开始记录应用系统的记录数据。

12.一种数据记录系统，其特征在于，包括：

数据更新模块，用于将应用系统的记录数据封装为符合统一规范的数据包结构；

消息处理模块，用于将所述数据包结构封装为统一格式的消息；

接口处理模块，用于发送所述消息到指定的存储设备。

13.根据权利要求12所述的数据记录系统，其特征在于，还包括：

记录调度模块，用于控制执行状态机变化，根据状态机变化来控制数据更新模块的执行；

所述状态机包括未知状态、配置记录状态和数据记录状态。

14.一种数据记录系统，其特征在于，所述系统包括至少一个处理器以及至少一个存储器；

所述存储器存储执行权利要求1－11任一方法的计算机程序，所述处理器调用存储器中的所述计算机程序以执行权利要求1－11任一所述的方法。

Images