CN110196856B - 一种分布式数据读取方法及装置 - Google Patents
一种分布式数据读取方法及装置 Download PDFInfo
- Publication number
- CN110196856B CN110196856B CN201910383137.2A CN201910383137A CN110196856B CN 110196856 B CN110196856 B CN 110196856B CN 201910383137 A CN201910383137 A CN 201910383137A CN 110196856 B CN110196856 B CN 110196856B
- Authority
- CN
- China
- Prior art keywords
- data
- global
- state
- version
- write transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2315—Optimistic concurrency control
- G06F16/2329—Optimistic concurrency control using versioning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
Abstract
本发明涉及数据处理领域，尤其涉及一种分布式数据读取方法及装置，该方法为，将全局读事务请求发送给对应的各数据节点；分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据，并从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据，这样，读取各数据节点上数据时，不仅读取一个版本的数据，而是可以同时返回一个版本或多个版本的数据，通过一次读取，进而再从中识别出符合全局一致性版本的数据，解决了全局事务读取数据异常的问题，并且节省了时间，提高了效率。
Description
技术领域
本发明涉及数据处理领域，尤其涉及一种分布式数据读取方法及装置。
背景技术
目前，在分布式系统中，当进行跨节点的全局写事务操作时，假设全局写事务涉及两个数据节点，已经过了PREPARE阶段，事务可以提交，第一个数据节点提交完成，第二个数据节点尚未提交，若此时新来一个全局读事务操作，第一个数据节点提交的数据被读到，但是第二个数据节点因尚未完成提交，因此新数据没有被读到，导致全局读事务操作读到的数据版本是不一致的，造成数据异常。
因此在全局读事务操作中，如何保证读到的数据版本一致是一个需要考虑的问题。
发明内容
本发明实施例提供一种分布式数据读取方法及装置，以解决现有技术中分布式数据全局读数据不一致的问题。
本发明实施例提供的具体技术方案如下：
本发明一个实施例提供了一种分布式数据读取方法，包括：
将全局读事务请求发送给对应的各数据节点；
分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据，其中，返回的数据为针对所述全局读事务请求的目标数据，所述子写事务状态表示全局写事务在数据节点上的局部状态；所述一个版本为最新子写事务状态处于全局提交完成committed状态或全局回滚完成aborted状态的版本，所述多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本；
从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据。
本发明另一个实施例提供了一种分布式数据读取装置，包括：
发送模块，用于将全局读事务请求发送给对应的各数据节点；
获取模块，用于分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据，其中，返回的数据为针对所述全局读事务请求的目标数据，所述子写事务状态表示全局写事务在数据节点上的局部状态；所述一个版本为最新子写事务状态处于全局committed状态或全局aborted状态的版本，所述多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本；
确定模块，用于从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据。
结合本发明另一个实施例，进一步包括：
处理模块，用于获取全局写事务请求对应的全局事务标识，并确定所述全局写事务请求对应的各数据节点；
写模块，用于分别向所述全局写事务请求对应的各数据节点写入数据；
更新模块，用于更新记录的全局写事务状态信息，其中，所述全局写事务状态信息至少包括全局事务标识、最新的全局写事务状态、对应的各数据节点。
结合本发明另一个实施例，进一步包括：
同步模块，用于若确定最新的全局写事务状态为全局committed状态或全局aborted状态，则将所述最新的全局写事务状态同步到对应的各数据节点；其中，全局committed状态表示对应的各数据节点均提交完成，全局aborted状态表示对应的各数据节点均回滚完成；
更新模块还用于：若在更新记录的全局写事务状态信息时，确定存在全局读事务正在执行，则将更新记录的全局写事务状态信息的更新操作进行缓存，并在确定所述全局读事务执行完成后，执行所述更新操作。
结合本发明另一个实施例，所述子写事务状态包括：本地准备完成prepared状态、本地committed状态、本地aborted状态、全局committed状态和全局aborted状态。
结合本发明另一个实施例，分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据时，获取模块具体用于：
若数据节点确定存在r(n+1)版本的数据，并处于本地prepared状态，则获取数据节点返回的r(n)和r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于本地committed状态，则获取数据节点返回的r(n)和r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于本地aborted状态，则获取数据节点返回的r(n)和r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于全局committed状态，则获取数据节点返回的r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于全局aborted状态，则获取数据节点返回的r(n)版本的数据；
若数据节点确定不存在r(n+1)版本的数据，则获取数据节点返回的r(n)版本的数据。
结合本发明另一个实施例，从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据时，确定模块具体用于：
若返回的数据为一个版本，则直接将该版本的数据确定为符合全局一致性的版本的数据；
若返回的数据有多个版本，则根据返回的数据上记录的全局事务标识，获取所述全局事务标识对应的最新的全局写事务状态，并根据返回的数据对应的子写事务状态和所述最新的全局写事务状态，从多个版本的数据中确定出符合全局一致性的版本的数据；其中，所述最新的全局写事务状态表示全局写事务的全局状态。
结合本发明另一个实施例，根据返回的数据对应的子写事务状态和所述最新的全局写事务状态，从多个版本的数据中确定出符合全局一致性的版本的数据时，确定模块具体用于：
若返回的数据有r(n)和r(n+1)2个版本，则根据r(n+1)版本对应的子写事务状态和最新的全局写事务状态，从r(n)和r(n+1)中确定出符合全局一致性的版本的数据。
结合本发明另一个实施例，从r(n)和r(n+1)中确定出符合全局一致性的版本的数据时，确定模块具体用于：
若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态处于正在提交committing状态时，则确定出符合全局一致性的版本的数据为r(n+1)版本数据；
若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态为正在回滚aborting状态，则在确定各数据节点返回的数据中均包含被更新或删除的数据时，确定符合全局一致性的版本的数据为r(n)版本数据；
若r(n+1)版本处于本地committed状态，并最新的全局写事务状态为committing或全局committed状态时，则确定符合全局一致性的版本的数据为r(n+1)版本数据；
若r(n+1)版本处于本地aborted状态，并最新的全局写事务状态为aborting或全局aborted状态时，则确定符合全局一致性的版本的数据为r(n)版本数据。
结合本发明另一个实施例，从r(n)和r(n+1)中确定出符合全局一致性的版本的数据时，确定模块进一步用于：
若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态为preparing状态时，则阻塞所述全局读事务请求对应的全局读事务；
在确定最新的全局写事务状态更新为committing状态时，重新启动所述全局读事务，并以使获取模块重新执行分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据的步骤；
在确定最新的全局写事务状态更新为aborting状态时，回滚所述全局读事务。
本发明另一个实施例提供了一种分布式数据读取方法，包括：
接收全局读事务请求；
根据本地记录的子写事务状态返回一个版本或多个版本的数据，以使数据接收方从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据，其中，返回的数据为针对所述全局读事务请求的目标数据，所述子写事务状态表示全局写事务在数据节点上的局部状态；所述一个版本为最新子写事务状态处于全局提交完成committed状态或全局回滚完成aborted状态的版本，所述多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本。
结合本发明另一个实施例，所述子写事务状态包括：本地准备完成prepared状态、本地committed状态、本地aborted状态、全局committed状态和全局aborted状态。
结合本发明另一个实施例，根据本地记录的子写事务状态返回一个版本或多个版本的数据，具体包括：
若确定存在r(n+1)版本的数据，并处于本地prepared状态，则返回r(n)和r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于本地committed状态，则返回r(n)和r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于本地aborted状态，则返回的r(n)和r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于全局committed状态，则返回的r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于全局aborted状态，则返回的r(n)版本的数据；
若确定不存在r(n+1)版本的数据，则返回的r(n)版本的数据。
本发明另一个实施例提供了一种分布式数据读取装置，包括：
接收模块，用于接收全局读事务请求；
发送模块，用于根据本地记录的子写事务状态返回一个版本或多个版本的数据，以使数据接收方从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据，其中，返回的数据为针对所述全局读事务请求的目标数据，所述子写事务状态表示全局写事务在数据节点上的局部状态；所述一个版本为最新子写事务状态处于全局提交完成committed状态或全局回滚完成aborted状态的版本，所述多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本。
结合本发明另一个实施例，所述子写事务状态包括：本地准备完成prepared状态、本地committed状态、本地aborted状态、全局committed状态和全局aborted状态。
结合本发明另一个实施例，根据本地记录的子写事务状态返回一个版本或多个版本的数据时，发送模块具体用于：
若确定存在r(n+1)版本的数据，并处于本地prepared状态，则返回r(n)和r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于本地committed状态，则返回r(n)和r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于本地aborted状态，则返回的r(n)和r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于全局committed状态，则返回的r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于全局aborted状态，则返回的r(n)版本的数据；
若确定不存在r(n+1)版本的数据，则返回的r(n)版本的数据。
本发明另一个实施例提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一种分布式数据读取方法的步骤。
一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一种分布式数据读取方法的步骤。
本发明实施例中，将全局读事务请求发送给对应的各数据节点；分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据，并从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据，这样，读取各数据节点上数据时，不是仅读取一个版本的数据，而是可以使数据节点根据本地记录的子写事务状态返回一个版本或多个版本的数据，进而再从中确定出符合全局一致性的版本，可以通过一次读取，后续再从中进行识别，最终确定全局一致性版本的数据，解决了全局事务读取数据异常的问题，并且不需要分2次读，节省了事务处理时间，提高了效率，并且还可以保证数据一致性。
附图说明
图1为现有技术中数据异常说明示意图；
图2为现有技术中DRCC异常发生示意图；
图3为本发明实施例中分布式事务处理架构示意图；
图4为本发明实施例中分布式数据写方法的流程图；
图5为现有技术中数据项结构示意图；
图6为本发明实施例中数据项结构示意图；
图7为本发明实施例中一种分布式数据读取方法的流程图；
图8为本发明实施例中另一种分布式数据读取方法的流程图；
图9为本发明实施例中一种分布式数据读取装置结构示意图；
图10为本发明实施例中另一种分布式数据读取装置结构示意图；
图11为本发明实施例中电子设备的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，并不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
为便于对本发明实施例的理解，下面先对几个概念进行简单介绍：
分布式：基本思想是把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给许多计算机进行处理，最后把这些计算结果综合起来得到最终的结果。
事务：一般是指要做的或所做的事情，在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。
XA：为一种分布式事务协议，XA采用两阶段提交协议(The two-phase commitprotocol，2PC)方式来管理分布式事务。
多版本并发控制(Multi-Version Concurrency Control，MVCC)：是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存，MVCC可以维持一个数据的多个版本使读写操作没有冲突。
SS2PL：SS2PL和严格的两相锁(Strict Two-Phase Locking，S2PL)的差别在于释放锁的时机不同，即事务的结束点和封锁点是否重合，SS2PL是在事务提交后，才释放读锁和写锁。
分布式读半已提交异常(Distributed Read Committed-Committing anomaly，DRCC异常)：本发明实施例中主要是指针对存在跨节点的全局写操作的分布式系统，由于不同数据节点对全局写事务的提交时间不同，若一个数据节点提交完成，第二个数据节点尚未提交，此时新来一个全局读操作，读取到第一个数据节点的数据为提交的数据，但是第二个数据节点因未完成数据提交故新数据没有被读到，读到的为上一个版本的旧数据，因此导致全局读操作读到的数据是不一致的。
现有技术中，当使用XA技术实现跨节点的写操作时，可能会出现全局读操作读取到的数据不一致的问题，本发明实施例中称之为DRCC异常。
例如参阅图1所示，为现有技术中数据异常说明示意图。如图1所示，假设事务T1为全局写事务，事务T2为全局读事务，C1、C2为协调节点，Px、Py为数据节点，C1分别向Px、Py中写数据，C2分别从Px、Py中读数据。
S1、开始(BEGIN)T1，C1分别向Px、Py写入x1、y1，操作为[w(x1),w(y1)]。
此时Px的上一个提交完成的数据为
版本(versions)为versions＝{}，Py的上一个提交完成的数据为
versions＝{}。
S2、C1上T1进入准备(prepare)阶段，向Px写入x1，md＝{y}。
此时Px还未针对此次写入提交，因此其上一个提交完成的数据，即最新提交完成的数据仍为
但此时versions＝{x1}。
S3、C1上T1进入prepare阶段，向Py写入y1，md＝{x}。
此时Py也还未针对此次写入提交，其上一个提交完成的数据仍为
但versions＝{y1}。
S4、Px向C1返回写入成功的响应(RESPONSE)，进入本地准备完成(prepared)状态。
S5、Py向C1返回写入成功的RESPONSE，进入本地prepared状态。
此时Px、Py均回应并进入本地prepared状态，则C1可以确认该全局写事务已完成prepare阶段，可以进入提交(commit)阶段。
S6、C1上T1进入提交(commit)阶段，指示Px提交tsc＝1。
此时Px的上一个提交完成的数据，即最新提交完成的数据更新为lastCommit[x]＝1，versions＝{x1}。
S7、假设Py还未提交时，新来了一个全局读事务T2，全局读事务T2分别向Px、Py中读取数据r，即读取[r(x),r(y)]。
C2向Px读(GET)数据i＝x，
C2向Py读(GET)数据i＝y，
S8、Px向C2返回数据包的RESPONSE，x1，md＝{y}。
S9、Py向C2返回数据包的RESPONSE，
md＝{}。
S10、C2从Py读数据时是读取上一个提交完成的数据，为空未读到任何数据，从Px读取到最新版本的数据x1，并确定最新版本数据为vlatest←{x:1,y:1}，则向Py再次GET数据i＝y，tsreq＝1。
S11、Py向C2返回数据包的RESPONSE，y1，md＝{x}。
S12、C2确定均提交完成全局读事务T2，确定全局提交完成，commit T2，最终获得读取的数据resp＝{x1,y1}。
S13、之后C1上T1才指示Py提交tsc＝1。
此时Py的上一个提交完成的数据，即最新提交完成的数据更新为lastCommit[y]＝1，versions＝{y1}。
S14、Px向C1返回RESPONSE，进入本地提交完成(committed)状态。
S15、Py向C1返回RESPONSE，进入本地committed状态。
此时Px、Py均提交完成，则C1可以确认事务已全局提交完成，commit T1，处于全局committed状态，结束该全局写事务。
根据如图1所示实施例，上述S7-S12为全局读事务执行过程，可知在全局写事务T1的两个数据节点已经过了prepare阶段，事务可以提交，但是Px数据节点提交完成，Py还未提交，此时新来的全局读事务T2在第一次读时，从Px、Py读到的数据版本是不一致的，如上述步骤S8和步骤S9，该数据不一致的问题在去中心化的分布式数据库中存在，其本质即是DRCC异常，这里如图1所示的实施例中在数据不一致时又进行了第二次读，如上述步骤S10和步骤S11，即采用了两次读的方式，第一次读时对不同数据节点读到的数据进行判断，不一致时再进行第二次读，第二次读时要求读数据节点上处于perpared状态的版本的数据，从而保证不同数据节点读到的数据一致，虽然最后也使得读取数据是一致的，但是把一个事务，切割为二次读，增加了一次读操作，增加了事务处理时间，客观上也减少了单位时间内事务的吞吐量，导致事务处理的效率降低。
又例如，假设事务T写两个节点，做转账操作，具体如下：
BEGIN GLOBAL；//申请一个全局事务标识gxid，假设为20
UPDATE user_account SET my_wallet＝my_wallet–10WHERE key＝100；//节点Na，本地lxid为18
UPDATE user_account SET my_wallet＝my_wallet+10WHERE key＝900；//节点Nb，本地lxid为22
COMMIT；
节点Na上的key为100的元组，其元组上的事务标识(identification，ID)为一个二元组：{gxid，lxid}＝{20，18}；节点Nb上的key为900的元组，其元组上的事务ID为一个二元组：{gxid，lxid}＝{20，22}。这样，通过{gxid，lxid}就可以识别来自不同节点的数据，是否是同一个全局事务操作的数据，即是否属于同一个事务。
例如，若节点Na下一个事务是全局事务，则事务号为{gxid，lxid}＝{21，19}，再下一个事务是局部事务，则事务号为{gxid，lxid}＝{0，20}，再下一个事务是全局事务，则事务号为{gxid，lxid}＝{22，21}，依次类推。
基于该实施例，参阅图2所示，为现有技术中DRCC异常发生示意图，初始时两个数据节点Na:X、Nb:Y，在执行全局写事务过程中，Na数据节点和Nb数据节点的全局写事务状态不同，提交状态不同，例如Na数据节点的操作为X＝X-10，状态为本地committed，即已提交完成，Na上key＝100的账户额度已减去了10元，而Nb数据节点的操作为Y＝Y+10，状态为committing，此时虽然Nb上数据增加了10但还未提交完成，则执行全局读事务时，读到Na上key＝100的账户额度已减去了10元，但是读到Nb上key＝900的账户额度还没有增加10元，这种情况下转账不平衡，数据不一致，称之为DRCC异常。
另外，为更好地理解本发明实施例，下面对DRCC异常发生原因进行简单分析，以采用不同的并发控制技术为例进行说明，可以分为以下几种情况：
第一种情况：假设各个数据节点使用了SS2PL技术，而分布式数据库使用了分布式提交排序(Commitment Ordering，CO)算法和原子提交协议，这时如图2所示，读数据异常发生时，Na数据节点子事务提交而锁被释放，因此新值可读，Nb数据节点子事务没有提交并且锁没有释放(此处表明本问题和隔离级别没有关系，任何隔离级别下封锁的并发机制都会因写操作而加排它锁)，因而读取不到Nb数据节点上最新的值，即读事务被阻塞直至写事务被提交或回滚之后才能读取到。而根据原子提交协议可知，Na数据节点能提交是因为所有数据节点都同意提交，所以Nb数据节点所处的状态是同意提交但未提交，因此若没有时延或分区发生，则Nb数据节点很快提交，全局读事务可以满足读一致性，但是若分区恰好发生在Nb数据节点同意提交之后，或者此后Nb数据节点宕机，更复杂一点的是多副本机制下多数副本宕机，则Na数据节点应该在原子提交协议下被标识为事务提交无效而回滚已提交的子事务，此时，对于全局读事务而言，读Na数据节点的操作发生不可逆，调度器应当回滚该全局读事务以保证读一致性，因此，在数据节点使用了SS2PL技术的分布式数据库中不存在DRCC异常。
第二种情况：假设各个数据节点使用了MVCC机制，全局读事务在读取了Na数据节点上的新值后，能够读取到Nb数据节点上的旧值，这是因为MVCC机制写不阻塞读，但Nb数据节点上新值尚未提交，因此只能读到旧版本的值，因而会发生DRCC异常。
第三种情况：假设Na数据节点使用SS2PL技术，而Nb节点使用了MVCC机制，同样的情况下也会发生DRCC异常。
第三种情况：假设Nb数据节点基于MVCC机制使用全双工的串行接口(SynchronousSerialInterface，SSI)技术，同样的情况下，也会因读操作选择了旧版本而发生DRCC异常，因此可知即使在可串行化隔离级别下，依旧存在DRCC异常。
因此，本发明实施例中主要针对上述问题，提出了一种分布式数据的读取方法，主要是针对分布式系统中单个节点的数据库，并发访问控制方法基于MVCC机制发生的数据异常情况，并且需要说明的是，本发明实施例是针对分布式系统中各个节点都正常运行时全局读不一致的场景，不涉及单点故障引发的不一致问题，具体地，本发明实施例中维护全局写事务状态信息，进而针对全局读事务请求，分别获取对应的各数据节点根据本地记录的子写事务状态返回的数据，各数据节点可以通过子写事务状态进行可见性判断，可以返回一个或多个版本的数据，进而再从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据，这样，通过维护全局写事务状态信息，在跨节点读取数据时，数据节点可以返回一个或多个版本的数据，对于多版本的数据进行全局一致性识别，保证最终获取的数据是一致性的，并且全局读事务可以通过至多一轮的通信完成，不需要多次读，降低了事务处理时间，提高了效率，并且本发明实施例中不需要设置专门的全局事务管理节点，实现了去中心化的全局一致性的数据读取，提升了性能。
参阅图3所示，为本发明实施例中分布式事务处理架构示意图，至少包括应用程序、网关、Scheduler、ZookKeeper、Set1、SetM、全局gxid生成集群，其中，网关、Scheduler、Set1、SetM、全局gxid生成集群之间的交互都是通过ZookKeeper完成，可以极大简化各个节点之间的通信机制，实现简单。其中，Set1、SetM、全局gxid生成集群可以采用多副本结构，例如分为主节点、备节点1和备节点2，可以提高可靠性，避免单点故障。
a、应用程序为能够支持分布式数据访问的软件应用程序，例如MySQL应用程序等，应用程序可以运行在客户端，并且提供应用程序的应用程序接口(Application ProgramInterface，API)，例如MySQL API，其中客户端可以是智能手机、平板电脑、便携式个人计算机、智能电视等任何智能设备，例如应用程序在客户端运行时，可以向服务器发送全局写事务请求或全局读事务请求，也可以接收服务器返回的数据等。
b、网关主要用于：
(1)解析SQL，识别出ddl操作，并以任务形式保存到ZooKeeper，让ZooKeeper来统一调度。
(2)识别出dml操作，进行sql转换并发到对应的set中的主或备机。
(3)收集set内各个节点的应答，组合处理后返回给前端应用API。
(4)监控ZooKeeper的路由信息，拉取路由、权限等信息。
c、ZookKeeper，主要用于实现网关、Scheduler、Set1、SetM、全局gxid生成集群之间的通信交互。
d、Scheduler，主要用于：
(1)从ZooKeeper拉取ddl任务，并在实际的MySQL实例上执行。
(2)从ZooKeeper中获取状态，生成扩容任务。
(3)管理set，控制set内的主备机的切换等操作。
(4)多个Scheduler自身通过ZooKeeper的选举机制实现容灾。
e、Set1、SetM，主要由MySQL和Agent构成，Agent模块负责监控本机MySQL实例的运行情况，可以采用多副本机制，例如包括主节点、备节点1、备节点2，主要用于：
(1)监控实例状态并上报到ZooKeeper。
(2)监控表的状态并上报到ZooKeeper。
(3)从ZooKeeper中拉取迁移任务并执行。
(4)参与主备切换流程。
f、全局gxid生成集群，本发明实施例中通过增加了全局gxid生成集群，实现了轻量的事务处理架构，主要是因为全局gxid生成集群功能单一，可以在内存中批量生成gxid，效率会极高，相对于一个实现了全局事务管理、冲突访问控制、MVCC机制的全局事务管理器而言，明显提高了性能，全局gxid生成集群可以采用多副本机制，例如包括主全局gxid生成节点、第一备全局gxid生成节点、第二备全局gxid生成节点，可以提高可靠性，当然若需要提高可靠性或考虑其它实际情况，也可以采用五副本、甚至更多副本等，本发明实施例中并不进行限制。全局gxid生成集群主要用于：
(1)生成全局事务标识，其中，全局事务表示跨节点操作，可以包括全局读事务或全局写事务。
其中，全局事务标识的取值为数值型，单调递增。
具体地，当有一个全局事务发生时，就会向全局gxid生成集群申请一个全局事务标识，可以全局唯一标识该全局事务。
(2)维护全局写事务状态信息。
具体地：本发明实施例中在全局写事务执行过程中，在全局gxid生成集群中维护全局写事务状态信息，这样目的是为了实现本发明实施例中分布式数据读取时保持读一致性。
本发明实施例中，全局gxid生成集群采用多副本机制，可以避免单点故障，提高可靠性，丢失事务状态信息的可能性非常小。
其中，全局写事务状态信息至少包括全局事务标识、最新的全局写事务状态、对应的各数据节点。
例如，全局写事务状态信息由三元组表示：{gxid，status，nodes}，其中：
a)gxid代表全局事务标识。
b)status代表最新的全局写事务所处的状态，即最新的全局写事务状态，全局写事务状态包括正在执行(running)、正在准备(preparing)、正在提交(committing)、正在回滚(aborting)、全局提交完成(committed)、全局回滚完成(aborted)，其中，running表示全局写事务正在执行，preparing表示全局写事务2PC进入提交阶段，正处于prepare阶段，committing表示全局写事务已经完成prepare阶段，正处于commit阶段，aborting表示全局写事务正处于回滚阶段，全局committed表示全局写事务已经全局提交完成，全局aborted表示全局写事务已经全局回滚完成。
需要说明的是，上述全局写事务状态表示全局写事务的整体状态，即全局写事务的全局状态。其中，全局写事务的全局committed状态，表示全局写事务全局提交，是涉及的所有数据节点都已经提交完成；全局写事务的全局aborted状态是指涉及的所有数据节点都已经回滚完成。并且，本发明实施例中，在全局写事务提交后，会将全局写事务的全局committed状态同步到所有涉及到的数据节点，同样地，若确定全局回滚完成，也会将全局aborted状态同步到所有涉及到的数据节点，该同步操作会等到下一次写事务或读事务开始时，即数据节点和全局gxid生成集群产生必要通信时进行，因此，是一个异步的操作，不会产生一轮额外的通信。
c)nodes代表当前全局事务涉及到的数据节点。
另外，对于全局gxid生成集群中事务状态信息的维护，本发明实施例中还提供了以下实施方式：
1)因为已经全局提交完成的事务状态信息将不再被使用，因此若确定事务已全局提交完成，则将该条事务的事务状态标志为已失效，并移入垃圾回收区，等待清理线程清理，并且这种批量清理的模式，可以采用异步清理方式，从而提升性能。
2)对于已经全局回滚完成的事务，可以通过独立的回滚事务栈维护，以供重试机制使用。
基于上述应用架构图可知，本发明实施例中不需要设置单点的、复杂而耗时的全局事务管理器，分布式数据读取方法可以作用于分布式系统的部件上，可以认为是一种去中心化的分布式数据读取方法，并且本发明实施例中通过增加一个全局gxid生成集群，功能单一，可以在内存中批量生成gxid，效率比较高，因此，提供的分布式事务处理架构也是一个轻量级的、去中心化的分布式处理架构，还可以适用于混合型分布式数据库，例如事务型或分析型，在分布式数据库的架构层面，也提高了整个系统的性能。
另值得说明的是，本发明实施例中的应用架构图是为了更加清楚地说明本发明实施例中的技术方案，并不构成对本发明实施例提供的技术方案的限制，对于其它的应用架构和业务应用，本发明实施例提供的技术方案对于类似的问题，同样适用，例如本发明实施例可以适用于分布式数据库、分布式大数据处理等系统、存在跨节点的全局写操作的事务型系统等场景，其中，分布式数据库例如SQL、NoSQL、NewSQL、关系型、非关系型等，本发明实施例中并不进行限制，均可以基于本发明实施例中分布式数据读取方法来保证跨节点的全局读操作消除掉数据异常。
本发明各个实施例中，以分布式数据读取方法用于图3所示的应用架构图为例进行示意性说明。
基于上述实施例可知，在全局写事务执行过程中，发生全局读事务可能会出现数据读取不一致的数据异常情况，因此，为便于说明本发明实施例中分布式数据读取方法，下面先对分布式数据写过程进行简单说明，参阅图4所示，为本发明实施例中，分布式数据写方法的流程图，该方法包括：
步骤400：获取全局写事务请求对应的全局事务标识，并确定全局写事务请求对应的各数据节点。
本发明实施例中，发生全局事务时，不管为全局写事务还是全局读事务，就会向全局gxid生成集群中申请一个对应的全局事务标识，因此，接收全局写事务请求时，发生全局写事务，会获取一个该全局写事务对应的全局事务标识。
例如，该全局写事务请求对应的全局事务标识为15，分别在数据节点A和数据节点B上写数据。
步骤410：分别向全局写事务请求对应的各数据节点写入数据，并更新记录的全局写事务状态信息，其中，全局写事务状态信息至少包括全局事务标识、最新的全局写事务状态、对应的各数据节点。
具体包括：1)分别向全局写事务请求对应的各数据节点写入数据。
具体地可以采用XA技术，分别向各数据节点写入数据，实现跨节点的写操作，当然也可以采用其它技术，本发明实施例中并不进行限制。
其中XA技术核心是2PC技术，目前例如PostgreSQL、MySQL/InnoDB、Informix、Oracle等主流单机数据库，均实现了XA技术，可以保证跨节点写操作事务的一致性和原子性，适用范围较广，实现简单有效。
其中，各数据节点中写入数据后，其对应存储的数据项中至少包括全局事务标识、本地事务标识、表示不同版本的时间戳。
具体地本发明实施例中针对数据项结构进行了改进，参阅图5所示，为现有技术中数据项结构示意图，如图5所示的常规数据项结构，即数据的元组结构，例如MySQL/InnoDB的元组结构，主要包括事务ID等字段，而参阅图6所示，为本发明实施例中数据项结构示意图，可知本发明实施例中较现有技术中的结构，事务标识分为gxid和lxid两个标识，其中，gxid为全局事务标识，lxid为本地事务标识，并且增加了Prepared Time字段，PreparedTime的取值用一个分布式下全局的逻辑时间戳表示，效果上等同于gxid，该时间戳用于表示本条数据项的本版本，即不同版本的数据可以通过时间戳来索引，在2PC技术的架构下，该时间戳表示是在什么时候完成分布式prepare阶段的，即所有的数据节点都同意事务提交对应的逻辑时间点，此时没有事务冲突发生且该分布式事务可以提交。
这样，本发明实施例中提供的数据项结构，不仅可以识别不同数据节点上的数据是否属于同一个全局事务，还可以识别一个数据的不同版本，以便于后续进行分布式数据读取时识别出各个数据节点上版本一致的数据。
2)更新记录的全局写事务状态信息。
其中，全局写事务状态信息至少包括全局事务标识、最新的全局写事务状态、对应的各数据节点。
本发明实施例中，在全局写事务执行过程中，在全局gxid生成集群中维护全局写事务状态信息，将全局写事务状态信息更新到全局gxid生成集群是一个在提交阶段、单向同步写入的过程，并可以使用2PC技术保证写入的原子性。
进一步地，还包括：若在更新记录的全局写事务状态信息时，确定存在全局读事务正在执行，则将更新记录的全局写事务状态信息的更新操作进行缓存，并在确定全局读事务执行完成后，执行该更新操作。这样，在全局读事务执行过程中，将所有更新操作暂存到缓存区，待全局读事务执行完成后，再将这一批更新操作进行批量执行，可以保证全局读事务执行过程中获取到的最新的全局写事务状态是符合一致性的。
进一步地，为保证全局写事务状态在各数据节点本地的子写事务状态一致，本发明实施例中还提供了一种可能的实施方式，若确定最新的全局写事务状态为全局committed状态或全局aborted状态，则将最新的全局写事务状态同步到对应的各数据节点；其中，全局committed状态表示对应的各数据节点均提交完成，全局aborted状态表示对应的各数据节点均回滚完成。这样，全局写事务状态为全局committed或全局aborted状态时，同步到涉及到的各数据节点，各数据节点可以相应地将记录的子写事务状态更新为全局committed或aborted状态。
本发明实施例中，提供了一种分布式数据写方法，针对全局写事务请求，在执行全局写事务过程中，向对应的各数据节点写入数据，并更新记录的全局写事务状态信息，这样，通过维护和更新全局写事务状态信息，可以在后续对分布式数据读取时，提供最新的全局写事务状态信息，以进行全局一致性识别，最终获得符合全局一致性版本的数据。
在全局写事务执行过程中，若该全局写事务还未达到全局committed状态或全局aborted状态，此时若有全局读事务，跨节点进行数据读取时，本发明实施例中针对全局写事务处于的不同状态，读取数据的不同情况进行处理，保证最终获得的数据一致性。
具体参阅图7所示，为本发明实施例中一种分布式数据读取方法的流程图，该方法包括：
步骤700：将全局读事务请求发送给对应的各数据节点。
步骤710：分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据。
其中，返回的数据为针对全局读事务请求的目标数据，子写事务状态表示全局写事务在数据节点上的局部状态；一个版本为最新子写事务状态处于全局committed状态或全局aborted状态的版本，多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本。
这里的子写事务状态是全局写事务相对该数据节点的局部状态。
其中，子写事务状态可以包括以下几种：
a、本地prepared状态，即该全局写事务已经开启2PC流程，并且在本数据节点上已经完成prepare操作。
b、本地committed状态、本地aborted状态，即全局写事务已经进入2PC的提交或回滚阶段，但全局提交状态未知，不确定是否全局已提交完成。
c、全局committed状态、全局aborted状态，即全局写事务已经全局提交或全局回滚，并且已经将全局提交或全局回滚状态同步到数据节点。
本发明实施例中，读取数据节点上数据时，数据节点可以返回一个或多个版本的数据，具体根据该版本上对应的本地记录的子写事务状态而定，这不同于现有技术中的MVCC技术，现有技术中MVCC技术对于同一个数据项，可以有多个版本，每个版本都是UPDATE操作生成，第一个版本除外，其是由INSERT操作生成，MVCC技术可以提供Snapshot，即快照，快照里面包括了活跃事务列表，通过活跃事务列表，可以知道哪些数据版本是活跃事务正在写的，若没有提交，不应被读取，跳过正在写的版本，顺着反向指针回溯寻找最新但处于提交状态的版本，这样的版本就是一个可读的版本数据，即现有技术中MVCC技术每次有且仅有一个版本的数据可见，而本发明实施例中进行了改进，对于每一个数据项，可以有多个版本可见，来适应分布式数据库的需求。
其中，最近一个版本可见，即返回一个版本为最新子写事务状态处于全局committed状态或全局aborted状态的版本。
多个版本可见，较佳的为两个版本可见，即返回两个版本，包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本。
则具体执行步骤710时，包括以下几种情况：
第一种情况：若数据节点确定存在r(n+1)版本的数据，并处于本地prepared状态，则获取数据节点返回的r(n)和r(n+1)版本的数据。
也就是说，存在r(n+1)版本处于本地prepared状态，说明该版本数据上有全局写事务正在2PC阶段，且未完成全局prepare，则版本r(n)和r(n+1)可见。
第二种情况：若数据节点确定存在r(n+1)版本的数据，并处于本地committed状态，则获取数据节点返回的r(n)和r(n+1)版本的数据。
若存在版本r(n+1)处于本地committed状态，说明该版本数据上有全局写事务正在2PC阶段，且全局prepare已经完成，但全局提交未完成，则版本r(n)和r(n+1)可见。
第三种情况：若数据节点确定存在r(n+1)版本的数据，并处于本地aborted状态，则获取数据节点返回的r(n)和r(n+1)版本的数据。
若存在版本r(n+1)处于本地aborted状态，说明该版本数据上有全局写事务正在2PC阶段，且全局prepare已经完成，但全局回滚未完成，则版本r(n)和r(n+1)可见。
第四种情况：若数据节点确定存在r(n+1)版本的数据，并处于全局committed状态，则获取数据节点返回的r(n+1)版本的数据。
若存在版本r(n+1)处于全局committed状态，说明该版本数据上的全局写事务已经全局提交，此时跨节点读取时，所有涉及的数据节点都处于全局committed状态，都可以读取到最新的数据，则版本r(n+1)可见。
第五种情况：若数据节点确定存在r(n+1)版本的数据，并处于全局aborted状态，则获取数据节点返回的r(n)版本的数据。
若存在版本r(n+1)处于全局aborted状态，说明该版本数据上的全局写事务已经全局回滚完成，则版本r(n)可见。
第六种情况：若数据节点确定不存在r(n+1)版本的数据，则获取数据节点返回的r(n)版本的数据。
若不存在版本r(n+1)，说明目前没有正在执行的全局写事务，则版本r(n)可见。
上述数据节点根据本地记录的子写事务状态返回一个版本或多个版本的数据的方式，本发明实施例中也可以称之为同时读可见性判断算法。
进一步地，数据节点返回数据时，还可以设置响应超时重发机制，若该数据节点在设定时长内未接收到回复确认收到指令，则数据节点会重发该数据，并且还可以设置重发次数阈值，例如为3次，重发次数不超过该重发次数阈值，若超过该重发次数阈值，则不再返回数据。
这样，本发明实施例中针对全局读事务请求，对全局读事务请求对应的每个数据节点都进行数据读取，各数据节点通过同时读可见性判断算法，返回局部可见的一个或两个版本的数据，可以适应不同全局写事务状态，满足后续确定全局一致性版本的需求，保证数据一致性，并且至多通过一轮通信，减少通信次数，提高效率，节省了时间。
步骤720：从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据。
执行步骤720时，具体可以包括以下两种情况：
第一种情况：若返回的数据为一个版本，则直接将该版本的数据确定为符合全局一致性的版本的数据。
也就是说，在确定只有一个版本时，则该版本符合全局一致性，不需要进行额外判断。
第二种情况：若返回的数据有多个版本，则根据返回的数据上记录的全局事务标识，获取全局事务标识对应的最新的全局写事务状态，并根据返回的数据对应的子写事务状态和最新的全局写事务状态，从多个版本的数据中确定出符合全局一致性的版本的数据；其中，最新的全局写事务状态表示全局写事务的全局状态。
本发明实施例中，对存在多个版本的数据还需要进行全局一致性识别，获取满足全局一致性的版本的数据，本发明实施例中也可以称之为元组全局一致性识别。
具体包括：
S1、根据返回的数据上记录的全局事务标识，获取全局事务标识对应的最新的全局写事务状态。
本发明实施例中，根据数据项的结构，数据的数据项上记录有全局事务标识，若有多个版本，根据当前未处于全局committed状态或全局aborted状态的版本，从该版本上获取记录的全局事务标识，并根据该全局事务标识，从全局gxid生成集群中获取对应的最新的全局写事务状态。
S2、根据返回的数据对应的子写事务状态和最新的全局写事务状态，从多个版本的数据中确定出符合全局一致性的版本的数据。
具体地：若返回的数据有r(n)和r(n+1)2个版本，则根据r(n+1)版本对应的子写事务状态和最新的全局写事务状态，从r(n)和r(n+1)中确定出符合全局一致性的版本的数据。
其中，从r(n)和r(n+1)中确定出符合全局一致性的版本的数据时，可以分为以下几种情况：
第一种情况：若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态为preparing状态时，则阻塞该全局读事务请求对应的全局读事务，并在确定最新的全局写事务状态更新为committing状态时，重新启动该全局读事务，并重新执行分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据的步骤；或在确定最新的全局写事务状态更新为aborting状态时，回滚该全局读事务。
也就是说，全局写事务状态为preparing状态时，不知道该全局写事务之后是回滚还是提交，因此，先阻塞全局读事务，当等待该全局写事务状态更新为committing状态时，可以重启该全局读事务，重新执行数据读取和全局一致性识别，当等待该全局写事务状态更新为aborting状态，则回滚全局读事务。
第二种情况：若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态处于committing状态时，则确定出符合全局一致性的版本的数据为r(n+1)版本数据。
这样，通过判断识别出了还未处于全局committed状态的版本为全局一致性版本，不需要再次去读取，可以直接通过提前读取本地prepared状态，但未全局提交的版本，解决了DRCC异常，保证数据一致性。
第三种情况：若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态为aborting状态，则在确定各数据节点返回的数据中均包含被更新或删除的数据时，确定符合全局一致性的版本的数据为r(n)版本数据。
若全局写事务为aborting状态，则需要遍历该全局写事务所操作的数据节点返回的数据，如果每一个数据节点所返回的数据均包含被该全局写事务更新或删除的数据项，即判断是否包括r(n)版本，若包含r(n)版本，则r(n)版本可见，否则，回滚该全局读事务。
其中，这里需要的数据遍历筛选操作，可以通过布隆过滤器进行优化，从而提升筛选的性能。
第四种情况：若r(n+1)版本处于本地committed状态，并最新的全局写事务状态为committing或全局committed状态时，则确定符合全局一致性的版本的数据为r(n+1)版本数据。
这样，可以直接通过提前读取prepared状态，但未全局提交的版本，解决了DRCC异常，保证最终获取的数据的一致性，也不需要第二次读，提高效率。
第五种情况：若r(n+1)版本处于本地aborted状态，并最新的全局写事务状态为aborting或全局aborted状态时，则确定符合全局一致性的版本的数据为r(n)版本数据。
进一步地，针对多个版本的数据，对于不符合全局一致性的版本的数据，可以将该不符合全局一致性的版本的数据进行丢弃。
基于上述几种情况可知，在存在r(n+1)和r(n)两个版本时，需根据r(n+1)上记录的全局事务标识，向全局gxid生成集群获取对应的最新的全局写事务状态，在r(n+1)版本处于本地prepared状态下，全局写事务状态只能是preparing状态、committing状态、aborting状态中的一种，在r(n+1)版本处于本地committed状态下，全局写事务状态只可能是committing和全局committed状态中的一种，在r(n+1)版本处于本地aborted状态下，全局写事务状态只可能是aborting和全局aborted状态中的一种，通过基于最新的全局写事务状态和r(n+1)版本上记录的子写事务状态，从中识别出符合全局一致性的版本，从而获得全局一致性的版本的数据，保证从各个数据节点上读取的数据的一致性。
需要说明的是，本发明实施例的图7所示实施例中分布式数据读取方法的执行主体可以有以下三种模式，分别适用于不同的系统架构：1)客户端模式，可以由客户端中应用程序执行，例如，客户端向服务器发送全局读事务请求后，接收各数据节点返回的数据，并在客户端进行统一的全局一致性识别，确定出一致性版本数据。2)中心节点模式，设置单独的协调节点，由该协调节点针对全局读事务请求，汇总各数据节点返回的数据，并进行全局一致性识别，将结果返回给客户端，客户端可以获取到最终确定的全局一致性版本数据。3)去中心节点模式，不单独设置协调节点，而可以是由某一个数据节点充当协调节点，来汇总数据，并进行全局一致性识别，将结果返回给客户端。对于这三种模式，本发明实施例中并不进行限制，可以根据实际需求进行设置。
本发明实施例中，针对全局读事务请求，将该全局读事务请求发送到对应的各数据节点，以使各数据节点返回数据包，可以分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据，进而从中确定出符合全局一致性的版本的数据，这样，不是仅从数据节点上读取一个版本的数据，而是数据节点根据其本地记录的子写事务状态返回一个或多个版本的数据，通过一次读取，后续再从中进行识别，最终确定全局一致性版本的数据，不需要分2次读，节省了时间，提高了效率，并且还可以保证数据一致性，解决了全局事务读取数据异常的问题。
并且，通常分布式系统中，读数据不一致产生的根本原因是在分布式系统中缺少全局事务管理器，但是如果专门设置一个全局事务管理节点，很可能成为一个单点瓶颈，造成单点故障，因此，全局事务管理需要被分散到分布式系统中的各个部件中，从而达到去中心化的目的。
本发明实施例中的分布式数据读取方法，可以通过利用单机节点上的MVCC技术，对MVCC技术进行改进，采用读多个版本方式，较佳的采用最多读两个版本的方式，全局读事务可以通过至多一轮的通信完成，并且全局读事务的回滚率也得到了降低。
基于上述实施例，本发明实施例中还提供了另一种数据节点侧的分布式数据读取方法，参阅图8所示为本发明实施例中另一种分布式数据读取方法的流程图，该方法包括：
步骤800：接收全局读事务请求。
步骤810：根据本地记录的子写事务状态返回一个版本或多个版本的数据，以使数据接收方从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据。
其中，返回的数据为针对全局读事务请求的目标数据，子写事务状态表示全局写事务在数据节点上的局部状态；一个版本为最新子写事务状态处于全局提交完成committed状态或全局回滚完成aborted状态的版本，多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本。
其中，数据接收方可以为客户端、协调节点，本发明实施例中并不进行限制。
子写事务状态包括：本地prepared状态、本地committed状态、本地aborted状态、全局committed状态和全局aborted状态。
则具体地，执行步骤810包括以下几种情况：
1)若确定存在r(n+1)版本的数据，并处于本地prepared状态，则返回r(n)和r(n+1)版本的数据。
2)若确定存在r(n+1)版本的数据，并处于本地committed状态，则返回r(n)和r(n+1)版本的数据。
3)若确定存在r(n+1)版本的数据，并处于本地aborted状态，则返回的r(n)和r(n+1)版本的数据。
4)若确定存在r(n+1)版本的数据，并处于全局committed状态，则返回的r(n+1)版本的数据；
5)若确定存在r(n+1)版本的数据，并处于全局aborted状态，则返回的r(n)版本的数据。
6)若确定不存在r(n+1)版本的数据，则返回的r(n)版本的数据。
另具体地数据接收方从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据的实施方式，同上述实施例中方式相同这里就不再进行赘述了。
这样，在接收到全局读事务请求时，数据节点可以返回一个或多个版本的数据，即可以只返回最新子写事务状态处于全局committed状态或全局aborted状态的版本，也可以返回最新子写事务状态处于全局committed状态或全局aborted状态的版本和当前未处于全局committed状态或全局aborted状态的版本，从而可以使得后续从一个或多个版本中识别出全局一致性版本的数据，解决了全局读数据不一致的问题，并且通过判断一次可以返一个或多个版本数据，至多一次通信，节省了时间，效率更高。
基于上述实施例，下面采用具体应用场景进行说明，以验证本发明实施例中分布式数据读取方法的正确性和可靠性。以全局写事务涉及两个数据节点为例，分别为数据节点A和数据节点B，全局写事务为T，假设全局写事务T在数据节点A上和数据节点B节点上分别操作版本x(n)和y(n)，并产生版本x(n+1)和y(n+1)，则基于本发明实施例中的分布式数据读取方法进行读取时，会有以下几种情况和结果：
a)若在数据节点A和数据节点B上均已完成提交，即均处于全局committed状态，因此两个数据节点上均会返回最新已提交版本，即x(n+1)和y(n+1)，因此满足一致性。
b)如果在数据节点A和数据节点B上均已回滚提交完成，即均处于全局aborted状态，因此两个数据节点上均会返回最新已提交版本，即回滚后的版本，即x(n)和y(n)，因此满足一致性。
c)如果在数据节点A上已经提交完成，但数据节点B上还未提交，即数据节点A处于本地committed状态，数据节点B可能处于本地prepared状态，这时会发生DRCC异常，则通过提前读取已经prepare完成，但未全局提交的数据，解决了DRCC异常，最终读取到x(n+1)和y(n+1)版本的数据，满足一致性。
d)如果在数据节点A上已经回滚，但数据节点B上还未回滚，即数据节点A处于本地aborted状态，数据节点B可能处于其它未提交完成状态，则通过判断结果集合中是否包含x(n)和y(n)，如果包含，则读取x(n)和y(n)，否则，回滚当前全局读事务。
e)如果在数据节点A和数据节点B上都已经prepare完成，即均处于本地prepared状态，则通过提前读取已经prepare完成，但未全局提交的数据，最终获取到x(n+1)和y(n+1)版本的数据，满足一致性。
f)如果在数据节点A上已经prepare完成，但数据节点B上还未开始prepare，即数据节点B上未读取到r(n+1)版本数据，因为读取数据缺失，因此会阻塞该全局读事务，并在全局写事务进入committing或aborting时，选择回滚或重启该全局读事务。
g)如果在数据节点A上但数据节点B上均未开始prepare，即均未读取到r(n+1)版本，此时读取版本x(n)和y(n)，满足一致性。
因此，根据上述具体应用场景的验证结果，也可以得知本发明实施例中分布式数据读取方法，可以保证最终读取的数据一致性，解决了数据异常问题，并且至多一轮通信，减少通信量，节省了时间，也提高了效率。
基于上述实施例，参阅图9所示，本发明实施例中一种分布式数据读取装置，包括：
发送模块90，用于将全局读事务请求发送给对应的各数据节点；
获取模块91，用于分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据，其中，返回的数据为针对所述全局读事务请求的目标数据，所述子写事务状态表示全局写事务在数据节点上的局部状态；所述一个版本为最新子写事务状态处于全局committed状态或全局aborted状态的版本，所述多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本；
确定模块92，用于从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据。
可选的，进一步包括：
处理模块93，用于获取全局写事务请求对应的全局事务标识，并确定所述全局写事务请求对应的各数据节点；
写模块94，用于分别向所述全局写事务请求对应的各数据节点写入数据；
更新模块95，用于更新记录的全局写事务状态信息，其中，所述全局写事务状态信息至少包括全局事务标识、最新的全局写事务状态、对应的各数据节点。
可选的，进一步包括：
同步模块96，用于若确定最新的全局写事务状态为全局committed状态或全局aborted状态，则将所述最新的全局写事务状态同步到对应的各数据节点；其中，全局committed状态表示对应的各数据节点均提交完成，全局aborted状态表示对应的各数据节点均回滚完成；
更新模块95还用于：若在更新记录的全局写事务状态信息时，确定存在全局读事务正在执行，则将更新记录的全局写事务状态信息的更新操作进行缓存，并在确定所述全局读事务执行完成后，执行所述更新操作。
可选的，所述子写事务状态包括：本地准备完成prepared状态、本地committed状态、本地aborted状态、全局committed状态和全局aborted状态。
结合本发明另一个实施例，分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据时，获取模块91具体用于：
若数据节点确定存在r(n+1)版本的数据，并处于本地prepared状态，则获取数据节点返回的r(n)和r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于本地committed状态，则获取数据节点返回的r(n)和r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于本地aborted状态，则获取数据节点返回的r(n)和r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于全局committed状态，则获取数据节点返回的r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于全局aborted状态，则获取数据节点返回的r(n)版本的数据；
若数据节点确定不存在r(n+1)版本的数据，则获取数据节点返回的r(n)版本的数据。
可选的，从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据时，确定模块92具体用于：
若返回的数据为一个版本，则直接将该版本的数据确定为符合全局一致性的版本的数据；
若返回的数据有多个版本，则根据返回的数据上记录的全局事务标识，获取所述全局事务标识对应的最新的全局写事务状态，并根据返回的数据对应的子写事务状态和所述最新的全局写事务状态，从多个版本的数据中确定出符合全局一致性的版本的数据；其中，所述最新的全局写事务状态表示全局写事务的全局状态。
可选的，根据返回的数据对应的子写事务状态和所述最新的全局写事务状态，从多个版本的数据中确定出符合全局一致性的版本的数据时，确定模块92具体用于：
若返回的数据有r(n)和r(n+1)2个版本，则根据r(n+1)版本对应的子写事务状态和最新的全局写事务状态，从r(n)和r(n+1)中确定出符合全局一致性的版本的数据。
可选的，从r(n)和r(n+1)中确定出符合全局一致性的版本的数据时，确定模块92具体用于：
若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态处于正在提交committing状态时，则确定出符合全局一致性的版本的数据为r(n+1)版本数据；
若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态为正在回滚aborting状态，则在确定各数据节点返回的数据中均包含被更新或删除的数据时，确定符合全局一致性的版本的数据为r(n)版本数据；
若r(n+1)版本处于本地committed状态，并最新的全局写事务状态为committing或全局committed状态时，则确定符合全局一致性的版本的数据为r(n+1)版本数据；
若r(n+1)版本处于本地aborted状态，并最新的全局写事务状态为aborting或全局aborted状态时，则确定符合全局一致性的版本的数据为r(n)版本数据。
可选的，从r(n)和r(n+1)中确定出符合全局一致性的版本的数据时，确定模块92进一步用于：
若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态为preparing状态时，则阻塞所述全局读事务请求对应的全局读事务；
在确定最新的全局写事务状态更新为committing状态时，重新启动所述全局读事务，并以使获取模块91重新执行分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据的步骤；
在确定最新的全局写事务状态更新为aborting状态时，回滚所述全局读事务。
基于上述实施例，参阅图10所示，本发明实施例中另一种分布式数据读取装置，应用于数据节点侧，包括：
接收模块1000，用于接收全局读事务请求；
发送模块1010，用于根据本地记录的子写事务状态返回一个版本或多个版本的数据，以使数据接收方从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据，其中，返回的数据为针对所述全局读事务请求的目标数据，所述子写事务状态表示全局写事务在数据节点上的局部状态；所述一个版本为最新子写事务状态处于全局提交完成committed状态或全局回滚完成aborted状态的版本，所述多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本。
可选的，所述子写事务状态包括：本地准备完成prepared状态、本地committed状态、本地aborted状态、全局committed状态和全局aborted状态。
可选的，根据本地记录的子写事务状态返回一个版本或多个版本的数据时，发送模块1010具体用于：
若确定存在r(n+1)版本的数据，并处于本地prepared状态，则返回r(n)和r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于本地committed状态，则返回r(n)和r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于本地aborted状态，则返回的r(n)和r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于全局committed状态，则返回的r(n+1)版本的数据；
若确定存在r(n+1)版本的数据，并处于全局aborted状态，则返回的r(n)版本的数据；
若确定不存在r(n+1)版本的数据，则返回的r(n)版本的数据。
基于上述实施例，参阅图11所示，本发明实施例中，一种电子设备的结构示意图。
本发明实施例提供了一种电子设备，该电子设备可以包括处理器1110(CenterProcessing Unit，CPU)、存储器1120、输入设备1130和输出设备1140等，输入设备1130可以包括键盘、鼠标、触摸屏等，输出设备1140可以包括显示设备，如液晶显示器(LiquidCrystal Display，LCD)、阴极射线管(Cathode Ray Tube，CRT)等。
存储器1120可以包括只读存储器(ROM)和随机存取存储器(RAM)，并向处理器1110提供存储器1120中存储的程序指令和数据。在本发明实施例中，存储器1120可以用于存储本发明实施例中分布式数据读取方法的程序。
处理器1110通过调用存储器1120存储的程序指令，处理器1110用于按照获得的程序指令执行本发明实施例中的分布式数据读取方法。
基于上述实施例，本发明实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意方法实施例中的分布式数据读取方法。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对相关技术做出贡献的部分可以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台控制设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。
Claims (12)
1.一种分布式数据读取方法，其特征在于，包括：
将全局读事务请求发送给对应的各数据节点；
分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据，其中，返回的数据为针对所述全局读事务请求的目标数据，所述子写事务状态表示全局写事务在数据节点上的局部状态；所述一个版本为最新子写事务状态处于全局提交完成committed状态或全局回滚完成aborted状态的版本，所述多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本；
从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据。
2.如权利要求1所述的方法，其特征在于，进一步包括：
获取全局写事务请求对应的全局事务标识，并确定所述全局写事务请求对应的各数据节点；
分别向所述全局写事务请求对应的各数据节点写入数据，并更新记录的全局写事务状态信息，其中，所述全局写事务状态信息至少包括全局事务标识、最新的全局写事务状态、对应的各数据节点。
3.如权利要求2所述的方法，其特征在于，进一步包括：
若确定最新的全局写事务状态为全局committed状态或全局aborted状态，则将所述最新的全局写事务状态同步到对应的各数据节点；其中，全局committed状态表示对应的各数据节点均提交完成，全局aborted状态表示对应的各数据节点均回滚完成；
若在更新记录的全局写事务状态信息时，确定存在全局读事务正在执行，则将更新记录的全局写事务状态信息的更新操作进行缓存，并在确定所述全局读事务执行完成后，执行所述更新操作。
4.如权利要求1-3任一项所述的方法，其特征在于，所述子写事务状态包括：本地准备完成prepared状态、本地committed状态、本地aborted状态、全局committed状态和全局aborted状态。
5.如权利要求4所述的方法，其特征在于，分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据，具体包括：
若数据节点确定存在r(n+1)版本的数据，并处于本地prepared状态，则获取数据节点返回的r(n)和r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于本地committed状态，则获取数据节点返回的r(n)和r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于本地aborted状态，则获取数据节点返回的r(n)和r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于全局committed状态，则获取数据节点返回的r(n+1)版本的数据；
若数据节点确定存在r(n+1)版本的数据，并处于全局aborted状态，则获取数据节点返回的r(n)版本的数据；
若数据节点确定不存在r(n+1)版本的数据，则获取数据节点返回的r(n)版本的数据。
6.如权利要求5所述的方法，其特征在于，从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据，具体包括：
若返回的数据为一个版本，则直接将该版本的数据确定为符合全局一致性的版本的数据；
若返回的数据有多个版本，则根据返回的数据上记录的全局事务标识，获取所述全局事务标识对应的最新的全局写事务状态，并根据返回的数据对应的子写事务状态和所述最新的全局写事务状态，从多个版本的数据中确定出符合全局一致性的版本的数据；其中，所述最新的全局写事务状态表示全局写事务的全局状态。
7.如权利要求6所述的方法，其特征在于，根据返回的数据对应的子写事务状态和所述最新的全局写事务状态，从多个版本的数据中确定出符合全局一致性的版本的数据，具体包括：
若返回的数据有r(n)和r(n+1)2个版本，则根据r(n+1)版本对应的子写事务状态和最新的全局写事务状态，从r(n)和r(n+1)中确定出符合全局一致性的版本的数据。
8.如权利要求7所述的方法，其特征在于，从r(n)和r(n+1)中确定出符合全局一致性的版本的数据，具体包括：
若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态处于正在提交committing状态时，则确定出符合全局一致性的版本的数据为r(n+1)版本数据；
若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态为正在回滚aborting状态，则在确定各数据节点返回的数据中均包含被更新或删除的数据时，确定符合全局一致性的版本的数据为r(n)版本数据；
若r(n+1)版本处于本地committed状态，并最新的全局写事务状态为committing或全局committed状态时，则确定符合全局一致性的版本的数据为r(n+1)版本数据；
若r(n+1)版本处于本地aborted状态，并最新的全局写事务状态为aborting或全局aborted状态时，则确定符合全局一致性的版本的数据为r(n)版本数据。
9.如权利要求7所述的方法，其特征在于，从r(n)和r(n+1)中确定出符合全局一致性的版本的数据时，进一步包括：
若r(n+1)版本处于本地prepared状态，并最新的全局写事务状态为preparing状态时，则阻塞所述全局读事务请求对应的全局读事务；
在确定最新的全局写事务状态更新为committing状态时，重新启动所述全局读事务，并重新执行分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据的步骤；
在确定最新的全局写事务状态更新为aborting状态时，回滚所述全局读事务。
10.一种分布式数据读取装置，其特征在于，包括：
发送模块，用于将全局读事务请求发送给对应的各数据节点；
获取模块，用于分别获取各数据节点根据本地记录的子写事务状态返回的一个版本或多个版本的数据，其中，返回的数据为针对所述全局读事务请求的目标数据，所述子写事务状态表示全局写事务在数据节点上的局部状态；所述一个版本为最新子写事务状态处于全局committed状态或全局aborted状态的版本，所述多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本；
确定模块，用于从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据。
11.一种分布式数据读取方法，其特征在于，包括：
接收全局读事务请求；
根据本地记录的子写事务状态返回一个版本或多个版本的数据，以使数据接收方从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据，其中，返回的数据为针对所述全局读事务请求的目标数据，所述子写事务状态表示全局写事务在数据节点上的局部状态；所述一个版本为最新子写事务状态处于全局提交完成committed状态或全局回滚完成aborted状态的版本，所述多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本。
12.一种分布式数据读取装置，其特征在于，包括：
接收模块，用于接收全局读事务请求；
发送模块，用于根据本地记录的子写事务状态返回一个版本或多个版本的数据，以使数据接收方从返回的一个版本或多个版本的数据中确定出符合全局一致性的版本的数据，其中，返回的数据为针对所述全局读事务请求的目标数据，所述子写事务状态表示全局写事务在数据节点上的局部状态；所述一个版本为最新子写事务状态处于全局提交完成committed状态或全局回滚完成aborted状态的版本，所述多个版本至少包括最新子写事务状态处于全局committed状态或全局aborted状态的版本、当前未处于全局committed状态或全局aborted状态的版本。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910383137.2A CN110196856B (zh) | 2019-05-09 | 2019-05-09 | 一种分布式数据读取方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910383137.2A CN110196856B (zh) | 2019-05-09 | 2019-05-09 | 一种分布式数据读取方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110196856A CN110196856A (zh) | 2019-09-03 |
| CN110196856B true CN110196856B (zh) | 2022-08-02 |
Family
ID=67752587
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910383137.2A Active CN110196856B (zh) | 2019-05-09 | 2019-05-09 | 一种分布式数据读取方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110196856B (zh) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110807046B (zh) * | 2019-10-31 | 2022-06-07 | 浪潮云信息技术股份公司 | 一种新型分布式newsql数据库智能事务优化方法 |
| CN111259071B (zh) * | 2020-01-04 | 2022-08-05 | 浙江科技学院 | 一种分布式数据库系统中的并发访问控制方法 |
| CN111475585B (zh) * | 2020-06-22 | 2021-06-01 | 阿里云计算有限公司 | 数据处理方法、装置和系统 |
| CN114661690A (zh) * | 2020-12-24 | 2022-06-24 | 中兴通讯股份有限公司 | 多版本并发控制和日志清除方法、节点、设备和介质 |
| CN113239013B (zh) * | 2021-05-17 | 2024-04-09 | 北京青云科技股份有限公司 | 分布式系统及存储介质 |
| CN113778975B (zh) * | 2021-09-15 | 2023-11-03 | 京东科技信息技术有限公司 | 基于分布式数据库的数据处理方法及装置 |
| US20230153282A1 (en) * | 2021-11-15 | 2023-05-18 | International Business Machines Corporation | Chaining version data bi-directionally in data page to avoid additional version data accesses |
| CN114661718B (zh) * | 2022-03-28 | 2023-04-25 | 北京海量数据技术股份有限公司 | Opengauss平台下在线创建本地分区索引的方法及系统 |
| CN115080255B (zh) * | 2022-06-28 | 2023-03-24 | 奇秦科技(北京)股份有限公司 | 一种基于并发安全的分布式批量数据处理方法及系统 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103294675A (zh) * | 2012-02-23 | 2013-09-11 | 上海盛霄云计算技术有限公司 | 一种分布式存储系统中的数据更新方法及装置 |
| CN107577717A (zh) * | 2017-08-09 | 2018-01-12 | 阿里巴巴集团控股有限公司 | 一种保障数据一致性的处理方法、装置及服务器 |
| CN109325022A (zh) * | 2018-07-20 | 2019-02-12 | 新华三技术有限公司 | 一种数据处理方法和装置 |
| CN109710388A (zh) * | 2019-01-09 | 2019-05-03 | 腾讯科技（深圳）有限公司 | 数据读取方法、装置、电子设备以及存储介质 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7904434B2 (en) * | 2007-09-14 | 2011-03-08 | Oracle International Corporation | Framework for handling business transactions |
| US10235440B2 (en) * | 2015-12-21 | 2019-03-19 | Sap Se | Decentralized transaction commit protocol |
-
2019
- 2019-05-09 CN CN201910383137.2A patent/CN110196856B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103294675A (zh) * | 2012-02-23 | 2013-09-11 | 上海盛霄云计算技术有限公司 | 一种分布式存储系统中的数据更新方法及装置 |
| CN107577717A (zh) * | 2017-08-09 | 2018-01-12 | 阿里巴巴集团控股有限公司 | 一种保障数据一致性的处理方法、装置及服务器 |
| CN109325022A (zh) * | 2018-07-20 | 2019-02-12 | 新华三技术有限公司 | 一种数据处理方法和装置 |
| CN109710388A (zh) * | 2019-01-09 | 2019-05-03 | 腾讯科技（深圳）有限公司 | 数据读取方法、装置、电子设备以及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110196856A (zh) | 2019-09-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110196856B (zh) | 一种分布式数据读取方法及装置 | |
| CN109739935B (zh) | 数据读取方法、装置、电子设备以及存储介质 | |
| US11921746B2 (en) | Data replication method and apparatus, computer device, and storage medium | |
| US10678808B2 (en) | Eager replication of uncommitted transactions | |
| WO2021036768A1 (zh) | 数据读取方法、装置、计算机设备及存储介质 | |
| US20190012343A1 (en) | Transaction execution commitment without updating of data row transaction status | |
| CN109710388B (zh) | 数据读取方法、装置、电子设备以及存储介质 | |
| US10250693B2 (en) | Idempotence for database transactions | |
| US9779128B2 (en) | System and method for massively parallel processing database | |
| JP2015514248A (ja) | ２フェーズコミットコールの厳密な順序付けに基づいたトランザクションリカバリをサポートするためのシステムおよび方法 | |
| CN109783578B (zh) | 数据读取方法、装置、电子设备以及存储介质 | |
| EP4216061A1 (en) | Transaction processing method, system, apparatus, device, storage medium, and program product | |
| Chairunnanda et al. | ConfluxDB: Multi-master replication for partitioned snapshot isolation databases | |
| CN113391885A (zh) | 一种分布式事务处理系统 | |
| EP4276651A1 (en) | Log execution method and apparatus, and computer device and storage medium | |
| CN112148436B (zh) | 去中心化的tcc事务管理方法、装置、设备及系统 | |
| CN106648840B (zh) | 事务之间的时序确定方法和装置 | |
| CN115617908A (zh) | 一种MySQL数据同步方法、装置、数据库终端、介质及系统 | |
| CN112800060A (zh) | 数据处理方法、装置、计算机可读存储介质及电子设备 | |
| CN110532069B (zh) | 一种分布式事务提交方法及装置 | |
| CN111221909A (zh) | 一种基于日志解析的数据库修改列同步方法和装置 | |
| Padhye | Transaction and data consistency models for cloud applications | |
| US11494347B1 (en) | Efficient update-anywhere replication of queue operations on a replicated message queue | |
| CN114416201A (zh) | 一种基于分布式数据库的快照隔离实现方法 | |
| Ínigo et al. | Design and implementation of database replication protocols in the madis architecture |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |