CN107438092B - 用于分布式场景中数据处理的方法和设备 - Google Patents

Abstract

本申请的目的是提供一种用于分布式场景中数据处理的方法和设备，通过主设备获取本地提交的第一请求信息，并基于所述第一请求信息创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；所述主设备通过异步复制通道向从设备发送所更新的主区业务数据；当所述主设备不可服务时，所述从设备获取所述主设备对应的第一请求信息，并基于所述第一请求信息创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；保护了应用系统不受由于多地同时写带来的数据损坏的问题，从而确保了在多地同时修改的场景下，能保持数据正确性和最终一致性。

Description

用于分布式场景中数据处理的方法和设备

技术领域

本申请涉及计算机领域，尤其涉及一种用于分布式场景中数据处理的技术。

背景技术

信息化进程不断加快的今天，互联网向更宽更广方向发展，各行各业的业务越来越多，当业务的规模扩大到跨地域甚至全球范围时，业务数据通常需要在多地之间复制。城际之间的网络延迟通常在数十毫秒以上，如果采用同步复制的方式，用户的体验将会大打折扣，并且同步复制会降低系统整体的可用性。因此，目前一般采用异步复制，但异步复制使得数据在多地之间产生冲突从而导致数据一致性被破坏。

Paxos是一种基于消息传递的一致性算法，被大量应用在分布式计算领域，其目的在于如何就某一个决议达成一致性。但Paxos的吞吐量低，一个决议必须在多数参与者确认后才能提交，网络时延高。另外，目前的一些数据传输设施，虽提供了数据的异地复制，但不能控制由于数据丢失带来的经济损失且数据只能在一地写。

发明内容

本申请的目的是提供一种于分布式场景中数据处理的方法与设备，以解决在多地同时修改的场景下，数据的正确性和一致性的问题。

根据本申请的一个方面，提供了一种在主设备端用于分布式场景中数据处理的方法，包括：

获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区均为主设备所在区；

通过异步复制通道向从设备发送所更新的主区业务数据；

在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；

当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新。

根据本申请的一个方面，提供了一种在从设备端用于分布式场景中数据处理的方法，包括：

接收并存储主设备通过异步复制通道发送的所更新的主区业务数据；

当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；

当所述主设备恢复完成后，不再获取所述第一请求信息。

根据本申请的另一个方面，提供了一种在分布式系统中用于分布式场景中数据处理的方法，其中，所述方法包括：

主设备获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；

所述主设备通过异步复制通道向从设备发送所更新的主区业务数据；

当所述主设备不可服务时，所述从设备获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

在所述主设备不可服务后进行恢复期间，所述从设备通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备，所述主设备更新本地存储的所述主区业务数据；

当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，所述主设备重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，所述从设备不再获取所述第一请求信息。

根据本申请的再一方面，还提供了一种用于分布式场景中数据处理的主设备，包括：

获取装置，用于获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；

第一发送装置，用于通过异步复制通道向从设备发送所更新的主区业务数据；

更新装置，用于在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；

恢复装置，用于当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新。

根据本申请的再一方面，还提供了一种用于分布式场景中数据处理的从设备，包括：

接收装置，用于接收并存储主设备通过异步复制通道发送的所更新的主区业务数据；

处理装置，用于当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

第二发送装置，用于在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；

停止获取装置，用于当所述主设备恢复完成后，不再获取所述第一请求信息。

根据本申请的再一方面，还提供了一种用于分布式场景中数据处理的系统，其中，所述系统包括：主设备和从设备；

其中，所述主设备包括：

获取装置，用于获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；

第一发送装置，用于通过异步复制通道向从设备发送所更新的主区业务数据；

更新装置，用于在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；

恢复装置，用于当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新；

所述从设备包括：

接收装置，用于接收并存储所述主设备通过异步复制通道发送的所更新的主区业务数据；

处理装置，用于当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

第二发送装置，用于在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；

停止获取装置，用于当所述主设备恢复完成后，不再获取所述第一请求信息。

此外，本申请还提供了一种用于分布式场景中数据处理的主设备，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区均为主设备所在区；

通过异步复制通道向从设备发送所更新的主区业务数据；

在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；

当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新。

此外，本申请还提供了一种用于分布式场景中数据处理的从设备，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

接收并存储主设备通过异步复制通道发送的所更新的主区业务数据；

当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；

当所述主设备恢复完成后，不再获取所述第一请求信息。

此外，本申请还提供了一种用于分布式场景中数据处理的系统，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

主设备获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；

所述主设备通过异步复制通道向从设备发送所更新的主区业务数据；

当所述主设备不可服务时，所述从设备获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

在所述主设备不可服务后进行恢复期间，所述从设备通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备，所述主设备更新本地存储的所述主区业务数据；

当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，所述主设备重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，所述从设备不再获取所述第一请求信息。

与现有技术相比，根据本申请实施例的方法和设备，通过主设备获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；接着，所述主设备通过异步复制通道向从设备发送所更新的主区业务数据；当所述主设备不可服务时，所述从设备获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；保护了应用系统不受由于多地同时写带来的数据损坏的问题，从而确保了在多地同时修改的场景下，能保持数据正确性和最终一致性。

进一步地，在所述主设备不可服务后进行恢复期间，所述从设备通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备，所述主设备更新本地存储的所述主区业务数据；在主设备不可服务时进行主备切换，当主设备恢复服务时，将从设备中请求归属区为主设备所在区对应的所更新的主区业务数据发送至主设备，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，完成数据的回迁，进而使得当故障发生时，受影响的数据面变窄，整体可用性提高。

更进一步地，获取所述从设备所发送的接收到所更新的主区业务数据的确认信息；以获取到所述确认信息的时间为起点且恢复目标时长为时间长度，更新发送窗口期限，提供了一种明确的恢复目标点保证，使得业务方能基于此评估数据丢失可能带来的风险。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出根据本申请一个方面的一种用于分布式场景中数据处理的主设备的结构示意图；

图2示出根据本申请一个方面的一个优选实施例的获取装置11的结构示意图；

图3示出根据本申请一个方面的一种用于分布式场景中数据处理的从设备的结构示意图；

图4示出根据本申请一个方面的一种用于分布式场景中数据处理的系统结构示意图；

图5示出根据本申请一个方面的一种用于分布式场景中数据处理的系统服务架构示意图；

图6示出根据本申请另一个方面的一种在主设备端用于分布式场景中数据处理的方法流程示意图；

图7示出根据本申请另一个方面的一个优选实施例的步骤S11的流程示意图；

图8示出根据本申请另一个方面的一种在从设备端用于分布式场景中数据处理的方法流程示意图；

图9示出根据本申请另一个方面的一种用于分布式场景中数据处理的系统方法流程示意图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

图1示出根据本申请一个方面的一种用于分布式场景中数据处理的主设备的结构示意图。所述主设备1包括：获取装置11、第一发送装置12、更新装置13和恢复装置14。其中，获取装置11获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区均为主设备所在区；第一发送装置12通过异步复制通道向从设备发送所更新的主区业务数据；更新装置13在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；恢复装置14当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新。

在此，当所述主设备发生不可服务时，所述从设备会暂时获取主设备所在地提交的第一请求信息，并基于所述第一请求信息继续更新从设备所存储的主区业务数据，其中，禁止修改不可合并类型的主区业务数据类型以避免不可合并类型的主区业务数据因异地修改而发生数据冲突。

在此，所述主设备1包括但不限于用户设备、或用户设备与网络设备通过网络相集成所构成的设备。所述用户设备其包括但不限于任何一种可与用户通过触摸板进行人机交互的移动电子产品，例如智能手机、PDA等，所述移动电子产品可以采用任意操作系统，如android操作系统、iOS操作系统等。其中，所述网络设备包括一种能够按照事先设定或存储的指令，自动进行数值计算和信息处理的电子设备，其硬件包括但不限于微处理器、专用集成电路(ASIC)、可编程门阵列(FPGA)、数字处理器(DSP)、嵌入式设备等。所述网络包括但不限于互联网、广域网、城域网、局域网、VPN网络、无线自组织网络(Ad Hoc网络)等。优选地，主设备1还可以是运行于所述用户设备、或用户设备与网络设备、触摸终端或网络设备与触摸终端通过网络相集成所构成的设备上的脚本程序。当然，本领域技术人员应能理解上述主设备1仅为举例，其他现有的或今后可能出现的主设备1如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

上述各装置之间是持续不断工作的，在此，本领域技术人员应理解“持续”是指上述各装置分别实时地或者按照设定的或实时调整的工作模式要求，例如所述获取装置11持续获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新；第一发送装置12持续通过异步复制通道向从设备发送所更新的主区业务数据；更新装置13持续在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；恢复装置14当所述主设备恢复完成后，持续重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，直至所述主设备1完成确认请求用户身份工作或停止工作。

本申请一实施例所述主设备1用于分布式场景中数据处理，对数据是否可合并进行区别处理，标记不可合并类数据的写入区和请求归属区为主设备所在区，使得应用系统不受由于多地同时写带来的数据损坏问题。

具体地，获取装置11获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区。

在一具体实施例中，区域A中的用户将用户请求(如创建订单)提交至区域A的服务器的请求信息为第一请求信息，根据所获取的创建订单请求信息对本地存储的该订单数据进行更新，即更新包括将订单中包含的下单用户个人信息、地址信息、订单内容、物流信息等进行创建和修改等写信息存储在本地。主区业务数据是指基于该第一请求信息创建的数据，优选地为主设备所在区的用户提交的业务请求所创建的数据。当一条不可合并类型类数据被首次创建时，其写入区和请求归属区设定为当前地域，即每份数据的写入区和请求归属区与地理位置信息有关，该地理位置信息是指数据中心的标示符，而不是经纬度坐标，例如，部署在杭州的数据中心的标示符是HZ。进一步的，写入区表示在允许修改该数据的所在地域，数据在非写入区是禁止修改的，同时同一时间全局最多只有一个地域是该数据的写区。请求归属区表示数据经常在该地被修改，即数据的使用者常驻此地。需要说明的是，写入区和请求归属区与不可合并类型的每条数据相对应，不是与数据类对应，每条不可合并类的数据都有自己的写入区和请求归属区，同一种数据类的数据的写入区和请求归属区可以不同。

具体地，第一发送装置12通过异步复制通道向从设备发送所更新的主区业务数据。

在此，为了不给用户造成过高的时延，跨地域之间通常选择异步方式进行数据复制。异步复制不会阻塞用户的写请求，所以用户的请求会先提交，第一发送装置12基于获取装置11获取到的第一请求信息根据既定的策略将请求以增量变更的形式复制至从设备中，其中，增量变更的形式优选为log形式(日志形式)。

具体地，更新装置13在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据。

在一具体实施例中，例如，主设备所在区为杭州，用户的订单在杭州创建，称为数据A，其中，数据A为主区业务数据，其写入区和请求归属区都为杭州，从设备所在区为上海，对于从杭州获取来的数据A只能读不能写；当杭州的服务器主设备发生灾难不可服务时，在上海的从设备获取用户的请求信息，创建新的订单，称为数据B，则数据B包括根据杭州用户所提交的请求创建订单的数据集B1和上海本地用户所提交的请求创建订单的数据集B2，其中，数据集B1为杭州用户的订单为临时在上海进行写的数据，其写入区为上海但请求归属区为杭州，而数据集B2的写入区和请求归属区都为上海。当主设备服务恢复后，主设备所在区为杭州的本地存储的主区业务数据更新为数据A和数据集B1。

需要说明的是，上述实施例所述主设备和从设备用于两地之间的数据处理的设备，所述设备还可以应用于多地之间的数据处理；其中，主设备对应若干从设备，各设备分布在不同的地域中，且主设备与从设备的服务之间为对等的同时互为主备。

具体地，恢复装置14当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新。

在此，主设备服务恢复完成后，进行正常工作，而在主设备服务不可用期间临时在从设备写的数据集需迁回主设备，并将这部分数据集的写入区由从设备所在区更新为主设备所在区。例如，继续接前例，在本申请上述具体实施例中，主设备所在区为杭州，从设备所在区为上海，当杭州服务器恢复进行正常工作后，需要将杭州用户临时迁移到上海异地写的数据集回迁至杭州，即根据“请求归属区为杭州，写入区为杭州”确定待回迁的数据集，即确定待回迁的数据集为数据集B1并将其迁至杭州以满足就近服务的原则。在上海的从设备需要禁写这部分数据集B1，在杭州的主设备接收在上海的从设备通过异步复制通道所发送的数据集B1；接着，等待这部分数据向杭州的异步复制至稳态，即两地的版本完全一致，将这部分数据集B1的写入区更新为杭州。需要说明的是，上述主设备所在区为杭州，从设备所在区为上海仅为本申请一实际场景的具体实施例，并不用以限制本申请。另外，本地提交的第一请求信息提交至主设备，不需要再提交至其他设备进行处理，主设备基于所获取的请求对本地存储的主区业务数据进行更新。例如，主设备所在区的用户创建了100个订单后主设备发生服务不可用问题，所在区的用户又新创建的100个订单的请求根据就近服务原则提交至从设备，当主设备服务恢复后，主设备截获所在区的用户再次创建订单的提交请求，对本地存储的数据进行更新。

优选地，所述获取装置11包括：获取单元111、解析单元112和处理单元113。如图2示出的根据本申请一个方面的一个优选实施例的获取装置11的结构示意图；其中，获取单元111获取所述第一请求信息；解析单元112解析所述第一请求信息所请求处理的主区业务数据的数据信息，所述数据信息包括：数据类型、操作类型和/或相关区域信息，其中，所述数据类型包括可合并类型和不可合并类型，所述操作类型包括创建操作和修改操作，所述相关区域信息包括写入区和请求归属区；处理单元113根据所述第一请求信息所请求处理的主区业务数据的数据信息，对所述主区业务数据进行更新。

在实际场景中，跨地域之间通过异步方式进行数据复制时，用户的请求会先提交，如果此时对端数据也发生了变化，当收到异步传输来的数据时，对端将会面临数据冲突的可能，在两地同时修改数据是造成这一问题的原因之一。在很多情况下，系统要求数据能在两地同时修改，例如用户从某地迁移到另外某地，或者某地服务中断，需要将流量迁移到异地等。因此，解决异步复制带来的数据冲突问题变得尤为关键。通常业务数据都是复杂多样的，在大多数业务系统中，不同类型的数据，在其版本变更发生分支后，对其合并策略的要求也不同。以在线交易系统为例，用户的订单列表如果在两地同时修改(各自创建新订单)，如果能保证创建的订单ID不会冲突，那么对这两个订单列表做集合并运算。再例如，用户的基本信息(如：昵称、生日和地址等)，如果在两地发生修改，我们可以根据修改的时间戳来处理冲突，以晚修改的版本覆盖早修改的版本。然而，另外一类数据则是无法接受两地同时修改的，譬如订单的交易状态信息，它记载了订单状态的变迁过程，每一步都是基于前一步演变而来的，如果在两地同时发生修改，不考虑某些业务数据的特殊性，这类数据是无法被合并的。鉴于此，主设备获取第一请求信息后要对主区业务数据进行解析获得数据类型、操作类型和/或操作类型信息，其中，操作类型是指该数据是需要创建新数据的创建操作还是对已有数据进行修改得到新数据的修改操作。

在本申请的一优选实施例中，解析单元112解析所述第一请求信息所请求处理的主区业务数据的数据信息，根据解析结果，对于能够被自动合并的数据采用上述自动合并算法保证合并之后的状态一致，不必要求变更的历史完全一致进行解决数据冲突问题。从而使得写请求在何地提交变得不再重要(不考虑性能因素)，最终都会得到一致的结果，所以当某地服务出现不可用时，可以迅速切换到异地继续服务，极大提高系统可用性。对于不可合并数据，提供每份数据的与地理位置有关的写入区和请求归属区信息。当一个数据实体被首次创建时，写入区和请求归属区就设定为当前地域。数据实体在写入区被修改后，改动会被异步复制到其他的备份区，备份区收到复制副本后会在本地提交。需要说明的是，此时该数据在备份区中的写入区和请求归属区仍保持未变，因此在备份区该数据是禁止修改的。正常情况下请求归属区和写入区同为数据的创建区，只有到发生主备切换的时候，写入区才会变化，当发生请求归属区迁移时，请求归属区才会发生变化。通过上述设置不可合并类数据的写入区和请求归属区对不可合并类数据实施写保护操作进而避免了数据被同时修改。

更优选地，所述处理单元113用于：当所述第一请求信息请求对不可合并类型的主区业务数据进行修改操作时，判断所述不可合并类型的主区业务数据的写入区是否为所述主设备所在区，若否，则禁止修改相应所述不可合并类型的主区业务数据，若是，则修改相应所述不可合并类型的主区业务数据；当所述第一请求信息请求不可合并类型的主区业务数据进行创建操作时，创建相应主区业务数据并标记其写入区和请求归属区为所述主设备所在区；当所述第一请求信息请求对可合并类型的主区业务数据进行创建操作或修改操作时，直接对相应所述主区业务数据进行创建操作或修改操作。

例如，主设备所在区为杭州，在获取杭州的用户进行本地提交请求创建数据实体后，判断该数据实体的数据类别，当为不可合并类数据时，所已创建的数据的写入区为杭州，若是对该已有的数据进行修改操作，则修改相应所述不可合并类型的已创建的数据；从设备所在区为上海，获取从主设备复制而来的数据，因所复制数据的写入区为主设备所在区杭州，则在上海的从设备只能对所复制数据进行读操作不能进行写操作，即禁止修改复制来的相应所述不可合并类型的数据。当用户提交的请求为可合并类型的数据时，直接对该类数据进行创建操作或修改操作。需要说明的是，进行创建操作时，需要满足创建的数据不能覆盖已有的数据，所新创建的数据对应的写入区和归属区的标识符在全局唯一。

优选地，所述主设备还包括：获取确认信息装置15(未示出)和更新窗口期限装置16(未示出)，其中，获取确认信息装置15获取所述从设备所发送的确认信息，所述确认信息包括确认接收到所更新的主区业务数据；更新窗口期限装置16以获取到所述确认信息的时间为起点且恢复目标时长为时间长度，更新发送窗口期限。

在实际应用中，异步复制在数据中心发生严重灾难时，可能丢失数据的增量更新。不同类型的业务系统对数据丢失的可接受程度是不一样的，例如，金融系统和在线交易系统对数据丢失是极为敏感的，而电商网站可能勉强能接受。然而，没有一种系统能保证100％不丢失数据，在这种情况下，本申请中所述主设备提供明确的RPO，使得业务方能基于此评估由于数据丢失而带来的经济损失和法律风险。在具体实施例中，主设备的发送端本地维持一个发送窗口，起于上一次从设备的接收端确认的时间点，即所确认的消息包(Packet)在发送端的提交时间点，长度固定为RPO，只要当前时间仍在发送窗口之内，新的业务请求就允许在本地提交，然后经由数据传输通道异步复制给从设备的接收端。接收端收到数据后，经由某种途径向发送端报告Packet的确认信息(例如Packet ID)，获取确认信息装置15收到确认信息后，更新窗口期限装置16将发送窗口向未来平移一定距离，使得窗口开始于所确认Packet的发送时间。例如，在一具体实施例中，主设备所在区为杭州，从设备所在区为上海，杭州用户在杭州提交的一条数据请求创建数据实体后异步复制到上海，上海的从设备向主设备反馈确认信息，主设备收到确认信息的时刻为t，杭州本地维持一个发送窗口，长度为RPO，则起始点为t时刻，只要当前时间在t～t+RPO之间，则新的主区业务数据请求就允许在杭州本地提交，然后异步复制给所在上海的从设备，从设备收到异步复制的数据后发送确认信息，所在杭州的主设备接收到确认信息的时刻为t2(t2>t)，则主设备的发送端的发送窗口进行平移一定距离，由原来的t～t+RPO变为t2～t2+RPO。这样保证数据的丢失的时间不超过RPO，提供了明确的RPO保证。

本领域技术人员应能理解，上述RPO(Recovery Point Objective，恢复点目标)是指因硬件、程序或通信发生故障，而导致的计算机、系统或网络出现故障时，必须从备份存储中恢复以保证系统正常运行的文件的时长，是一种用于衡量故障恢复后数据丢失的最大限量指标。

本领域技术人员应能理解，上述主设备所在区为杭州，从设备所在区为上海仅为举例，只需主设备所在区和从设备所在区满足跨地域即可；上述确认发送窗口的方法仅为本申请一具体实施例，对本申请所述获取到所述确认信息的时间为起点且恢复目标时长为时间长度，更新发送窗口期限的方法进行详细描述，当然，现有或今后可能出现的适合本申请确认发送窗口的方法，均可以引用的方式包含于本申请。

优选地，所述获取确认信息装置15(未示出)判断当前时间是否在所述发送窗口期限内，若是，则通过异步复制通道向所述从设备发送所更新的主区业务数据，若否，则等待所述确认信息。

接上述实施例，若当前时间在发送窗口期限内，即在t～t+RPO之间，则所更新的主区业务数据请求就允许在杭州本地提交，然后异步复制给所在上海的从设备，若不在发送窗口期限内，则所在杭州的主设备的发送端等待从设备所发送的确认信息。

图3示出根据本申请一个方面的一种用于分布式场景中数据处理的从设备的结构示意图。所述从设备2包括：接收装置21、处理装置22、第二发送装置23和停止获取装置24。其中，接收装置21接收并存储主设备通过异步复制通道发送的所更新的主区业务数据；处理装置22当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为第二区、请求归属区为第一区，并禁止修改不可合并类型的主区业务数据；第二发送装置23在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；停止获取装置24当所述主设备恢复完成后，不再获取所述第一请求信息。

在此，所述从设备2包括但不限于用户设备、或用户设备与网络设备通过网络相集成所构成的设备。所述用户设备其包括但不限于任何一种可与用户通过触摸板进行人机交互的移动电子产品，例如智能手机、PDA等，所述移动电子产品可以采用任意操作系统，如android操作系统、iOS操作系统等。其中，所述网络设备包括一种能够按照事先设定或存储的指令，自动进行数值计算和信息处理的电子设备，其硬件包括但不限于微处理器、专用集成电路(ASIC)、可编程门阵列(FPGA)、数字处理器(DSP)、嵌入式设备等。所述网络包括但不限于互联网、广域网、城域网、局域网、VPN网络、无线自组织网络(Ad Hoc网络)等。优选地，从设备2还可以是运行于所述用户设备、或用户设备与网络设备、触摸终端或网络设备与触摸终端通过网络相集成所构成的设备上的脚本程序。当然，本领域技术人员应能理解上述从设备2仅为举例，其他现有的或今后可能出现的从设备如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

本申请一实施例所述从设备2用于分布式场景中数据处理，当主设备发生服务不可用时，作为主设备的数据备份区接收主设备所切换来的流量，当主设备服务恢复后，禁写之前从主设备临时迁移过来的数据，禁写之后等待增量数据异步复制完成，完成数据的回迁。

具体地，接收装置21接收并存储主设备通过异步复制通道发送的所更新的主区业务数据。

在此，从设备的服务作为主设备的服务的备份存储区，提交至主设备的用户数据异步复制至从设备，从设备接收在主设备中对用户数据进行创建、修改等所更新后的数据后将这些数据进行本地存储，但从设备对所述接收的所更新的数据中的不可合并类数据只能进行读操作，不能对其进行删除、增加写、改正或替换的修改操作。

具体地，处理装置22用于当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据。

在一具体实施例中，例如，主设备所在区为杭州，用户的订单在杭州创建的数据中的不可合并类数据为主区业务数据a，其写入区和请求归属区都为杭州，从设备所在区为上海，对于从杭州获取来的不可合并类的主区业务数据a只能读不能写；当杭州的服务器主设备发生灾难不可服务时，在上海的从设备获取主设备对应的第一请求信息，并基于获取到的第一信息请求创建新的订单数据c，此时，从设备中主区业务数据b包括两部分：从主设备通过异步复制通道复制而来的主区业务数据a和写入区为上海但请求归属区为杭州的新创建的订单数据c，订单数据c为所更新的主区业务数据，是杭州用户创建的订单临时在上海进行写的数据。所更新的主区业务数据中的不可合并类数据只能在从设备所在区进行修改操作，在其他区禁止修改。

具体地，第二发送装置23在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备。

在此，优选地，所述第二发送装置23包括：更新单元(未示出)，用于继续获取所述第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，禁止对不可合并类型的主区业务数据进行修改操作和创建操作。接前例，在上海的从设备获取主设备对应的第一请求信息，并基于获取到的第一信息请求创建新的订单数据c为所更新的主区业务数据，其写入区为上海，请求归属区为杭州；当主设备服务恢复进行正常工作后，通过异步复制通道将订单数据c发送至主设备。

需要说明的是，上述从设备通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备的方法不限于两个地域之间，还可在多个地域之间进行。

具体地，停止获取装置24当所述主设备恢复完成后，不再获取所述第一请求信息。

继续接前例，当从设备将主设备临时在从设备写的数据即订单数据c异步复制发送至主设备，等待增量数据异步复制达到稳态，即两地版本数据一致时，主设备正常获取所在区的用户提交的第一请求信息，从设备不再获取该请求信息，而接收由主设备复制来的数据作为主设备中数据的存储设备对主设备所发送的数据进行备份。

优选地，所述处理装置22还包括：发送确认信息单元(未示出)，用于当接收到所述主设备通过异步复制通道发送的所更新的主区业务数据后，向所述主设备发送确认信息。

在此，主设备的发送端本地维持一个发送窗口，只要当前时间仍在发送窗口之内，新的业务请求就允许在本地提交，然后经由数据传输通道异步复制给从设备的接收端。接收端收到数据后，发送确认信息单元经由某种途径向发送端报告Packet的确认信息(例如Packet ID)。

优选地，所述从设备还包括：从区业务数据更新装置25(未示出)，用于获取本地提交的第二请求信息，并基于所述第二请求信息对本地存储的从区业务数据进行更新，其中，当创建不可合并类型的从区业务数据时，标记其写入区和请求归属区为从设备所在区。

在此，从设备不仅作为主设备中数据的存储备份设备，还作为本地提交数据请求的主区设备，第二请求信息是指本地提交的用户请求数据信息和对主区业务数据进行修改请求，从设备所在区的本地用户提交请求时，从区业务数据更新装置25获取所提交的请求信息并基于请求信息创建数据或修改数据对本地存储的从区业务数据进行更新。例如，从设备所在区为上海，上海用户提交创建订单或修改订单数据请求，从区业务数据更新装置25将创建完的数据实体或修改后的数据进行存储。又如，第二请求信息为对主区业务数据中的可合并类数据进行修改操作(如修改用户昵称、地址等)，从区业务数据更新装置25将修改后的数据进行存储以更新主区业务数据。当根据用户提交的创建请求进行创建数据实体时若为不可合并类数据，则标记所述创建的数据实体的写入区和请求归属区为从设备所在区。

更优选地，所述从区业务数据更新装置25还包括：判断单元(未示出)，用于当所述第二请求信息请求对所述主区业务数据进行修改操作时，判断所述主区业务数据的数据类型，当所述主区业务数据为可合并类型则进行修改操作，当所述主区业务数据为不可合并类型则禁止进行修改操作。

在此，若从设备中从主设备复制而来的主区业务数据为可合并类数据，从设备对所述可合并类数据可进行修改操作，例如，修改用户昵称、地址等；若从主设备复制而来的主区业务数据为不可合并类数据，因所述主区业务数据的写入区为主设备所在区，从设备对其的修改操作为禁止操作。

优选地，所述从设备还包括：标记装置26(未示出)，用于将所接收并存储的所述主设备通过异步复制通道发送的所更新的主区业务数据标记为不再转发数据。

在此，为避免数据被重复往返地复制，发送端只发送在本地提交的改动，接收端不会将收到的复制数据再进行转发。当服务所在地域的数目超过3个以上时，转发会导致同一份数据被同一个接收端接收多次，产生正确性问题。因此，发送端将待复制的数据分别发给每个接收端。从设备作为主设备复制数据的接收端，在接收并存储主设备所发送来的主区业务数据后不再将主区业务数据再转发给其他设备。

图4示出根据本申请一个方面的一种用于分布式场景中数据处理的系统结构示意图。所述系统包括：主设备1和从设备2；其中，所述主设备1包括：获取装置11、第一发送装置12、第一更新装置13和第二更新装置14；所述从设备2包括：接收装置21、处理装置22、第二发送装置23和停止获取装置24。

本领域技术人员应当能够理解，具有主设备1和从设备2的系统，或具有主设备、若干从设备的系统，以实现用于分布式场景中数据处理的方案均包含于本申请请求保护的范围之内。

在此，所述主设备1可以与若干从设备2配合工作，主设备与从设备分布在不同的地域，若干从设备分布在不同的地域中，具体地，获取装置11获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；第一发送装置12通过异步复制通道向从设备发送所更新的主区业务数据；接收装置21接收并存储所述主设备通过异步复制通道发送的所更新的主区业务数据；处理装置22当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；随后，第二发送装置23在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；接着，第一更新装置13在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；第二更新装置14用于当所述主设备恢复完成后，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新；最后，停止获取装置24当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，不再获取所述第一请求信息。

在此，所述主设备和从设备中各装置部分已在前文描述，在此不再累赘说明。在一优选实施例中，距离用户最近的数据中心通常是主区，其余为该用户数据的备份区，主区只有一个，备区可以有多个，容灾发生时主区服务不可用，将业务切换到备份区。需要说明的是，所有地域的服务之间是对等的，同时又互为主备的。在本申请优选的实施例中，所述主设备为主区服务设备，所述从设备为其中一个备份服务设备，在实际分布式场景中，某一地区的设备可以同时作为主设备和从设备，即作为当地的主区服务设备的同时，作为其他地区的设备的备份服务设备，以实现当主区发生容灾时能够进行主备切换，将业务切换到备份区。即例如，杭州的服务设备是杭州地区的主区服务设备，同时是上海的备区服务设备。当主设备服务出现不可服务时，主区的流量瞬间切换到备份区。对于可合并类数据，支持异地写入，版本的冲突能够自动被处理，对于不可合并类数据，在备份区是默认禁写的，因此不会造成数据损坏的问题。主设备(主区)将本地存储的数据复制至从设备(备份区)中，当发生流量切换时，系统启动不可合并类数据的写入区主备切换。首先，将主区所有不可合并类数据实体进行禁写，随后，等待主区完成将增量改动到备份区的异步复制，如果主备区之间的网络没有问题，复制将在可预计的时间内完成；如果网络出现问题，则可以有三种选择：第一，等待网络恢复，因为备份区的服务基本可用；第二，通过备用通道将增量改动以人工的方式搬运到主区；第三，基于对数据重要性的评估，丢弃该部分数据增量，因有RPO的控制，所以丢弃的风险是可控的。最后，在备份区将所有不可合并类数据实体的写入区设置为当前地域，完成主区到备份区的切换。当主区的服务恢复后，还是应当将原来那部分切走的数据切回去，因为考虑到用户的使用体验，数据往往是就近存放的。回切的过程一般不用考虑区间网络的问题，首先在备份区禁写，禁写只能禁写之前从主区临时迁移过来的数据，而不能禁写本来就属于备份区的数据，即将写入区为主区但请求归属区为备份区的数据进行禁写，禁写之后等待增量数据异步复制完成，最后在主区设置可写，即完成数据写区的回迁。

请求归属区迁移是指得知数据的使用者更换了常驻地后，系统将用户数据的归属地迁移到同一地域的过程。它对于跨境业务是有很大帮助的，因为跨境往往意味着更高的延迟，跨境访问将会带给用户更加糟糕的体验，因此需要根据用户的常驻地信息，就近迁移用户数据，假如用户的常驻地发生变更，数据也要能尽快迁移。归属区的迁移与主备切换的过程大致类似，在此不再累赘描述，唯一的不同是停写之后需要一并修改请求归属区和写入区为目的地区。

需要说明的是，传统意义上的主备模式和数据库的分库分表是主区提供服务，能够写数据对数据进行修改，主区的数据复制给备份区，备份区不提供服务，不具有写功能。而通过本申请的一实施例所述的系统可以实现备份区的部分服务功能，即当主区发生灾难时，备份区开始创建新数据，提供部分服务，备份区内的数据一部分是之前从主区复制而来的数据，一部分是新创建的数据；主区恢复时，备份区将之前复制而来的数据和新创建的数据的归属区仍为主区所对应的数据重新切回主区，实现部分数据的多地写功能，降低服务的不可用，提供更高的系统可用性和数据可靠性。

在一优选实施例中，如图5示出根据本申请一个方面的一种用于分布式场景中数据处理的系统服务架构示意图。该服务架构用来解决跨地域场景中数据复制而来和容灾控制的传输服务。所述服务由Service和Agent两部分构成。其中，Service是一个全球部署服务，提供高吞吐量和高可用性的全局的协调和事件通知服务；Agent是一个驻留在应用程序端的装置，它与Service、持久化存储系统和复制传输系统保持交互。从写请求的提交流程来看，Agent位于业务逻辑层与持久化层之间，它截获原来直接写到持久化存储的请求，根据既定的策略将请求以增量变更的形式复制，当然最后请求还是会落地到持久化存储中。具体过程为：在地域A(In Region A)中，Agent 1控制用户提交的请求，截获到用户提交的请求进行判断是否符合要求及发送窗口是否可写，若都满足，则Agent 1通知业务应用层(Application Business Layer)进行以下两项工作，第一，是将提交的请求写入本地数据库进行存储，即写入持续化存储；第二，是写的操作以log的形式通过复制通道异步复制至地域B中，地域B(In Region A)中的Agent 2接收到复制过来的数据后，通过Service发送确认信息通知Agent 1。

本领域技术人员应能理解，所述解决跨地域场景中数据复制而来和容灾控制的传输服务的系统服务为本申请的一优选实施例，对本申请所述用于分布式场景中数据处理的系统进行详细描述，当然，现有或今后可能出现的适合本申请的系统服务，均可以引用的方式包含于本申请。

图6示出根据本申请另一个方面的一种在主设备端用于分布式场景中数据处理的方法流程示意图。所述方法包括：步骤S11、步骤S12、步骤S13和步骤S14。其中，步骤S11：获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区均为主设备所在区；步骤S12：通过异步复制通道向从设备发送所更新的主区业务数据；步骤S13：在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；步骤S14：当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新。

本申请一实施例所述在主设备端用于分布式场景中数据处理的方法，对数据是否可合并的区别对待，标记不可合并类数据的写入区和请求归属区为主设备所在区，使得应用系统不受由于多地同时写带来的数据损坏问题。

具体地，在步骤S11中，获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区。

在一具体实施例中，区域A中的用户将用户请求(如创建订单)提交至区域A的服务器的请求信息为第一请求信息，根据所获取的创建订单请求信息对本地存储的该订单数据进行更新，即更新包括将订单中包含的下单用户个人信息、地址信息、订单内容、物流信息等进行创建和修改等写信息存储在本地。主区业务数据是指基于该第一请求信息创建的数据实体，优选地为主设备所在区的用户提交的业务请求所创建的数据。当一条不可合并类型类数据实体被首次创建时，其写入区和请求归属区设定为当前地域，即每份数据的写入区和请求归属区与地理位置信息有关，该地理位置信息是指数据中心的表示符，而不是经纬度坐标，例如，部署在杭州的数据中心的标示符是HZ。进一步的，写入区表示在允许修改该数据实体的所在地域，数据在非写入区是禁止修改的，同时同一时间全局最多只有一个地域是该数据的写区。请求归属区表示数据经常在该地被修改，即数据的使用者常驻此地。需要说明的是，写入区和请求归属区与每条数据对应的，不是与数据类对应，每条不可合并类的数据都有自己的写入区和请求归属区，同一种类型的数据之间，写入区和请求归属区可以不同。

具体地，在步骤S12中，通过异步复制通道向从设备发送所更新的主区业务数据。

在此，为了不给用户造成过高的时延，跨地域之间通常选择异步方式进行数据复制。异步复制不会阻塞用户的写请求，所以用户的请求会先提交，基于获取到的第一请求信息根据既定的策略将请求以增量变更的形式复制至从设备中，其中，增量变更的形式优选为log形式(日志形式)。

具体地，在步骤S13中，在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据。

在一具体实施例中，例如，主设备所在区为杭州，用户的订单在杭州创建，称为数据A，其中，数据A为主区业务数据，其写入区和请求归属区都为杭州，从设备所在区为上海，对于从杭州获取来的数据A只能读不能写；当杭州的服务器主设备发生灾难不可服务时，在上海的从设备获取用户的请求信息，创建新的订单，称为数据B，则数据B包括根据杭州用户所提交的请求创建订单的数据集B1和上海本地用户所提交的请求创建订单的数据集B2，其中，数据集B1为杭州用户的订单为临时在上海进行写的数据，其写入区为上海但请求归属区为杭州，而数据集B2的写入区和请求归属区都为上海。当主设备服务恢复后，主设备所在区为杭州的本地存储的主区业务数据更新为数据A和数据集B1。

需要说明的是，上述实施例所述主设备和从设备用于两地之间的数据处理的设备，所述设备还可以应用于多地之间的数据处理；其中，主设备对应若干从设备，各设备分布在不同的地域中，且主设备与从设备的服务之间为对等的同时互为主备。

具体地，在步骤S14中，当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新。

在此，主设备服务恢复完成后，进行正常工作，而在主设备服务不可用期间临时在从设备写的数据集需迁回主设备，并将这部分数据集的写入区由从设备所在区更新为主设备所在区。例如，继续接前例，在本申请上述具体实施例中，主设备所在区为杭州，从设备所在区为上海，当杭州服务器恢复进行正常工作后，需要将杭州用户临时迁移到上海异地写的数据集回迁至杭州，即根据“请求归属区为杭州，写入区为杭州”确定待回迁的数据集，即确定待回迁的数据集为数据集B1并将其迁至杭州以满足就近服务的原则。在上海的从设备需要禁写这部分数据集B1，在杭州的主设备接收在上海的从设备通过异步复制通道所发送的数据集B1；接着，等待这部分数据向杭州的异步复制至稳态，即两地的版本完全一致，将这部分数据集B1的写入区更新为杭州。需要说明的是，上述主设备所在区为杭州，从设备所在区为上海仅为本申请一实际场景的具体实施例，并不用以限制本申请。另外，本地提交的第一请求信息提交至主设备，不需要再提交至其他设备进行处理，主设备基于所获取的请求对本地存储的主区业务数据进行更新。例如，主设备所在区的用户创建了100个订单后主设备发生服务不可用问题，所在区的用户又新创建的100个订单的请求根据就近服务原则提交至从设备，当主设备服务恢复后，主设备截获所在区的用户再次创建订单的提交请求，对本地存储的数据进行更新。

优选地，所述步骤S11包括：步骤S111、步骤S112和步骤S113。如图7示出的根据本申请另一个方面的一个优选实施例的步骤S11的流程示意图；其中，步骤S111：获取所述第一请求信息；步骤S112：解析所述第一请求信息所请求处理的主区业务数据的数据信息，所述数据信息包括：数据类型、操作类型和/或相关区域信息，其中，所述数据类型包括可合并类型和不可合并类型，所述操作类型包括创建操作和修改操作，所述相关区域信息包括写入区和请求归属区；步骤S113：根据所述第一请求信息所请求处理的主区业务数据的数据信息，对所述主区业务数据进行更新。

在实际场景中，跨地域之间通过异步方式进行数据复制时，用户的请求会先提交，如果此时对端数据也发生了变化，当收到异步传输来的数据时，对端将会面临数据冲突的可能，在两地同时修改数据是造成这一问题的原因之一。在很多情况下，系统要求数据能在两地同时修改，例如用户从某地迁移到另外某地，或者某地服务中断，需要将流量迁移到异地等。因此，解决异步复制带来的数据冲突问题变得尤为关键。通常业务数据都是复杂多样的，在大多数业务系统中，不同类型的数据，在其版本变更发生分支后，对其合并策略的要求也不同。以在线交易系统为例，用户的订单列表如果在两地同时修改(各自创建新订单)，如果能保证创建的订单ID不会冲突，那么对这两个订单列表做集合并运算。再例如，用户的基本信息(如：昵称、生日和地址等)，如果在两地发生修改，我们可以根据修改的时间戳来处理冲突，以晚修改的版本覆盖早修改的版本。然而，另外一类数据则是无法接受两地同时修改的，譬如订单的交易状态信息，它记载了订单状态的变迁过程，每一步都是基于前一步演变而来的，如果在两地同时发生修改，不考虑某些业务数据的特殊性，这类数据是无法被合并的。鉴于此，主设备获取第一请求信息后要对主区业务数据进行解析获得数据类型、操作类型和/或操作类型信息，其中，操作类型是指该数据是需要创建新数据的创建操作还是对已有数据进行修改得到新数据的修改操作。

在本申请的一优选实施例中，在步骤S112中解析所述第一请求信息所请求处理的主区业务数据的数据信息，根据解析结果，对于能够被自动合并的数据采用上述自动合并算法保证合并之后的状态一致，不必要求变更的历史完全一致进行解决数据冲突问题。从而使得写请求在何地提交变得不再重要(不考虑性能因素)，最终都会得到一致的结果，所以当某地服务出现不可用时，可以迅速切换到异地继续服务，极大提高系统可用性。对于不可合并数据，提供每份数据的与地理位置有关的写入区和请求归属区信息。当一个数据实体被首次创建时，写入区和请求归属区就设定为当前地域。数据实体在写入区被修改后，改动会被异步复制到其他的备份区，备份区收到复制副本后会在本地提交。需要说明的是，此时该数据在备份区中的写入区和请求归属区仍保持未变，因此在备份区该数据是禁止修改的。正常情况下请求归属区和写入区同为数据的创建区，只有到发生主备切换的时候，写入区才会变化，当发生请求归属区迁移时，请求归属区才会发生变化。通过上述设置不可合并类数据的写入区和请求归属区对不可合并类数据实施写保护操作进而避免了数据被同时修改。

更优选地，步骤S113包括：当所述第一请求信息请求对不可合并类型的主区业务数据进行修改操作时，判断所述不可合并类型的主区业务数据的写入区是否为所述主设备所在区，若否，则禁止修改相应所述不可合并类型的主区业务数据，若是，则修改相应所述不可合并类型的主区业务数据；当所述第一请求信息请求不可合并类型的主区业务数据进行创建操作时，创建相应主区业务数据并标记其写入区和请求归属区为所述主设备所在区；当所述第一请求信息请求对可合并类型的主区业务数据进行创建操作或修改操作时，直接对相应所述主区业务数据进行创建操作或修改操作。

例如，主设备所在区为杭州，在获取杭州的用户进行本地提交请求创建数据实体后，判断该数据实体的数据类别，当为不可合并类数据时，所已创建的数据的写入区为杭州，若是对该已有的数据进行修改操作，则修改相应所述不可合并类型的已创建的数据；从设备所在区为上海，获取从主设备复制而来的数据，因所复制数据的写入区为主设备所在区杭州，则在上海的从设备只能对所复制数据进行读操作不能进行写操作，即禁止修改复制来的相应所述不可合并类型的数据。当用户提交的请求为可合并类型的数据时，直接对该类数据进行创建操作或修改操作。需要说明的是，进行创建操作时，需要满足创建的数据不能覆盖已有的数据，所新创建的数据对应的写入区和归属区的标识符在全局唯一。

优选地，所述方法还包括：步骤S15(未示出)和步骤S16(未示出)，其中，在步骤S15中，获取所述从设备所发送的确认信息，所述确认信息包括确认接收到所更新的主区业务数据；在步骤S16中，以获取到所述确认信息的时间为起点且恢复目标时长为时间长度，更新发送窗口期限。

在实际应用中，异步复制在数据中心发生严重灾难时，可能丢失数据的增量更新。不同类型的业务系统对数据丢失的可接受程度是不一样的，例如，金融系统和在线交易系统对数据丢失是极为敏感的，而电商网站可能勉强能接受。然而，没有一种系统能保证100％不丢失数据，在这种情况下，本申请中所述主设备提供明确的RPO，使得业务方能基于此评估由于数据丢失而带来的经济损失和法律风险。在具体实施例中，主设备的发送端本地维持一个发送窗口，起于上一次从设备的接收端确认的时间点，即所确认的消息包(Packet)在发送端的提交时间点，长度固定为RPO，只要当前时间仍在发送窗口之内，新的业务请求就允许在本地提交，然后经由数据传输通道异步复制给从设备的接收端。接收端收到数据后，经由某种途径向发送端报告Packet的确认信息(例如Packet ID)，经过步骤S15收到确认信息后，步骤S16：将发送窗口向未来平移一定距离，使得窗口开始于所确认Packet的发送时间。例如，在一具体实施例中，主设备所在区为杭州，从设备所在区为上海，杭州用户在杭州提交的一条数据请求创建数据实体后异步复制到上海，上海的从设备向主设备反馈确认信息，主设备收到确认信息的时刻为t，杭州本地维持一个发送窗口，长度为RPO，则起始点为t时刻，只要当前时间在t～t+RPO之间，则新的主区业务数据请求就允许在杭州本地提交，然后异步复制给所在上海的从设备，从设备收到异步复制的数据后发送确认信息，所在杭州的主设备接收到确认信息的时刻为t2(t2>t)，则主设备的发送端的发送窗口进行平移一定距离，由原来的t～t+RPO变为t2～t2+RPO。这样保证数据的丢失的时间不超过RPO，提供了明确的RPO保证。

本领域技术人员应能理解，上述RPO(Recovery Point Objective，恢复点目标)是指因硬件、程序或通信发生故障，而导致的计算机、系统或网络出现故障时，必须从备份存储中恢复以保证系统正常运行的文件的时长，是一种用于衡量故障恢复后数据丢失的最大限量指标。

本领域技术人员应能理解，上述主设备所在区为杭州，从设备所在区为上海仅为举例，只需主设备所在区和从设备所在区满足跨地域即可；上述确认发送窗口的方法仅为本申请一具体实施例，对本申请所述获取到所述确认信息的时间为起点且恢复目标时长为时间长度，更新发送窗口期限的方法进行详细描述，当然，现有或今后可能出现的适合本申请确认发送窗口的方法，均可以引用的方式包含于本申请。

优选地，所述步骤S15：判断当前时间是否在所述发送窗口期限内，若是，则通过异步复制通道向所述从设备发送所更新的主区业务数据，若否，则等待所述确认信息。

接上述实施例，若当前时间在发送窗口期限内，即在t～t+RPO之间，则所更新的主区业务数据请求就允许在杭州本地提交，然后异步复制给所在上海的从设备，若不在发送窗口期限内，则所在杭州的主设备的发送端等待从设备所发送的确认信息。

图8示出根据本申请另一个方面的一种在从设备端用于分布式场景中数据处理的方法流程示意图。所述方法包括：步骤S21、步骤S22、步骤S23和步骤S24。其中，在步骤S21中，接收并存储主设备通过异步复制通道发送的所更新的主区业务数据；在步骤S22中，当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；在步骤S23中，在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；在步骤S24中，当所述主设备恢复完成后，不再获取所述第一请求信息。

本申请一实施例所述在从设备端用于分布式场景中数据处理的方法，当主设备发生服务不可用时，作为主设备的数据备份区接收主设备所切换来的流量，当主设备服务恢复后，禁写之前从主设备临时迁移过来的数据，禁写之后等待增量数据异步复制完成，完成数据的回迁。

具体地，在步骤S21中，接收并存储主设备通过异步复制通道发送的所更新的主区业务数据。

在此，从设备的服务作为主设备的服务的备份存储区，提交至主设备的用户数据异步复制至从设备，从设备接收在主设备中对用户数据进行创建、修改等所更新后的数据后将这些数据进行本地存储，但从设备对所述接收的所更新的数据中的不可合并类数据只能进行读操作，不能对其进行删除、增加写、改正或替换的修改操作。

具体地，在步骤S22中，用于当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据。

在一具体实施例中，例如，主设备所在区为杭州，用户的订单在杭州创建的数据中的不可合并类数据为主区业务数据a，其写入区和请求归属区都为杭州，从设备所在区为上海，对于从杭州获取来的不可合并类的主区业务数据a只能读不能写；当杭州的服务器主设备发生灾难不可服务时，在上海的从设备获取主设备对应的第一请求信息，并基于获取到的第一信息请求创建新的订单数据c，此时，从设备中主区业务数据b包括两部分：从主设备通过异步复制通道复制而来的主区业务数据a和写入区为上海但请求归属区为杭州的新创建的订单数据c，订单数据c为所更新的主区业务数据，是杭州用户创建的订单临时在上海进行写的数据。所更新的主区业务数据中的不可合并类数据只能在从设备所在区进行修改操作，在其他区禁止修改。

具体地，在步骤S23中，在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备。

在此，优选地，所述步骤S23包括：继续获取所述第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，禁止对不可合并类型的主区业务数据进行修改操作和创建操作。接前例，在上海的从设备获取主设备对应的第一请求信息，并基于获取到的第一信息请求创建新的订单数据c为所更新的主区业务数据，其写入区为上海，请求归属区为杭州；当主设备服务恢复进行正常工作后，通过异步复制通道将订单数据c发送至主设备。

需要说明的是，上述从设备通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备的方法不限于两个地域之间，还可在多个地域之间进行。

具体地，在步骤S24中，当所述主设备恢复完成后，不再获取所述第一请求信息。

继续接前例，当从设备将主设备临时在从设备写的数据即订单数据c异步复制发送至主设备，等待增量数据异步复制达到稳态，即两地版本数据一致时，主设备正常获取所在区的用户提交的第一请求信息，从设备不再获取该请求信息，而接收由主设备复制来的数据作为主设备中数据的存储设备对主设备所发送的数据进行备份。

优选地，步骤S22还包括：当接收到所述主设备通过异步复制通道发送的所更新的主区业务数据后，向所述主设备发送确认信息。

在此，主设备的发送端本地维持一个发送窗口，只要当前时间仍在发送窗口之内，新的业务请求就允许在本地提交，然后经由数据传输通道异步复制给从设备的接收端。接收端收到数据后，发送确认信息单元经由某种途径向发送端报告Packet的确认信息(例如Packet ID)。

优选地，所述方法还包括：获取本地提交的第二请求信息，并基于所述第二请求信息对本地存储的从区业务数据进行更新，其中，当创建不可合并类型的从区业务数据时，标记其写入区和请求归属区为从设备所在区。

在此，从设备不仅作为主设备中数据的存储备份设备，还作为本地提交数据请求的主区设备，第二请求信息是指本地提交的用户请求数据信息和对主区业务数据进行修改请求，从设备所在区的本地用户提交请求时，获取所提交的请求信息并基于请求信息创建数据或修改数据对本地存储的从区业务数据进行更新。例如，从设备所在区为上海，上海用户提交创建订单或修改订单数据请求，将创建完的数据实体或修改后的数据进行存储。又如，第二请求信息为对主区业务数据中的可合并类数据进行修改操作(如修改用户昵称、地址等)，将修改后的数据进行存储以更新主区业务数据。当根据用户提交的创建请求进行创建数据实体时若为不可合并类数据，则标记所述创建的数据实体的写入区和请求归属区为从设备所在区。

更优选地，基于所述第二请求信息对本地存储的从区业务数据进行更新还包括：当所述第二请求信息请求对所述主区业务数据进行修改操作时，判断所述主区业务数据的数据类型，当所述主区业务数据为可合并类型则进行修改操作，当所述主区业务数据为不可合并类型则禁止进行修改操作。

在此，若从设备中从主设备复制而来的主区业务数据为可合并类数据，从设备对所述可合并类数据可进行修改操作，例如，修改用户昵称、地址等；若从主设备复制而来的主区业务数据为不可合并类数据，因所述主区业务数据的写入区为主设备所在区，从设备对其的修改操作为禁止操作。

优选地，所述方法还包括：将所接收并存储的所述主设备通过异步复制通道发送的所更新的主区业务数据标记为不再转发数据。

在此，为避免数据被重复往返地复制，发送端只发送在本地提交的改动，接收端不会将收到的复制数据再进行转发。当服务所在地域的数目超过3个以上时，转发会导致同一份数据被同一个接收端接收多次，产生正确性问题。因此，发送端将待复制的数据分别发给每个接收端。从设备作为主设备复制数据的接收端，在接收并存储主设备所发送来的主区业务数据后不再将主区业务数据再转发给其他设备。

图9示出根据本申请另一个方面的一种在分布式系统中用于分布式场景中数据处理的系统方法流程示意图。所述方法包括：步骤S11～步骤S14和步骤S21～步骤S24。本领域技术人员应当能够理解，具有主设备和从设备的系统，或具有主设备、若干从设备的系统，以实现用于分布式场景中数据处理的方案均包含于本申请请求保护的范围之内。

在此，所述主设备可以与若干从设备配合工作，主设备与从设备分布在不同的地域，若干从设备分布在不同的地域中，具体地，通过步骤S11，主设备获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；步骤S12，所述主设备通过异步复制通道向从设备发送所更新的主区业务数据；当所述主设备不可服务时，在步骤S21中，所述从设备获取所述主设备对应的第一请求信息，在步骤S22中，基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；随后，在步骤S23中，在所述主设备不可服务后进行恢复期间，所述从设备通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；在步骤S13中，所述主设备更新本地存储的所述主区业务数据，其中，所述主设备更新本地存储的所述主区业务数据包括将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区；在步骤S14中，当所述主设备恢复完成后，所述主设备重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，在步骤S24中，所述从设备不再获取所述第一请求信息。

在此，所述步骤S11～步骤S14和步骤S21～步骤S24已在前文进行了详细描述，在此不再累赘说明。

在一优选实施例中，距离用户最近的数据中心通常是主区，其余为该用户数据的备份区，主区只有一个，备区可以有多个，容灾发生时主区服务不可用，将业务切换到备份区。需要说明的是，所有地域的服务之间是对等的，同时又互为主备的。在本申请优选的实施例中，所述主设备为主区服务设备，所述从设备为其中一个备份服务设备，在实际分布式场景中，某一地区的设备可以同时作为主设备和从设备，即作为当地的主区服务设备的同时，作为其他地区的设备的备份服务设备，以实现当主区发生容灾时能够进行主备切换，将业务切换到备份区。即例如，杭州的服务设备是杭州地区的主区服务设备，同时是上海的备区服务设备。当主设备服务出现不可服务时，主区的流量瞬间切换到备份区。对于可合并类数据，支持异地写入，版本的冲突能够自动被处理，对于不可合并类数据，在备份区是默认禁写的，因此不会造成数据损坏的问题。主设备(主区)将本地存储的数据复制至从设备(备份区)中，当发生流量切换时，系统启动不可合并类数据的写入区主备切换。首先，将主区所有不可合并类数据实体进行禁写，随后，等待主区完成将增量改动到备份区的异步复制，如果主备区之间的网络没有问题，复制将在可预计的时间内完成；如果网络出现问题，则可以有三种选择：第一，等待网络恢复，因为备份区的服务基本可用；第二，通过备用通道将增量改动以人工的方式搬运到主区；第三，基于对数据重要性的评估，丢弃该部分数据增量，因有RPO的控制，所以丢弃的风险是可控的。最后，在备份区将所有不可合并类数据实体的写入区设置为当前地域，完成主区到备份区的切换。当主区的服务恢复后，还是应当将原来那部分切走的数据切回去，因为考虑到用户的使用体验，数据往往是就近存放的。回切的过程一般不用考虑区间网络的问题，首先在备份区禁写，禁写只能禁写之前从主区临时迁移过来的数据，而不能禁写本来就属于备份区的数据，即将写入区为主区但请求归属区为备份区的数据进行禁写，禁写之后等待增量数据异步复制完成，最后在主区设置可写，即完成数据写区的回迁。

请求归属区迁移是指得知数据的使用者更换了常驻地后，系统将用户数据的归属地迁移到同一地域的过程。它对于跨境业务是有很大帮助的，因为跨境往往意味着更高的延迟，跨境访问将会带给用户更加糟糕的体验，因此需要根据用户的常驻地信息，就近迁移用户数据，假如用户的常驻地发生变更，数据也要能尽快迁移。归属区的迁移与主备切换的过程大致类似，在此不再累赘描述，唯一的不同是停写之后需要一并修改请求归属区和写入区为目的地区。

需要说明的是，传统意义上的主备模式和数据库的分库分表是主区提供服务，能够写数据对数据进行修改，主区的数据复制给备份区，备份区不提供服务，不具有写功能。而通过本申请的一实施例所述的系统可以实现备份区的部分服务功能，即当主区发生灾难时，备份区开始创建新数据，提供部分服务，备份区内的数据一部分是之前从主区复制而来的数据，一部分是新创建的数据；主区恢复时，备份区将之前复制而来的数据和新创建的数据的归属区仍为主区所对应的数据重新切回主区，实现部分数据的多地写功能，降低服务的不可用，提供更高的系统可用性和数据可靠性。

在一优选实施例中，如图5示出根据本申请一个方面的一种用于分布式场景中数据处理的系统服务架构示意图。该服务架构用来解决跨地域场景中数据复制而来和容灾控制的传输服务。所述服务由Service和Agent两部分构成。其中，Service是一个全球部署服务，提供高吞吐量和高可用性的全局的协调和事件通知服务；Agent是一个驻留在应用程序端的装置，它与Service、持久化存储系统和复制传输系统保持交互。从写请求的提交流程来看，Agent位于业务逻辑层与持久化层之间，它截获原来直接写到持久化存储的请求，根据既定的策略将请求以增量变更的形式复制，当然最后请求还是会落地到持久化存储中。具体过程为：在地域A中，Agent 1控制用户提交的请求，截获到用户提交的请求进行判断是否符合要求及发送窗口是否可写，若都满足，则Agent 1通知应用层(ApplicationBusiness Layer)进行以下两项工作，第一，是将提交的请求写入本地数据库进行存储，即写入持续化存储；第二，是写的操作以log的形式通过复制通道异步复制至地域B中，地域B中的Agent 2接收到复制过来的数据后，通过Service发送确认信息通知Agent 1。

此外，本申请还提供了一种用于分布式场景中数据处理的主设备，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区均为主设备所在区；

通过异步复制通道向从设备发送所更新的主区业务数据；

在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；

当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新。

此外，本申请还提供了一种用于分布式场景中数据处理的从设备，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

接收并存储主设备通过异步复制通道发送的所更新的主区业务数据；

当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；

当所述主设备恢复完成后，不再获取所述第一请求信息。

此外，本申请还提供了一种用于分布式场景中数据处理的系统，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

主设备获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；

所述主设备通过异步复制通道向从设备发送所更新的主区业务数据；

当所述主设备不可服务时，所述从设备获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

在所述主设备不可服务后进行恢复期间，所述从设备通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备，所述主设备更新本地存储的所述主区业务数据；

当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，所述主设备重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，所述从设备不再获取所述第一请求信息。

本领域技术人员应能理解，所述解决跨地域场景中数据复制而来和容灾控制的传输服务的系统服务为本申请的一优选实施例，对本申请所述用于分布式场景中数据处理的系统进行详细描述，当然，现有或今后可能出现的适合本申请的系统服务，均可以引用的方式包含于本申请。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (27)

1.一种在主设备端用于分布式场景中数据处理的方法，其中，所述方法包括：

获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区均为主设备所在区；

通过异步复制通道向从设备发送所更新的主区业务数据；

在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；

当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新。

2.根据权利要求1所述的方法，其中，所述获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新包括：

获取所述第一请求信息；

解析所述第一请求信息所请求处理的主区业务数据的数据信息，所述数据信息包括：数据类型、操作类型和/或相关区域信息，其中，所述数据类型包括可合并类型和不可合并类型，所述操作类型包括创建操作和修改操作，所述相关区域信息包括写入区和请求归属区；

根据所述第一请求信息所请求处理的主区业务数据的数据信息，对所述主区业务数据进行更新。

3.根据权利要求2所述的方法，其中，根据所述第一请求信息所请求处理的主区业务数据的数据信息，基于所述第一请求信息对所述主区业务数据进行更新包括：

当所述第一请求信息请求对不可合并类型的主区业务数据进行修改操作时，判断所述不可合并类型的主区业务数据的写入区是否为所述主设备所在区，若否，则禁止修改相应所述不可合并类型的主区业务数据，若是，则修改相应所述不可合并类型的主区业务数据；

当所述第一请求信息请求不可合并类型的主区业务数据进行创建操作时，创建相应主区业务数据并标记其写入区和请求归属区均为所述主设备所在区；

当所述第一请求信息请求对可合并类型的主区业务数据进行创建操作或修改操作时，直接对相应所述主区业务数据进行创建操作或修改操作。

4.根据权利要求1至3中任一项所述的方法，其中，所述方法还包括：

获取所述从设备所发送的确认信息，所述确认信息包括确认接收到所更新的主区业务数据；

以获取到所述确认信息的时间为起点且恢复目标时长为时间长度，更新发送窗口期限。

5.根据权利要求4所述的方法，其中，所述通过异步复制通道向从设备发送所更新的主区业务数据包括：

判断当前时间是否在所述发送窗口期限内，若是，则通过异步复制通道向所述从设备发送所更新的主区业务数据，若否，则等待所述确认信息。

6.一种从设备端用于分布式场景中数据处理的方法，其中，所述方法包括：

接收并存储主设备通过异步复制通道发送的所更新的主区业务数据；

当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；

当所述主设备恢复完成后，不再获取所述第一请求信息。

7.根据权利要求6所述的方法，其中，所述当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新包括：

当接收到所述主设备通过异步复制通道发送的所更新的主区业务数据后，向所述主设备发送确认信息。

8.根据权利要求6所述的方法，其中，所述通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备期间还包括：

继续获取所述第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，禁止对不可合并类型的主区业务数据进行修改操作和创建操作。

9.根据权利要求6所述的方法，其中，所述方法还包括：

获取本地提交的第二请求信息，并基于所述第二请求信息对本地存储的从区业务数据进行更新，其中，当创建不可合并类型的从区业务数据时，标记其写入区和请求归属区为从设备所在区。

10.根据权利要求9所述的方法，其中，所述基于所述第二请求信息对本地存储的从区业务数据进行更新还包括：

当所述第二请求信息请求对所述主区业务数据进行修改操作时，判断所述主区业务数据的数据类型，当所述主区业务数据为可合并类型则进行修改操作，当所述主区业务数据为不可合并类型则禁止进行修改操作。

11.根据权利要求6所述的方法，其中，所述方法还包括：

将所接收并存储的所述主设备通过异步复制通道发送的所更新的主区业务数据标记为不再转发数据。

12.一种在分布式系统中用于分布式场景中数据处理的方法，其中，所述方法包括：

主设备获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；

所述主设备通过异步复制通道向从设备发送所更新的主区业务数据；

当所述主设备不可服务时，所述从设备获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

在所述主设备不可服务后进行恢复期间，所述从设备通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备，所述主设备更新本地存储的所述主区业务数据；

当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，所述主设备重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，所述从设备不再获取所述第一请求信息。

13.一种用于分布式场景中数据处理的主设备，其中，所述主设备包括：

获取装置，用于获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；

第一发送装置，用于通过异步复制通道向从设备发送所更新的主区业务数据；

更新装置，用于在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；

恢复装置，用于当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新。

14.根据权利要求13所述的主设备，其中，所述获取装置包括：

获取单元，用于获取所述第一请求信息；

解析单元，用于解析所述第一请求信息所请求处理的主区业务数据的数据信息，所述数据信息包括：数据类型、操作类型和/或相关区域信息，其中，所述数据类型包括可合并类型和不可合并类型，所述操作类型包括创建操作和修改操作，所述相关区域信息包括写入区和请求归属区；

处理单元，用于根据所述第一请求信息所请求处理的主区业务数据的数据信息，对所述主区业务数据进行更新。

15.根据权利要求14所述的主设备，其中，所述处理单元用于：

当所述第一请求信息请求对不可合并类型的主区业务数据进行修改操作时，判断所述不可合并类型的主区业务数据的写入区是否为所述主设备所在区，若否，则禁止修改相应所述不可合并类型的主区业务数据，若是，则修改相应所述不可合并类型的主区业务数据；

当所述第一请求信息请求不可合并类型的主区业务数据进行创建操作时，创建相应主区业务数据并标记其写入区和请求归属区为所述主设备所在区；

当所述第一请求信息请求对可合并类型的主区业务数据进行创建操作或修改操作时，直接对相应所述主区业务数据进行创建操作或修改操作。

16.根据权利要求13至15中任一项所述的主设备，其中，所述主设备还包括：

获取确认信息装置，用于获取所述从设备所发送的确认信息，所述确认信息包括确认接收到所更新的主区业务数据；

更新窗口期限装置，用于以获取到所述确认信息的时间为起点且恢复目标时长为时间长度，更新发送窗口期限。

17.根据权利要求16所述的主设备，其中，所述获取确认信息装置用于：

判断当前时间是否在所述发送窗口期限内，若是，则通过异步复制通道向所述从设备发送所更新的主区业务数据，若否，则等待所述确认信息。

18.一种用于分布式场景中数据处理的从设备，其中，所述从设备包括：

接收装置，用于接收并存储主设备通过异步复制通道发送的所更新的主区业务数据；

处理装置，用于当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为第二区、请求归属区为第一区，并禁止修改不可合并类型的主区业务数据；

第二发送装置，用于在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；

停止获取装置，用于当所述主设备恢复完成后，不再获取所述第一请求信息。

19.根据权利要求18所述的从设备，其中，所述处理装置还包括：

发送确认信息单元，用于当接收到所述主设备通过异步复制通道发送的所更新的主区业务数据后，向所述主设备发送确认信息。

20.根据权利要求18所述的从设备，其中，所述第二发送装置包括：

更新单元，用于继续获取所述第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，禁止对不可合并类型的主区业务数据进行修改操作和创建操作。

21.根据权利要求18所述的从设备，其中，所述从设备还包括：

从区业务数据更新装置，用于获取本地提交的第二请求信息，并基于所述第二请求信息对本地存储的从区业务数据进行更新，其中，当创建不可合并类型的从区业务数据时，标记其写入区和请求归属区为从设备所在区。

22.根据权利要求21所述的从设备，其中，所述从区业务数据更新装置还包括：

判断单元，用于当所述第二请求信息请求对所述主区业务数据进行修改操作时，判断所述主区业务数据的数据类型，当所述主区业务数据为可合并类型则进行修改操作，当所述主区业务数据为不可合并类型则禁止进行修改操作。

23.根据权利要求18所述的从设备，其中，所述从设备还包括：

标记装置，用于将所接收并存储的所述主设备通过异步复制通道发送的所更新的主区业务数据标记为不再转发数据。

24.一种用于分布式场景中数据处理的系统，其中，所述系统包括：主设备和从设备；

其中，所述主设备包括：

获取装置，用于获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区均为主设备所在区；

第一发送装置，用于通过异步复制通道向从设备发送所更新的主区业务数据；

更新装置，用于在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；

恢复装置，用于当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新；

所述从设备包括：

接收装置，用于接收并存储所述主设备通过异步复制通道发送的所更新的主区业务数据；

处理装置，用于当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

第二发送装置，用于在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；

停止获取装置，用于当所述主设备恢复完成后，不再获取所述第一请求信息。

25.一种用于分布式场景中数据处理的主设备，其中，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区均为主设备所在区；

通过异步复制通道向从设备发送所更新的主区业务数据；

在所述主设备不可服务后进行恢复期间，通过异步复制通道接收在不可服务期间所述从设备基于所述第一请求信息所更新的主区业务数据，以更新本地存储的所述主区业务数据；

当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新。

26.一种用于分布式场景中数据处理的从设备，其中，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

接收并存储主设备通过异步复制通道发送的所更新的主区业务数据；

当所述主设备不可服务时，获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

在所述主设备服务恢复期间，通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备；

当所述主设备恢复完成后，不再获取所述第一请求信息。

27.一种用于分布式场景中数据处理的系统，其中，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

主设备获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，其中，当创建不可合并类型的主区业务数据时，标记其写入区和请求归属区为主设备所在区；

所述主设备通过异步复制通道向从设备发送所更新的主区业务数据；

当所述主设备不可服务时，所述从设备获取所述主设备对应的第一请求信息，并基于所述第一请求信息对所存储的相应主区业务数据进行更新，其中，创建不可合并类型的主区业务数据时记录其写入区为从设备所在区、请求归属区为主设备所在区，并禁止修改不可合并类型的主区业务数据；

在所述主设备不可服务后进行恢复期间，所述从设备通过异步复制通道将不可服务期间所更新的主区业务数据发送至所述主设备，所述主设备更新本地存储的所述主区业务数据；

当所述主设备恢复完成后，将所接收的不可合并类型的主区业务数据的写入区更新为所述主设备所在区，所述主设备重新获取本地提交的第一请求信息，并基于所述第一请求信息对本地存储的主区业务数据进行更新，所述从设备不再获取所述第一请求信息。

Images