一种金融数据的异常容灾方法、系统、设备及介质

摘要

本发明涉及金融数据处理技术领域，尤其是涉及一种金融数据的异常容灾方法、系统、计算机设备以及存储介质。金融数据的异常容灾方法包括：基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据；根据标准化金融数据的数据状态，对状态后端中的数据状态进行更新，得到当前数据状态；设定检查点的触发周期，当检查点被触发时，基于标准化金融数据和当前数据状态，对状态后端进行持久化处理并在持久化处理完成后生成相应的检查点数据文件；当列式存储引擎中的服务节点发生服务异常时，加载最新的检查点数据文件对服务节点进行重启恢复。本申请具有有助于降低设备成本和提高集群的可用性的效果。

权利要求

1.一种金融数据的异常容灾方法，其特征在于，所述金融数据的异常容灾方法包括以下步骤：基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据；

根据所述标准化金融数据的数据状态，对所述状态后端中的数据状态进行更新，得到当前数据状态；

设定检查点的触发周期，当所述检查点被触发时，基于所述标准化金融数据和所述当前数据状态，对所述状态后端进行持久化处理并在所述持久化处理完成后生成相应的检查点数据文件，所述基于所述标准化金融数据和当前数据状态，对所述状态后端进行持久化处理，具体包括：基于所述标准化金融数据和所述当前数据状态，将所述状态后端中与所述标准化金融数据和所述当前数据状态相对应的线程注册到全局注册中心中；

从所述全局注册中心中获取所述线程的注册顺序和依赖关系，根据所述注册顺序和所述依赖关系，将有依赖关系的线程按所述注册顺序进行排列，以形成若干条状态链，其中，所述状态链中的节点用于表示线程，两个节点之间具有方向的边用于表示线程之间的依赖关系；

根据所述状态链的逻辑关系，构建得到有向无环图，其中，所述有向无环图包括列式存储引擎，全局注册中心和至少一条状态链；

基于所述有向无环图，对所述状态后端进行持久化处理；

当所述列式存储引擎中的服务节点发生服务异常时，加载最新的检查点数据文件对所述服务节点进行重启恢复。

2.根据权利要求1所述的金融数据的异常容灾方法，其特征在于，所述基于所述有向无环图，对所述状态后端进行持久化处理，具体包括：基于所述有向无环图，通过消息队列将所述标准化金融数据和所述当前数据状态广播到所述有向无环图的每一条状态链中对应的根节点中；

根据标准化金融数据和所述当前数据状态，并行对所述根节点下的每一个节点中的算子状态进行状态更新，并将更新后的状态发送至所述全局注册中心进行保存。

3.根据权利要求2所述的金融数据的异常容灾方法，其特征在于，所述在所述持久化处理完成后生成相应的检查点数据文件，具体包括：当所述有向无环图中的所有节点的算子状态更新完成后，根据所述全局注册中心的全局状态生成相应的检查点数据文件；

将所述检查点数据文件存储到本地文件系统中。

4.根据权利要求1所述的金融数据的异常容灾方法，其特征在于，所述基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据，具体包括：根据待存储的金融数据的数据类型，选择与所述数据类型相匹配的数据结构；

将选定数据结构的金融数据封装为后端状态对象；

根据所述后端状态对象的数据状态，从所述列式存储引擎的状态后端中获取与所述后端状态对象的数据状态相对应的数据状态，判断两者数据状态是否一致；

若两者数据状态一致，则跳过本次写入操作；

若两者数据状态不一致，则将所述状态对象写入到所述状态后端中。

5.根据权利要求4所述的金融数据的异常容灾方法，其特征在于，所述若两者数据状态不一致，则将所述状态对象写入到所述状态后端中，具体包括：将所述状态对象序列化成二进制数据；

判断所述二进制数据的预留空间是否充足；

若所述预留空间充足，则将所述二进制数据写入到所述预留空间对应的存储位置中以形成一个数据块，并更新所述二进制数据在该数据块的位置索引；

若所述预留空间不充足，则重新分配新的存储空间，并将预留空间对应的存储位置标记为不可用，将所述二进制数据写入到所述新的存储空间对应的存储位置中以形成一个数据块，更新所述二进制数据在该数据块的位置索引。

6.根据权利要求1所述的金融数据的异常容灾方法，其特征在于，在所述加载最新的检查点数据文件进行重启恢复前，还包括：从检查点数据文件中获取元数据，从所述元数据中获取数据块的位置索引和类型；

根据数据块的位置索引和类型，分配与所述数据块的内存结构和内存大小。

7.一种金融数据的异常容灾系统，其特征在于，所述金融数据的异常容灾系统包括：数据处理模块，用于基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据；

状态更新模块，用于根据所述标准化金融数据的数据状态，对所述状态后端中的数据状态进行更新，得到当前数据状态；

检查点触发周期设定模块，用于设定检查点的触发周期；

数据保存模块，用于当所述检查点被触发时，基于所述标准化金融数据和所述当前数据状态，对所述状态后端进行持久化处理并在所述持久化处理完成后生成相应的检查点数据文件，数据保存模块包括：线程注册模块，用于基于标准化金融数据和当前数据状态，将状态后端中与标准化金融数据和当前数据状态相对应的线程注册到全局注册中心中；

状态链生成模块，用于从全局注册中心中获取线程的注册顺序和依赖关系，根据注册顺序和依赖关系，将有依赖关系的线程按注册顺序进行排列，以形成若干条状态链，其中，状态链中的节点用于表示线程，两个节点之间具有方向的边用于表示线程之间的依赖关系；

有向无环图构建模块，用于根据状态链的逻辑关系，构建得到有向无环图，其中，有向无环图包括列式存储引擎，全局注册中心和至少一条状态链；

数据持久化模块，用于基于有向无环图，对状态后端进行持久化处理；

数据异常恢复模块，用于当所述列式存储引擎发生服务异常时，加载最新的检查点数据文件进行重启恢复。

8.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1‑6任一项所述的一种金融数据的异常容灾方法的步骤。

9.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1‑6任一项所述的一种金融数据的异常容灾方法的步骤。

说明书

一种金融数据的异常容灾方法、系统、设备及介质

技术领域

[0001] 本发明涉及金融数据处理技术领域，尤其是涉及一种金融数据的异常容灾方法、系统、计算机设备以及存储介质。

背景技术

[0002] 金融数据，作为一种高价值的无形资产，涉及金融领域的股票、期权、期货以及每个交易日从开盘到收盘的数据记录，数据记录为毫秒级，造成该类数据历史基数、日增量都相对庞大，在面对如此海量且有价值的历史数据和日增量数据时，如何将该类数据进行存储以及在设备发生故障后，如何进行容灾，以减少该类数据的丢失，成为了该领域技术人员亟待解决的技术问题。

[0003] 现有的对数据的异常容灾的方法包括：采用冷备用方案，通过增加一套与主节点一样配置的设备。当主节点宕机后，启动从节点以应对异常容灾；采用热备用方案，通过 zookeeper 分布式组件，对一个固定的zookeeper节点进行抢占，一旦抢占成功，则注册端口对用户服务，自身识别为主节点。当主节点宕机后，其他冷备用节点将会得到zookeeper的通知，再次启动抢占zookeeper节点抢占的逻辑；或者，采用基于分布式理念的多主方案，通过 zookeeper 分布式组件，把所有服务节点注册到zookeeper的节点列表上，注册成功后，服务节点即打开端口对外服务，但需要额外引入一个节点网关，把用户的请求均匀的进行转发。当任意节点宕机后，网关得到zookeeper丢线通知，则不再向故障节点进行转发，除非所有服务节点全部当机crash，否则都能正常对外服务。

[0004] 上述中的现有技术方案存在以下缺陷：

[0005] 在通过采用冷备用方案对数据进行容灾时，需要冗余一套与主节点一样配置的设备，从而导致了双倍的设备成本，同时没法提高日常正常运作的并发数量；在通过采用热备用方案对数据进行容灾时，虽然实现了在节点故障的时候快速转移数据，但依然无法降低成本，且服务器由于日常处于开机的状态，电力成本有所增加；在通过采用基于分布式理念的多主方案对数据进行容灾时，则需要增加主节点的容量，并需要随时准备好其中一部分节点故障后而造成大量的用户请求涌入，从而不仅导致了主节点在负载的监控上特别敏感，而且在节点局部故障可能造成雪崩，容易酿成全局事故。同时引入了网关，增加了链路复杂性，增加了问题排查的难度。

[0006] 上述现有的技术方案仍存在着高成本，可用性不高的技术缺陷，因此，还有改善空间。

发明内容

[0007] 为了降低设备成本和提高集群的可用性，本申请提供一种金融数据的异常容灾方法、系统、计算机设备以及存储介质。

[0008] 本申请的上述发明目的一是通过以下技术方案得以实现的：

[0009] 一种金融数据的异常容灾方法，所述金融数据的异常容灾方法包括以下步骤：

[0010] 基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据；

[0011] 根据所述标准化金融数据的数据状态，对所述状态后端中的数据状态进行更新，得到当前数据状态；

[0012] 设定检查点的触发周期，当所述检查点被触发时，基于所述标准化金融数据和所述当前数据状态，对所述状态后端进行持久化处理并在所述持久化处理完成后生成相应的检查点数据文件；

[0013] 当所述列式存储引擎中的服务节点发生服务异常时，加载最新的检查点数据文件对所述服务节点进行重启恢复。

[0014] 通过采用上述技术方案，通过将待存储的金融数据进行处理后存储到列式存储引擎的状态后端中，更新其状态后端中对应的数据状态，并设置检查点的触发周期，对状态后端中的金融数据及其数据状态进行周期性的持久化处理，且在持久化处理完成后生成相应的检查点数据文件。当列式存储引擎中的服务节点发生服务异常时，进而可以从本机的文件系统中加载最新生成的检查点数据文件对异常的服务节点进行重启恢复，从而有效地避免了采用双设备进行容灾，使得所有设备都能投入到生产使用当中，有助于降低设备成本和降低设备冗余，提升集群的可用性和提高每个服务节点资源的利用率。同时，由于金融数据及其状态存储在列式存储引擎中，有助于在服务节点故障时实现毫秒级重启，从而有助于保证集群在高并发的金融场景下，降低集群雪崩的可能性。

[0015] 本申请在一较佳示例中可以进一步配置为：所述基于所述标准化金融数据和当前数据状态，对所述状态后端进行持久化处理，具体包括：

[0016] 基于所述标准化金融数据和所述当前数据状态，将所述状态后端中与所述标准化金融数据和所述当前数据状态相对应的线程注册到全局注册中心中；

[0017] 从所述全局注册中心中获取所述线程的注册顺序和依赖关系，根据所述注册顺序和所述依赖关系，将有依赖关系的线程按所述注册顺序进行排列，以形成若干条状态链；其中，所述状态链中的节点用于表示线程，两个节点之间具有方向的边用于表示线程之间的依赖关系；

[0018] 根据所述状态链的逻辑关系，构建得到有向无环图，其中，所述有向无环图包括列式存储引擎，全局注册中心和至少一条状态链；

[0019] 基于所述有向无环图，对所述状态后端进行持久化处理。

[0020] 通过采用上述技术方案，通过将状态后端中与更新后的金融数据及其数据状态相对应的线程注册到全局注册中心中，并根据全局注册中心中的线程的注册顺序和线程之间的依赖关系形成若干条状态链，从而构建得到有向无环图，进而可以将构建得到的有向无环图作为每一条状态链路节点之间的通知顺序，对有向无环图中的每一条状态链路中的每一个节点对应的线程进行持久化处理，有助于在有计算依赖的金融数据的场景下，使每一条链路之间互不影响，都能独立运作，从而能保证每一个层级状态的一致性，极大降低了已计算的数据被重复计算的可能性，有助于减少不必要的计算开销，提高了数据处理的效率。

[0021] 本申请在一较佳示例中可以进一步配置为：所述基于所述有向无环图，对所述状态后端进行持久化处理，具体包括：

[0022] 基于所述有向无环图，通过消息队列将所述标准化金融数据和所述当前数据状态广播到所述有向无环图的每一条状态链中对应的根节点中；

[0023] 根据标准化金融数据和所述当前数据状态，并行对所述根节点下的每一个节点中的算子状态进行状态更新，并将更新后的状态发送至所述全局注册中心进行保存。

[0024] 通过采用上述技术方案，通过根据构建得到的有向无环图，利用消息队列将更新后的金融数据及其更新后的数据状态广播到有向无环图的每一条状态链路的根节点中，并行对每一个根节点下的每一个节点中的算子状态进行状态更新，并将更新后的状态发送至全局注册中心进行缓存。采用广播的方式将状态后端中更新后的金融数据及其更新后的数据状态广播到每一条状态链路中，有助于并行对每一条链路中的节点状态进行状态更新操作，有助于提高程序的执行效率和更好地实现负载均衡，从而有助于提高状态保存的速度。同时，采用状态链的方式，有效地提高了状态保存的性能，从而有助于实现金融数据集其状态的实时持久化的效果。

[0025] 本申请在一较佳示例中可以进一步配置为：所述在所述持久化处理完成后生成相应的检查点数据文件，具体包括：

[0026] 当所述有向无环图中的所有节点的算子状态更新完成后，根据所述全局注册中心的全局状态生成相应的检查点数据文件；

[0027] 将所述检查点数据文件存储到本地文件系统中。

[0028] 通过采用上述技术方案，通过在有向无环图中的所有节点的算子状态更新完成后，根据全局注册中心缓存的所有节点的算子状态，生成相应的检查点数据文件，并把该检查点数据文件作为最新的检查点数据文件存储到本地文件系统中，有利于在集群的服务节点发生异常时，可以从本地文件系统中读取最新的检查点数据文件对异常的服务节点进行重启恢复，有助于提高异常服务节点重启恢复的速度。

[0029] 本申请在一较佳示例中可以进一步配置为：所述基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据，具体包括：

[0030] 根据待存储的金融数据的数据类型，选择与所述数据类型相匹配的数据结构；

[0031] 将选定数据结构的金融数据封装为后端状态对象；

[0032] 根据所述后端状态对象的数据状态，从所述列式存储引擎的状态后端中获取与所述后端状态对象的数据状态相对应的数据状态，判断两者数据状态是否一致；

[0033] 若两者数据状态一致，则跳过本次写入操作；

[0034] 若两者数据状态不一致，则将所述状态对象写入到所述状态后端中。

[0035] 通过采用上述技术方案，通过根据待存储金融数据类型，选择与该数据类型相匹配的数据结构，将选定数据结构的金融数据封装为后端状态对象，并判断该后端状态对象的数据状态是否存在于状态后端中，以决定后续是否进行写入操作，有助于减少状态后端对同样的金融数据的写入次数，提高数据的处理效率。同时，为状态后端设计了相关的数据结构，有助于用户可以根据自身的业务场景选择合适的数据结构，降低了用户的使用门槛，有助于提高用户的使用体验和更好地满足用户的需求。并且，由于采用相关的数据结构对存储的数据进行了更高层次的封装，有助于后续在获取到相关的存储文件时，可以快速地在分析进程中打开状态后端，以对该状态后端进行监控和可视化，有助于提高程序的可拓展性和适用性。

[0036] 本申请在一较佳示例中可以进一步配置为：所述若两者数据状态不一致，则将所述状态对象写入到所述状态后端中，具体包括：

[0037] 将所述后端对象序列化成二进制数据；

[0038] 判断所述二进制数据的预留空间是否充足；

[0039] 若所述预留空间充足，则将所述二进制数据写入到所述预留空间对应的存储位置中以形成一个数据块，并更新所述二进制数据在该数据块的位置索引；

[0040] 若所述预留空间不充足，则重新分配新的存储空间，并将预留空间对应的存储位置标记为不可用，将所述二进制数据写入到所述新的存储空间对应的存储位置中以形成一个数据块，更新所述二进制数据在该数据块的位置索引。

[0041] 通过采用上述技术方案，通过将后端对象序列化成二进制数据，并进一步判断预留的空间是否充足，以决定后续是否需要重新分配新的连续的存储空间，有助于将待存储的金融数据进行批量写入，以存储为有序的数据块，进而有助于保证金融数据的时序性，便于后续对金融数据的查询和分析。

[0042] 本申请在一较佳示例中可以进一步配置为：在所述加载最新的检查点数据文件进行重启恢复前，还包括：

[0043] 从检查点数据文件中获取元数据，从所述元数据中获取数据块的位置索引和类型；

[0044] 根据数据块的位置索引和类型，分配与所述数据块的内存结构和内存大小。

[0045] 通过采用上述技术方案，通过在加载最新生成的检查点数据文件对异常的服务节点进行重启恢复前，从检查点数据文件中的元数据获取待重放金融数据的数据块的位置索引和类型，并据此预先分配相关的内存结构和大小，进而有助于在加载检查点数据文件对异常的服务节点进行重启恢复时，可以并发加载要重放金融数据的数据块，进而极大地避免了在加载检查点数据文件的过程中频繁地进行内存分配和释放操作，有助于提高了加载的效率，从而有助于实现异常节点的高效恢复。

[0046] 本申请的上述发明目的二是通过以下技术方案得以实现的：

[0047] 一种金融数据的异常容灾系统，所述金融数据的异常容灾系统包括：

[0048] 数据处理模块，用于基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据；

[0049] 状态更新模块，用于根据所述标准化金融数据的数据状态，对所述状态后端中的数据状态进行更新，得到当前数据状态；

[0050] 检查点触发周期设定模块，用于设定检查点的触发周期；

[0051] 数据保存模块，用于当所述检查点被触发时，基于所述标准化金融数据和所述当前数据状态，对所述状态后端进行持久化处理并在所述持久化处理完成后生成相应的检查点数据文件；

[0052] 数据异常恢复模块，用于当所述列式存储引擎发生服务异常时，加载最新的检查点数据文件进行重启恢复。

[0053] 通过采用上述技术方案，通过将待存储的金融数据进行处理后存储到列式存储引擎的状态后端中，更新其状态后端中对应的数据状态，并设置检查点的触发周期，对状态后端中的金融数据及其数据状态进行周期性的持久化处理，且在持久化处理完成后生成相应的检查点数据文件。当列式存储引擎中的服务节点发生服务异常时，进而可以从本机的文件系统中加载最新生成的检查点数据文件对异常的服务节点进行重启恢复，从而有效地避免了采用双设备进行容灾，使得所有设备都能投入到生产使用当中，有助于降低设备成本和降低设备冗余，提升集群的可用性和提高每个服务节点资源的利用率。同时，由于金融数据及其状态存储在列式存储引擎中，有助于在服务节点故障时实现毫秒级重启，从而有助于保证集群在高并发的金融场景下，降低集群雪崩的可能性。

[0054] 本申请的上述目的三是通过以下技术方案得以实现的：

[0055] 一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述一种金融数据的异常容灾方法的步骤。

[0056] 本申请的上述目的四是通过以下技术方案得以实现的：

[0057] 一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述一种金融数据的异常容灾方法的步骤。

[0058] 综上所述，本申请包括以下至少一种有益技术效果：

[0059] 1.通过将待存储的金融数据存入到列式存储引擎的状态后端中，并对状态后端的金融数据及其状态进行持久化处理，根据持久化处理结果生成相应的检查点数据文件，在列式存储引擎发生服务异常时，可以从本地文件系统中加载最新的检查点数据文件对该异常的服务节点进行重启恢复，有效地避免了采用双设备容灾，进而使所有设备都能投入使用，有效地降低了设备冗余和生产成本，有助于保证所有服务节点都能对外提供服务，提高了每一个节点资源的利用率，提升了服务集群的高可用性，从而有助于低成本金融数据异常容灾的实现。同时，由于金融数据的状态存储在列式引擎中，有助于提高异常服务节点的重启恢复的速度，从而有助于实现异常服务节点的毫秒级重启。

[0060] 2.通过基于状态的快速恢复机制，有利于保证金融数据的完整性、准确性和可靠性，从而使金融场景下的时序数据的实时分析任务能正常进行，同时有助于快速响应用户的请求，提升用户的使用体验。

附图说明

[0061] 图1是本申请一实施例中状态后端的结构示意图。

[0062] 图2是本申请一实施例中一种金融数据的异常容灾方法的一流程图；

[0063] 图3是本申请一实施例中一种金融数据的异常容灾方法步骤S10的实现流程图；

[0064] 图4是本申请一实施例中一种金融数据的异常容灾方法步骤S15的实现流程图；

[0065] 图5是本申请一实施例中一种金融数据的异常容灾方法步骤S30的实现流程图；

[0066] 图6是本申请一实施例中一种金融数据容灾方法中一构建的有向无环图的结构示例图；

[0067] 图7是本申请一实施例中一种金融数据的异常容灾方法步骤S314的实现流程图；

[0068] 图8是本申请一实施例中一种金融数据的异常容灾方法步骤S30的另一实现流程图；

[0069] 图9是本申请一实施例中一种金融数据的异常容灾系统的一原理框图；

[0070] 图10是本申请一实施例中的设备示意图。

具体实施方式

[0071] 以下结合附图对本申请作进一步详细说明。

[0072] 在一实施例中，如图1所示，本申请公开了一状态后端的结构示意图，本申请的一状态后端可以包括外模式、逻辑模式和内模式三层架构。

[0073] 在本实施例中，外模式是指用户能够看见和使用局部数据的逻辑结构和特征的描述，是状态后端中用户的数据视图，是与某一应用有关的数据的逻辑表示，例如本申请中的金融数据。外模式主要用于为用户提供泛型的抽象数据结构，方便用户可以根据自身的业务场景选择合适的数据结构。

[0074] 在本实施例中，逻辑模式是指状态后端中全体数据的逻辑结构和特征描述，是所有用户的公共数据视图。它是状态后端模式结构的中间层，主要用于为每一个对外提供的数据结构设计一个对应的逻辑模型。

[0075] 在本实施例中，内模式也称存储模式，是对状态后端中的物理存储和存储方式的描述，是数据在状态后端内部中的组织方式，主要用于为相应的带存储数据提供对应的存储方案和存储引擎。可以理解的，在本申请实施例中，本申请采用列式存储的方式对其金融场景产生的金融数据进行存储。

[0076] 进一步地，mq队列即消息队列(message queue)，是一种应用间的通信方式。本申请在调度上提供了一个全局无锁的消息队列，以便于各层次之间的相互通信。

[0077] 本申请通过外模式、逻辑模式和内模式的三层架构设计，将状态后端分为不同的层级，使得每个层级的功能和责任更加清晰，进而有助于优化状态后端的结构和功能，使系统更加灵活和安全，有助于提高开发人员的开发效率和系统的可维护性。同时有助于为后续的金融数据及其数据状态的存储和持久化处理提供相应的处理流程，从而有助于优化金融数据的处理性能，保证金融数据的完整性和可靠性。

[0078] 在一实施例中，如图2所示，本申请公开了一种金融数据的异常容灾方法，具体包括如下步骤：

[0079] S10：基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据。

[0080] 在本实施例中，列式存储是一种与行式不同的数据存储方案，在存储结构化数据时，在底层的存储介质上，内部的数据存储结构是以列的方式进行组织存储，即存储完若干条记录的首个字段后，再存储这些记录的第二个字段，然后是这些记录的第三个字段，以此类推，当这些记录的所有字段存储完毕后，再按照这种方式，组织存储下一批若干条记录的所有字段。存储引擎是指对存储数据的处理机制，是存储数据，建立索引，更新或查询数据等技术的实现方式。本实施例中的列式存储引擎用于限定金融数据存储时以列式存储的方式进行存储，并用于对该引擎中的状态后端存储的金融数据及其数据状态进行持久化操作，同时列式存储引擎对于在线分析处理数据的场景具有天然的优势，可适用于对本申请的金融数据进行实时分析的金融场景中，有利于提高程序的灵活性和可扩展性。

[0081] 在本实施例中，状态后端是Flink中提供的一个用于状态的存储、访问以及维护的一个可插拔的组件。可以理解的，在本申请中，该状态后端是指上述经过改进的状态后端，用于存储和处理本申请中的金融数据以及其数据状态。

[0082] 具体的，基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据。可以理解的，该数据处理包括对待存储金融数据进行封装处理，判断处理和序列化处理等一系列处理，从而得到标准化金融数据，便于后续将该标准化金融数据存储到状态后端中。可以理解的，标准化金融数据是指经过上述数据处理后的且符合状态后端的存储条件的金融数据，即相对于状态后端中存储的历史金融数据来说，该金融数据属于新的金融数据。

[0083] 进一步地，请参阅图3，在步骤S10中，即基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据，具体包括：

[0084] S11：根据待存储的金融数据的数据类型，选择与数据类型相匹配的数据结构。

[0085] 具体的，根据待存储的金融数据的数据类型，选择与该金融数据的数据类型相匹配的数据结构。该状态后端中的数据结构包括但不限于BackendMap（用于存储键‑值(key‑value)型数据）、BackendValue（用于存储单个变量数据）、BackendList（用于存储列表数据）、BackendSet（用于存储集合型数据）、BackendStack（用于存储栈型数据）、BackendQueue（用于存储队列型数据），从而覆盖了(但不限于)Map、Value、List、Set、Stack、Queue 等一系列传统常用的容器并且对标到了具体编程语言的结构封装，如C、C++和Java等流行编程语言，极大地提高程序的可拓展性和适用性，具体采用何种编程语言可以根据实际的需要进行选择，在此不作任何限制。可以理解的，用户可以根据自身的实际业务场景选择合适的数据结构对其数据进行处理，且在进行后端数据状态保存的过程中，用户无需再进行额外的处理，操作简易，有助于满足用户的多方面需求和降低用户的使用门槛，从而提升了用户的使用体验。

[0086] S12：将选定数据结构的金融数据封装为后端状态对象。

[0087] 具体地，通过将选定数据结构的金融数据输入到列式存储引擎中，列式存储引擎将选定数据结构的金融数据封装为后端状态对象，方便后续状态后端的写入操作。同时，由于对金融数据采用了相关的数据结构进行更高层次的容器进行封装。因此，相关技术人员只要知释了高层封装的容器结构，在获取到相关的存储文件，用户可以在分析进程中快速地打开状态后端，以对状态后端进行监控和可视化，从而有助于简化运维人员的的培训，快速地提升运维人员的工作效率。

[0088] S13：根据后端状态对象的数据状态，从列式存储引擎的状态后端中获取与后端状态对象的数据状态相对应的数据状态，判断两者数据状态是否一致。

[0089] 具体地，根据上述封装后的后端对象的数据状态，从状态后端中获取与该后端对象的数据状态对应的数据状态，将两者的数据状态的哈希(hash)值进行比对，从而判断两者的数据状态是否一致，以决定后续是否进行状态后端的写入操作，有助于减少状态后端对同样数据及数据状态的写入次数，提高数据的处理效率。可以理解的，该状态后端的数据状态包括历史对待存储的金融数据进行处理的数据状态。

[0090] S14：若两者数据状态一致，则跳过本次写入操作。

[0091] 具体地，如果上述封装后的后端对象的数据状态对应的哈希(hash)值与状态后端中的数据状态对应的哈希(hash)值一致，即表明此时的数据并没有发生改变，可以直接跳过本次金融数据的写入行为，减少对相同的金融数据的写入次数，进而有利于提高数据的处理效率。

[0092] S15：若两者数据状态不一致，则将状态对象写入到状态后端中。

[0093] 具体地，如果上述封装后的后端对象的数据状态的哈希(hash)值和状态后端中的数据状态的哈希(hash)值不一致，即表明该数据为新的金融数据，也即标准化金融数据，进而将标准化金融数据写入到状态后端中，从而实现状态后端的增量存储。

[0094] 进一步地，请参阅图4，在步骤S15中，即若两者数据状态不一致，则将状态对象写入到状态后端中，具体包括：

[0095] S151：将后端对象序列化成二进制数据。

[0096] 具体地，将要存入状态后端中的后端对象序列化成二进制数据，即将上述的标准化金融数据序列化成二进制数据，以便机器能快速进行识别，提高其数据处理的效率。

[0097] S152：判断二进制数据的预留空间是否充足。

[0098] 具体地，根据后端对象序列化后的二进制数据的数据结构，判断该数据结构类型已有的数据存储空间是否有充足的预留空间，以决定后续是否需要重新分配新的连续的存储空间。由于金融数据具有数据的时序的特性，因此可以对金融数据进行批量写入，并将数据存储为有序的块，进而使得相同类型的数据结构的金融数据在硬盘中的物理存储空间相邻，有利于确保金融数据按照时间顺序进行存储的同时方便后续的查询和分析，例如当用户需要读取同一数据结构的金融数据时，由于在列式存储中的相邻的列结构的金融数据类型相同，从而减少了硬盘的读写次数，有助于提升金融数据的查询效率，以快速响应用户的请求。

[0099] S153：若预留空间充足，则将二进制数据写入到预留空间对应的存储位置中以形成一个数据块，并更新二进制数据在该数据块的位置索引。

[0100] 在本实施例中，数据块指的是一组有序的存储单元，用于后续将上述得到的标准化金融数据批量写入该存储单元中以形成一个有序数据块，有助于保证金融数据的时序性和便于后续金融场景下的查询和分析流程。

[0101] 具体地，如果该数据结构类型已有的数据空间仍有充足的预留空间，则将该二进制数据写入到该预留空间相对应的存储位置中以形成一个有序的数据块，并更新该二进制数据的索引位置，以便后续便于查找。

[0102] S154：若预留空间不充足，则重新分配新的存储空间，并将预留空间对应的存储位置标记为不可用，将二进制数据写入到新的存储空间对应的存储位置中以形成一个数据块，更新二进制数据在该数据块的位置索引。

[0103] 具体地，如果该数据结构类型已有的数据空间没有充足的预留空间，则将原有的预留空间中对应的存储位置标记为不可用，并重新开辟新的连续的存储空间，以解决后续金融数据预留空间不足的问题，将该二进制数据写入到新的存储空间对应的存储位置中以形成一个有序的数据块，更新数据块的位置索引，以便后续能快速查找到该类型的金融数据。

[0104] S20：根据标准化金融数据的数据状态，对状态后端中的数据状态进行更新，得到当前数据状态。

[0105] 具体地，根据标准化金融数据的数据状态，对状态后端中的数据状态进行同步更新，从而得到当前数据状态。可以理解的，对状态后端中的数据状进行更新可以是在状态后端中添加金融数据更新的状态信息。

[0106] S30：设定检查点的触发周期，当检查点被触发时，基于标准化金融数据和当前数据状态，对状态后端进行持久化处理并在持久化处理完成后生成相应的检查点数据文件。

[0107] 在本实施例中，检查点是一个保存着当前程序运行信息的数据文件，它的主要作用是当服务节点发生异常需要重启恢复的时候，可直接去本地文件系统中加载最新生成的检查点文件，而不需要额外去数据库中进行数据加载以提升异常服务节点的重启速度。可以理解的，生成的检查点数据文件保存的数据包括但不限于金融数据及其相关的数据状态，线程和进程的额外的数据状态信息以及用于标识金融数据存放位置和类型的元数据。可以理解的，该元数据还包括版本信息，用于标记对应的上述生成的检查点文件的版本信息。可以理解的，上述提到的数据库可以为关系型数据库，如Mysql和Oracle等，也可以是非关系型数据库，如NoSQL等，具体在此不作任何限制。

[0108] 具体地，通过设定检查点的触发周期对检查点进行周期性的定时触发，当检查点被触发时，即检查点保存操作被触发时，基于上述标准化金融数据和当前数据状态，对状态后端进行持久化处理并在持久化处理完成后生成相应的检查点数据文件。可以理解的，设定检查点的触发周期，该触发周期可以根据实际的需求、性能以及系统的资源进行设置或调整，设定检查点的触发周期的实现方式可以通过定时器的方式对检查点进行周期性的定时触发。可以理解的，上述提到的持久化处理指的是将程序数据在持久状态和瞬时状态间转换的处理机制。通俗的讲，就是瞬时数据（比如内存中的数据，是不能永久保存的）持久化为持久状态的数据。

[0109] 进一步地，请参阅图5，在步骤S30中，即基于标准化金融数据和当前数据状态，对状态后端进行持久化处理，具体包括：

[0110] S311：基于标准化金融数据和当前数据状态，将状态后端中与标准化金融数据和当前数据状态相对应的线程注册到全局注册中心中。

[0111] 在本实施例中，全局注册中心是一个用于管理和维护系统中各种状态信息的集中式服务或组件。它充当了一个状态的存储、查找和分发中心，以有助于保证系统中的各个部分都能够共享和访问状态信息，而无需直接耦合在一起。全局注册中心在系统中起到了缓存状态数据的中央管理和消息转发作用，帮助实现模块间的解耦合、数据一致性和灵活性，是构建复杂系统的重要组成部分。

[0112] 具体地，当上述的检查点被触发时，全局注册中心在接收到该触发消息后，基于状态后端中标准化金融数据和当前数据状态，将该状态后端中与该标准化金融数据及其当前数据状态相对应的线程注册到全局注册中心中。

[0113] S312：从全局注册中心中获取线程的注册顺序和依赖关系，根据注册顺序和依赖关系，将有依赖关系的线程按注册顺序进行排列，以形成若干条状态链；其中，状态链中的节点用于表示线程，两个节点之间具有方向的边用于表示线程之间的依赖关系。

[0114] 在本实施例中，状态链指的是由有依赖关系的节点的集合所形成的一条链路，状态链中的每一个节点代表一个线程，两个节点之间具有方向的边用于表示线程之间的依赖关系。该状态链用于将金融数据及其状态按顺序依次分发到相应的节点（即线程）中，对每一个节点的状态（即线程状态）进行持久化操作，进而可以有效地提高线程数据状态的保存性能，有助于实现实时持久化的效果。

[0115] 具体的，从全局注册中心中获取线程的注册顺序和依赖关系，根据注册顺序和依赖关系，将有依赖关系的线程按注册顺序进行排列，以形成若干条状态链。

[0116] S313：根据状态链的逻辑关系，构建得到有向无环图，其中，有向无环图包括列式存储引擎，全局注册中心和至少一条状态链。

[0117] 在本实施例中，有向无环图指的是一个无回路的有向图，由列式存储引擎，全局注册中心和上述形成的若干条状态链所组成，用于作为每一条状态链的持久化操作的通知顺序，从而使每一条链路之间互不影响，都能独立运作，进而保证每一个层级状态的一致性。

[0118] 具体地，根据上述形成的若干条状态链的逻辑关系，从而构建得到有向无环图。可以理解的，若干条具体指至少包括一条。进一步地，为了更清楚的说明本实施例，而非对其限制，本申请给出了一种金融数据容灾方法中一构建的有向无环图的结构示例图。如图6所示，该有向无环图包括列式存储引擎，全局注册中心和三条状态链。图中的状态链每一个节点代表一个线程，两个节点之间具有方向的边用于表示线程之间的依赖关系。图中所示的A节点、B节点、C节点分别为该有向无环图中三条状态链的根节点，三者表示同一层级的逻辑关系。同时根据线程之间的依赖关系，如图中的A1节点和A2节点均为依赖于根节点A的从节点，而A2节点又依赖于A1节点，以此类推，进而A节点、A1节点和A2节点就形成了一条状态链。在本申请中，每一条状态链之间的持久化操作互不影响，可以独立运作。可以理解的，图中展示的三条状态链和相关节点均是为了方便说明本实施例，并不代表实际构建的有向无环图的的实际容量，具体可以根据实际情况进行设置。本申请通过构建有向无环图，将该图结构作为每一条状态链持久化的通知顺序，从而有助于在有计算依赖的金融数据的场景下，保证每一个层级状态的一致性，尽量避免了已计算的数据被重复计算的可能性，从而有助于减少不必要的计算开销，提高了数据处理的效率。同时，采用状态链的方式，有效地提高了状态的保存性能，有助于实现实时持久化的效果。

[0119] S314：基于有向无环图，对状态后端进行持久化处理。

[0120] 具体地，根据构建得到的有向无环图，对该状态后端中的标准化金融数据和当前数据状态进行持久化处理。

[0121] 进一步地，请参阅图7，在步骤S314中，即基于有向无环图，对状态后端进行持久化处理，具体包括：

[0122] S3141：基于有向无环图，通过消息队列将标准化金融数据和当前数据状态广播到有向无环图的每一条状态链中对应的根节点中。

[0123] 具体地，基于上述构建得到的有向无环图，通过消息队列将状态后端中标准化金融数据和当前数据状态广播至有向无环图中每一条状态链的根节点中，通过并行对每一条状态链执行持久化操作，使每一条状态链中各个节点对应的线程彼此相互通知，以实现每一个线程状态的持久化操作。可以理解的，线程状态的持久化操作可以是线程状态的更新操作。

[0124] S3142：根据标准化金融数据和当前数据状态，并行对根节点下的每一个节点中的算子状态进行状态更新，并将更新后的状态发送至全局注册中心进行保存。

[0125] 在本实施例中，算子状态是指数据有前后依赖关系的线程任务的状态，用于表示当前线程运行的数据状态。

[0126] 具体地，根据状态后端中标准化金融数据和当前数据状态，并行对每一条状态链下的各个节点中的线程的算子状态进行状态更新，并将每一条状态链更新后的状态发送至全局注册中心进行缓存。

[0127] 进一步地，请参阅图8，在步骤S30中，即在持久化处理完成后生成相应的检查点数据文件，具体包括：

[0128] S321：当有向无环图中的所有节点的算子状态更新完成后，根据全局注册中心的全局状态生成相应的检查点数据文件。

[0129] 具体地，当上述构建的有向无环图中的所有节点的算子状态更新完成后，根据全局注册中心的全局状态生成相对应的检查点数据文件。可以理解的，全局注册中心的全局状态可以是在全局注册中心缓存的所有状态链中的每一个节点更新后的对应的状态。

[0130] S322：将检查点数据文件存储到本地文件系统中。

[0131] 具体地，将上述生成的检查点数据文件存储到本地文件系统中。为了节约降低生成成本，本地文件系统可以采用传统的机械硬盘，传统的机械硬盘相比起 SSD（固态硬盘），其寿命更高，成本更低。可以理解的，在网络线路通信方面，针对大状态的金融数据存储，可以采用万兆光纤互联作为大状态数据存储的通信方式，有助于降低通信成本，提高数据传输效率，并满足对高速、高带宽、低延迟的需求。

[0132] 进一步的，在上述的检查点数据文件尚未存储到本地文件系统中前，可以将状态后端中相应的数据缓存在额外的分布式内存组件中，从而有助于尽量避免存储器的存储错误，提高数据存储的稳定性和可靠性。同时，通过将数据暂时缓存在内存中，可以更快地响应查询请求，并有助于减少数据丢失的风险。

[0133] 进一步的，可以将生成的历史检查点数据存储文件异地转储到状态后端之外的冷备份存储组件中进行归档，在需要进行金融数据场景下的盘后分析时，如进行时间序列分析、趋势预测和风险管理等操作时，分析人员可以轻松获取并使用相关的存储文件，在分析进程中快速打开状态后端，从而降低了数据存储的开发成本。同时，通过将相关的检查点数据文件归档到冷备份存储组件，可以对本地文件系统的历史检查点数据文件进行选择性删除，保留最新生成的检查点文件，以节省存储空间，同时不仅能够有效地保护和保存金融数据，还能够提供便捷的访问和利用方式，为金融分析和决策提供了有力的支持。这种方法不仅提高了数据的安全性、灵活性和可靠性，还能够节约成本并提高数据的利用价值。可以理解的，上述冷备份指的是离线备份。

[0134] S40：当列式存储引擎中的服务节点发生服务异常时，加载最新的检查点数据文件对服务节点进行重启恢复。

[0135] 具体的，当列式存储引擎发生服务异常时，对异常的服务节点进行故障转移，在另一个容器节点中对该异常的服务节点进行重启，可以有效地对异常服务节点进行隔离，提高其他服务节点的安全性，读取本地文件系统中最新生成的检查点数据文件进行状态重置并重放数据，将数据加载到正确的位置，以实现对异常服务节点的恢复，同时，由于状态存储在列式存储引擎中，有助于此时异常的服务节点的重启可能只需要秒级就能启动完毕，不会因为服务节点内部数据损坏而导致无法恢复，且对于此时的用户对该服务节点的数据请求，会暂时将该请求阻塞在网关总线上，由网关总线将该数据请求转移到新的服务节点上，从而通过协同网关在故障机制下局部降级，有助于保证在集群高并发下场景下，降低造成集群雪崩的概率。可以理解的，上述的容器节点可以表示为一台机器，该机器可以为服务器计算机、客户端计算机、个人计算机（PC）等，具体在此不作限制。可以理解的，在分布式系统中，基于分布式理念，所有机器作为一个容器，而每一个机器可以作为一个容器节点协同完成用户的请求任务。

[0136] 进一步地，在加载最新的检查点数据文件对异常的服务节点进行重启恢复前，可以从元数据中获取数据块的位置索引和类型，根据数据块的位置索引和类型，预先分配与该数据块的内存结构和内存大小。可以理解的，上述元数据可以包括金融数据的位置索引、类型和检查点文件对应的版本信息，主要用于标识金融数据的存放位置和类型和标记对应的生成的检查点文件的版本信息。通过提前对获取到的待重放的数据块的存放位置和类型，并据此预先分配相关的内存结构和大小，进而有助于在加载检查点数据文件对异常的服务节点进行重启恢复时，并发加载要重放数据的数据块，进而可以尽量避免在加载检查点数据文件过程中频繁地进行内存分配和释放操作，提高了加载的效率，从而有助于实现异常节点的高效恢复。

[0137] 通过采用上述技术方案，通过将待存储的金融数据进行处理后存储到列式存储引擎的状态后端中，更新其状态后端中对应的数据状态，并设置检查点的触发周期，对状态后端中的金融数据及其数据状态进行周期性的持久化处理，且在持久化处理完成后生成相应的检查点数据文件。当列式存储引擎中的服务节点发生服务异常时，进而可以从本机的文件系统中加载最新生成的检查点数据文件对异常的服务节点进行重启恢复，从而有效地避免了采用双设备进行容灾，使得所有设备都能投入到生产使用当中，有助于降低设备成本和降低设备冗余，提升集群的可用性和提高每个服务节点资源的利用率。同时，由于金融数据及其状态存储在列式存储引擎中，有助于在服务节点故障时实现毫秒级重启，从而有助于保证集群在高并发的金融场景下，降低集群雪崩的可能性。

[0138] 本申请提供了一种可应用于金融分析场景的技术方案，通过以上具体实施方式，有助于实现对金融数据持久化存储以及当服务节点发生异常时，可以基于本申请的快速恢复机制进行重启恢复，进而有助于减少数据丢失的风险，有利于保证金融数据的完整性、准确性和可靠性，从而可以为后续在金融分析场景中的数据处理、风险评估和投资决策等方面，提供有力的数据支持，具有较高的实用性、广泛的应用前景和商业价值。为了更清楚的说明上述实施例，而非对其限制，本申请通过提供上述多种数据结构对金融数据进行封装存储，更有助于满足多样性的金融数据或不同维度的金融数据的存储要求，如待存储的金融数据为股票“XX生物 SZXXXXXX”在2023年1月1日的开盘价（100）、收盘价（120）、最高价（130）、最低价（90）和平均价（110）等数据时，可以基于该金融数据的特性和基于列式存储原则，进而为每一金融数据所形成的列结构选择合适的数据结构对每一金融数据进行存储。例如对某一列结构：“XX生物 XXXXXXXA”，进而可以根据与该数据类型选择合适的数据结构进行封装。可以理解的，此处的X并非指特定的字符，X可根据实际情况表示任意单个或多个字符。

[0139] 进一步地，本申请通过设定检查点的触发周期，定期对状态后端中的金融数据及其数据状态进行持久化操作，并生成相应的检查点数据文件，进而有利于当集群内的服务节点发生服务异常时可以基于最新生成的检查点进行重启恢复，将相应的数据快速地加载到正确的位置，有助于减少数据的丢失，并通过协同网关在故障机制下局部降级，有助于保证在集群高并发下场景下，以快速响应客户的请求，降低造成集群雪崩的概率，从而可以极大地满足金融领域中的数据分析和决策支持的需求。当用户需要对金融分析场景下的数据进行盘后分析时，即进行时间序列分析、趋势预测和风险管理等操作时，一方面，用户可以通过请求获取状态后端中的金融数据的历史记录和实时更新的金融数据，以支持时间序列分析和趋势预测，进而可以利用这些数据进行统计分析、模型建立和预测，以揭示数据中的潜在规律和趋势；另一方面，用户还可以通过获取并使用相关的存储文件，在分析进程中快速打开状态后端，对状态后端进行监控和可视化，以更直观地观察数据的特征和趋势，这样，用户可以更好地理解数据的具体化，发现潜在的投资机会或风险，并做出相应的决策。

[0140] 进一步地， 本申请通过对金融分析场景中的股票数据进行例子说明，进一步展示了上述实施方式的适用性和优势，以便更清晰的理解本申请的技术方案，而非对其限制。在存储股票数据方面，用户可以根据实际要存储的股票数据情况进行上述数据结构的选择。例如根据股票的价格、成交量、市值、财务指标等各种数据的类型选择相应的数据结构进行存储到状态后端中，有利于全面满足用户对不同股票数据的存储需求；在股票数据处理方面，根据设定的检查点触发周期，定期对状态后端中的数据进行持久化操作，并生成相应的检查点数据文件，有利于实现对股票数据的持久化存储；在集群内的服务节点发生服务异常方面，系统可以基于最新生成的检查点进行重启恢复，由于这些股票数据的状态存储在列式引擎中，有助于提高异常服务节点的重启恢复的速度，从而有助于实现异常服务节点的毫秒级重启，并在加载检查点文件对异常服务节点进行重启恢复前，提前对获取到的待重放的数据块的存放位置和类型，并据此预先分配相关的内存结构和大小，进而可以在加载最新的检查点数据时并发加载要重放数据的数据块，从而有助于快速地将股票数据恢复到正确的位置，有助于满足资深股民在炒股时对每支股票的实时性获取需求；在盘后分析方面，在对股票数据进行盘后分析时，由于本申请采用了列式存储的存储策略并基于分布式理念，进而有助于加快了对数据查询请求的响应，从而有助于用户实时获取状态后端中的实时股票行情数据，这些数据可以包括最新的股票价格、涨跌幅、成交量等信息，有利于帮助客户利用这些数据来判断买入和卖出的时机，便于资深股民及时了解每支股票的实时动态的情况；在数据监控和可视化方面，用户可以通过获取相关的股票的检查点文件，在知悉高层封装的容器结构后，可以在分析过程中快速打开状态后端，对状态后端中的股票数据进行监控和可视化。通过可视化工具，用户可以将股票数据以图表、图形等形式展示，以便更直观地观察到每一支股票的特征和涨跌幅趋势，以支持股民的决策制定。

[0141] 应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

[0142] 在一实施例中，提供一种一种金融数据的异常容灾系统，该一种金融数据的异常容灾系统与上述实施例中一种金融数据的异常容灾方法一一对应。如图9所示，该一种金融数据的异常容灾系统包括数据处理模块、状态更新模块、数据保存模块和数据异常恢复模块。各功能模块详细说明如下：

[0143] 数据处理模块，用于基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据；

[0144] 状态更新模块，用于根据标准化金融数据的数据状态，对状态后端中的数据状态进行更新，得到当前数据状态；

[0145] 检查点触发周期设定模块，用于设定检查点的触发周期；

[0146] 数据保存模块，用于当检查点被触发时，基于标准化金融数据和当前数据状态，对状态后端进行持久化处理并在持久化处理完成后生成相应的检查点数据文件；

[0147] 数据异常恢复模块，用于当列式存储引擎发生服务异常时，加载最新的检查点数据文件进行重启恢复。

[0148] 可选地，数据处理模块包括：

[0149] 数据结构选择模块，用于根据待存储的金融数据的数据类型，选择与数据类型相匹配的数据结构；

[0150] 数据封装模块，用于将选定数据结构的金融数据封装为后端状态对象；

[0151] 数据判断模块，用于根据后端状态对象的数据状态，从列式存储引擎的状态后端中获取与后端状态对象的数据状态相对应的数据状态，判断两者数据状态是否一致；

[0152] 第一数据执行模块，用于若两者数据状态一致，则跳过本次写入操作；

[0153] 第二数据执行模块，用于若两者数据状态不一致，则将状态对象写入到状态后端中。

[0154] 可选的，第二数据执行模块包括：

[0155] 数据转换模块，用于将后端对象序列化成二进制数据；

[0156] 空间判断模块，用于判断二进制数据的预留空间是否充足；

[0157] 第一数据写入模块，用于若预留空间充足，则将二进制数据写入到预留空间对应的存储位置中以形成一个数据块，并更新二进制数据在该数据块的位置索引；

[0158] 第二数据写入模块，用于若预留空间不充足，则重新分配新的存储空间，并将预留空间对应的存储位置标记为不可用，将二进制数据写入到新的存储空间对应的存储位置中以形成一个数据块，更新二进制数据在该数据块的位置索引。

[0159] 可选的，数据保存模块包括：

[0160] 线程注册模块，用于基于标准化金融数据和当前数据状态，将状态后端中与标准化金融数据和当前数据状态相对应的线程注册到全局注册中心中；

[0161] 状态链生成模块，用于从全局注册中心中获取线程的注册顺序和依赖关系，根据注册顺序和依赖关系，将有依赖关系的线程按注册顺序进行排列，以形成若干条状态链，其中，状态链中的节点用于表示线程，两个节点之间具有方向的边用于表示线程之间的依赖关系；

[0162] 有向无环图构建模块，用于根据状态链的逻辑关系，构建得到有向无环图，其中，有向无环图包括列式存储引擎，全局注册中心和至少一条状态链；

[0163] 数据持久化模块，用于基于有向无环图，对状态后端进行持久化处理。

[0164] 可选的，数据持久化模块包括：

[0165] 消息通知模块，用于基于有向无环图，通过消息队列将标准化金融数据和当前数据状态广播到有向无环图的每一条状态链中对应的根节点中；

[0166] 信息缓存模块，用于根据标准化金融数据和当前数据状态，并行对根节点下的每一个节点中的算子状态进行状态更新，并将更新后的状态发送至全局注册中心进行保存。

[0167] 可选的，数据保存模块还包括：

[0168] 文件生成模块，用于当有向无环图中的所有节点的算子状态更新完成后，根据全局注册中心的全局状态生成相应的检查点数据文件；

[0169] 文件归档模块，将检查点数据文件存储到本地文件系统中。

[0170] 可选的，数据异常恢复模块包括：

[0171] 数据恢复预处理模块，用于从检查点数据文件中获取元数据，从元数据中获取数据块的位置索引和类型；

[0172] 内存分配模块，用于根据数据块的位置索引和类型，分配与数据块的内存结构和内存大小。

[0173] 关于一种金融数据的异常容灾系统的具体限定可以参见上文中对于一种金融数据的异常容灾方法的限定，在此不再赘述。上述一种金融数据的异常容灾系统中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

[0174] 在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图10所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种金融数据的异常容灾方法。

[0175] 在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

[0176] 基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据；

[0177] 根据标准化金融数据的数据状态，对状态后端中的数据状态进行更新，得到当前数据状态；

[0178] 设定检查点的触发周期，当检查点被触发时，基于标准化金融数据和当前数据状态，对状态后端进行持久化处理并在持久化处理完成后生成相应的检查点数据文件；

[0179] 当列式存储引擎中的服务节点发生服务异常时，加载最新的检查点数据文件对服务节点进行重启恢复。

[0180] 在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

[0181] 基于列式存储引擎的状态后端中的数据状态，对待存储的金融数据进行数据处理，得到标准化金融数据；

[0182] 根据标准化金融数据的数据状态，对状态后端中的数据状态进行更新，得到当前数据状态；

[0183] 设定检查点的触发周期，当检查点被触发时，基于标准化金融数据和当前数据状态，对状态后端进行持久化处理并在持久化处理完成后生成相应的检查点数据文件；

[0184] 当列式存储引擎中的服务节点发生服务异常时，加载最新的检查点数据文件对服务节点进行重启恢复。

[0185] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器（ROM）、可编程ROM（PROM）、电可编程ROM（EPROM）、电可擦除可编程ROM（EEPROM）或闪存。易失性存储器可包括随机存取存储器（RAM）或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM（SRAM）、动态RAM（DRAM）、同步DRAM（SDRAM）、双数据率SDRAM（DDRSDRAM）、增强型SDRAM（ESDRAM）、同步链路（Synchlink） DRAM（SLDRAM）、存储器总线（Rambus）直接RAM（RDRAM）、直接存储器总线动态RAM（DRDRAM）、以及存储器总线动态RAM（RDRAM）等。

[0186] 所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

[0187] 以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。