CN115374133A - 数据处理方法、装置、电子设备和计算机可读存储介质 - Google Patents

数据处理方法、装置、电子设备和计算机可读存储介质 Download PDF

Info

Publication number
CN115374133A
CN115374133A CN202210977394.0A CN202210977394A CN115374133A CN 115374133 A CN115374133 A CN 115374133A CN 202210977394 A CN202210977394 A CN 202210977394A CN 115374133 A CN115374133 A CN 115374133A
Authority
CN
China
Prior art keywords
data
node
transaction
read
cache
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.)
Pending
Application number
CN202210977394.0A
Other languages
English (en)
Inventor
周星璇
康俊彬
蔡乐
李飞飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Cloud Computing Ltd
Original Assignee
Alibaba Cloud Computing Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Alibaba Cloud Computing Ltd filed Critical Alibaba Cloud Computing Ltd
Priority to CN202210977394.0A priority Critical patent/CN115374133A/zh
Publication of CN115374133A publication Critical patent/CN115374133A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2308Concurrency control
    • G06F16/2315Optimistic concurrency control
    • G06F16/2329Optimistic concurrency control using versioning
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请提出一种数据处理方法、装置、电子设备和计算机可读存储介质。该方法包括:响应于第一读事务触发针对分布式数据库中的第一节点执行第一数据读取操作,确定是否接收到来自所述第一节点的预定消息;其中,所述预定消息是在所述第一节点上的第一写事务处于预备状态的情况下发送的;在接收到来自所述第一节点的预定消息的情况下,读取所述第一节点中的表数据,并基于所述表数据更新缓存数据。本申请实施例可以在减少缓存与实际表数据之间同步的开销的情况下,保持数据库中表数据与缓存数据的强一致性。

Description

数据处理方法、装置、电子设备和计算机可读存储介质
技术领域
本申请涉及数据库领域,尤其涉及一种数据处理方法、装置、电子设备和计算机可读存储介质。
背景技术
为了提高数据库性能,通常会在数据库节点内部维护缓存,比如对表定义、索引定义、约束、分布式数据库分片路由信息等元数据进行缓存,这类数据会被高频使用同时较少被修改。当需要使用时,直接从缓存读取数据,可以避免从磁盘上扫描表数据的开销。当表数据发生修改时,对应的缓存也需要进行刷新,以避免应用程序读取到过时的数据。
在分布式数据库中,为了解决分布式环境下的时序问题,保证分布式事务的可见性在各个数据库节点上是一致的,提出基于时钟协议以及Prepare(预备)和Commit(提交)两阶段来完成事务的提交。然而,在写事务处于Prepare状态到Commit状态的这一段时间内,若读事务直接从缓存中获取数据,则可能获取到过时的数据。也就是说,分布式数据库中的表数据与缓存的强一致性受到了破坏。
发明内容
本申请实施例提供一种数据处理方法、装置、电子设备和计算机可读存储介质,以解决相关技术存在的问题,技术方案如下:
第一方面,本申请实施例提供了一种数据处理方法,包括:
响应于第一读事务触发针对第一节点执行第一数据读取操作,确定是否接收到来自第一节点的预定消息;其中,预定消息是在第一节点上的第一写事务处于预备状态的情况下发送的;
在接收到预定消息的情况下,读取第一节点中的表数据,并基于表数据更新缓存数据。
第二方面,本申请实施例提供了一种数据处理方法,包括:
在第一节点上的第一写事务处于预备状态的情况下,向第一节点连接的第一进程发送预定消息;其中,预定消息用于指示第一进程在第一读事务触发对第一节点执行第一数据读取操作的情况下,读取第一节点中的表数据并基于表数据更新第一进程的缓存数据。
第三方面,本申请实施例提供了一种数据处理装置,包括:
节点确定模块,用于响应于第一读事务触发针对第一节点执行第一数据读取操作,确定是否接收到来自第一节点的预定消息;其中,预定消息是在第一节点上的第一写事务处于预备状态的情况下发送的;
第一读取模块,用于在接收到预定消息的情况下,读取第一节点中的表数据,并基于表数据更新缓存数据。
第四方面,本申请实施例提供了一种数据处理装置,包括:
消息发送模块,用于在第一节点上的第一写事务处于预备状态的情况下,向第一节点连接的第一进程发送预定消息;其中,预定消息用于指示第一进程在第一读事务触发针对第一节点执行第一数据读取操作的情况下,读取第一节点中的表数据并基于表数据更新第一进程的缓存数据。
第五方面,本申请实施例提供一种电子设备,包括存储器、处理器及存储在存储器上的计算机程序,处理器在执行计算机程序时实现本申请任一实施例提供的方法。
第六方面,本申请实施例提供一种计算机可读存储介质,计算机可读存储介质内存储有计算机程序,计算机程序被处理器执行时实现本申请任一实施例提供的方法。
根据本申请实施例的技术方案,写事务处于预备状态时,参与该写事务的节点向节点连接的其他进程发送预定消息,来通知各个进程各自在执行数据读取操作时访问表数据而非缓存数据。读事务在读取数据时,先检查是否有预定消息,在有预定消息的情况下,读取表数据并刷新缓存数据,从而及时刷新缓存数据,保持分布式数据库中表数据与缓存的强一致性,并且尽可能减少缓存与实际表数据之间同步的开销。
上述概述仅仅是为了说明书的目的,并不意图以任何方式进行限制。除上述描述的示意性的方面、实施方式和特征之外,通过参考附图和以下的详细描述,本申请进一步的方面、实施方式和特征将会是容易明白的。
附图说明
在附图中,除非另外规定,否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解,这些附图仅描绘了根据本申请公开的一些实施方式,而不应将其视为是对本申请范围的限制。
图1为本申请实施例中分布式事务协议的示意图。
图2为本申请实施例提供的数据处理方法的一个示例性的应用场景的示意图。
图3为根据本申请一实施例的数据处理方法的流程图。
图4为根据本申请另一实施例的数据处理方法的流程图。
图5为本申请应用示例中写事务的处理流程的示意图。
图6为根据本申请一实施例的数据处理装置的结构框图。
图7为根据本申请另一实施例的数据处理装置的结构框图。
图8为根据本申请一实施例的电子设备的结构框图。
具体实施方式
在下文中,仅简单地描述了某些示例性实施例。正如本领域技术人员可认识到的那样,在不脱离本申请的精神或范围的情况下,可通过各种不同方式修改所描述的实施例。因此,附图和描述被认为本质上是示例性的而非限制性的。
为便于理解本申请实施例的技术方案,以下对本申请实施例的相关技术进行说明,以下相关技术作为可选方案与本申请实施例的技术方案可以进行任意结合,其均属于本申请实施例的保护范围。
在单机数据库中,维护表数据与对应缓存的强一致性可以有多种方式。其中,PostgreSQL会在每个数据库连接中都各自维护一份系统表的缓存,在有DDL(DataDefinition Language,数据定义语言)操作修改了系统表的情况下,事务提交时就会向共享内存中写入数据过期消息,表示系统表数据发生了变化。当其他连接执行事务时,会先查看共享内存中是否有数据过期消息,如有,则重新读取表数据,并刷新本连接的缓存,这样就能保证不会从缓存中读到过时的数据。
但在分布式数据库中,就不能用上面的方法保证不会从缓存中读到过时的数据。这里,分布式数据库是指包含多个数据存储节点的数据库,其通过在多个节点间划分用户表数据来实现计算和存储的水平可扩展能力。分布式数据库通过分布式事务来实现全局一致的ACID(Atomicity-Consistency-Isolation-Durability,原子性、一致性、隔离性、持久性),使得分布式数据库对外表现和单机关系型数据库是一致的。
下面先介绍分布式数据库的并发控制机制和分布式事务协议。
分布式数据库可以采用MVCC(Multi-version Concurrency Control,多版本事务并发控制)机制提供事务隔离,来保证事务ACID中的隔离性。通常采用分布式时钟结合单节点MVCC来提供一致性的分布式事务并发隔离机制。
MVCC机制下同一份数据会有多个不同的版本,当更新数据时,并不是修改原来的tuple(元组),而是增加一个新版本的tuple,直至所属事务提交时才变为可见;其中,tuple是指数据库表中的一行记录。而数据读取操作(可简称为读操作)可以并发读取对它可见的最新版本的数据。这样读和写之间互不影响。MVCC通过快照隔离来实现事务隔离语义,事务在开始时分配开始时间戳,在读取tuple时,读取最新对它可见的版本。当事务提交时,分配一个提交时间戳,这个提交时间戳也会存储到数据库中。这里,快照隔离(SnapshotIsolation,SI)是数据库事务处理中的一个隔离级别,保证事务的读操作将看到一个一致的数据库的版本快照。其中,版本快照也可以简称为快照,是指基于该事务的开始时间戳确定的该事务可见的数据版本。
具体地,每个事务会有一个开始时间戳和提交时间戳,当事务T1的开始时间戳大于或等于事务T2提交时间戳,T1可以看到T2的修改。也就是说,分布式数据库对每个写事务都会存储事务提交时间戳用于支持基于时间戳的可见性判断。实际应用中,分布式数据库可以在协调节点为每个事务分配开始时间戳(startTS)和提交时间戳(commitTS)。
下面结合图1所示的分布式事务协议的示意图以及具体的示例解释分布式事务协议。
如图1所示,在一个基于分布式集群的数据库中,有一个或多个协调节点(Coordinator,CN)和多个数据存储节点(DataNode,DN),图1中以一个CN和两个DN为例进行示意。CN作为接受用户请求的组件,只存储了一些元数据信息和数据路由信息,而数据实际存储在DN上。CN收到用户请求,会根据路由信息,计算得到数据存储在哪个DN上,然后向该DN请求数据,最后收集到所需数据后,返回给用户。如果是DDL操作,包括数据库中建表、修改表结构、删除表等改变数据库对象定义的SQL(Structured Query Language,结构化查询语言)操作,则会让所有的CN和DN都参与进来。
以DML(Data Manipulation Language,数据操纵语言)事务为例,图1中以事务T1为例,在T1开始的时候,会在协调节点上为它分配当前时钟(ClockCurrent)作为开始时间戳startTS,即startTS=ClockCurrent。将startTS分发到了每个数据存储节点以后,会用startTS与数据存储节点本地的时钟比较,如果startTS比节点本地的时钟大,则将节点本地的时钟更新为startTS,该步骤可以表示为ClockUpdate(startTS)。
事务T1预备(Prepare)的时候会在每个参与事务T1的数据存储节点将当前本地时钟+1,得到预备时间戳prepareTS,即prepareTS=ClockAdvance。并将prepareTS返回给协调节点。协调节点会从各个数据存储节点发送的prepareTS中选最大值作为事务T1的提交时间戳commitTS,即commitTS=max{DN1.prepareTS,DN2.prepareTS,…}。如果commitTS比协调节点的本地时钟大,则用commitTS更新协调节点的本地时钟,该步骤可以表示为ClockUpdate(commitTS)。协调节点将commitTS发给每个DN节点去提交事务,用commitTS去推动每个参与事务T1的数据存储节点的本地时钟前进。
可以看到,分布式事务协议通过包含prepare等待的两阶段提交来同步并发事务之间的因果关系,解决事件在分布式环境下无序的问题,从而保证分布式事务可见性在各个数据库节点上是一致的。通过prepared等待,分布式数据库可以保证尽管事务T1在多个数据存储节点提交的真实物理时刻不一样,但如果满足事务T2的开始时间戳(T2.startTS)大于或等于T1的提交时间戳(T1.commitTS),则T2可以一致性的在所有节点看到T1的修改,从而保证快照隔离(SI)。
下面介绍具体的可见性判断规则。假设在任意一个节点如DN1上有两个并发事务T1、T2,对于T2而言,针对T1和T2之间的时序的几种情况,T1的可见性判断规则如下:
情况1:如果T2在扫描T1的修改时,T1还未prepare,没有提交时间戳,则判断T1对T2是不可见的。
情况2:如果T2在扫描T1的修改时,T1处于prepared状态,但还没有预备时间戳prepareTS,T2需要等待T1的提交或者终止(abort)。如果T1终止,则T1对T2不可见。如果T1提交,则T1有提交时间戳commitTS,直接基于时间戳比较进行可见性判断,即如果T2的开始时间戳T2.startTS≥T1的提交时间戳T1.commitTS,则T1对T2可见。如果T2.startTS<T1的T1.commitTS,则T1对T2不可见。
情况3:如果T2在扫描T1的修改时,T1处于prepared状态,且有预备时间戳prepareTS,则对T2的开始时间戳T2.startTS与T1的预备时间戳T1.prepareTS进行比较,如果T2.startTS<T1.prepareTS,那么可以推断得到T2.startTS<T1.commitTS,因此T1对T2不可见。如果T2.startTS≥T1.prepareTS,则T2需要等待T1的提交或者终止(abort)。对等待结果的处理可以参考上述情况2。
情况4:如果T2在扫描T1修改时,T1有提交时间戳,则直接通过时间戳比较进行可见性判断。即如果T2的开始时间戳T2.startTS≥T1的提交时间戳T1.commitTS,则T1对T2可见。如果T2.startTS<T1的T1.commitTS,则T1对T2不可见。
经本申请发明人深入研究发现,采用单机数据库缓存一致性算法不能保证分布式数据库中的表数据与缓存强一致性的原因是:单机数据库在事务提交时会通过在共享内存中写入缓存过时消息来让其他连接在事务开始时去读取表数据,刷新缓存。但分布式事务通过两阶段来提交,在事务处于prepared状态时,其他事务就需要等待prepared事务提交以获得commitTS进行比较。而在commitTS生成后,完成两阶段提交时才通知其他数据库连接需要刷新缓存。在写事务处于prepared状态到真正写入commitTS提交这一段时间内,由于针对写事务的修改信息,其他读事务的可见性判断存在多种可能的情况,例如确定为可见的或者尚未能确定为不可见的,但缓存数据未进行刷新,因此,若读事务访问数据时直接从缓存获取,则这些数据可能是过时的,不应该被获取到的。这就破坏了表数据与缓存的强一致性。
相关技术中,用于维护分布式数据库中表数据与缓存的强一致性的方案往往需要牺牲一定的系统性能例如增加同步开销,或者无法切实实现表数据与缓存的强一致性。基于此,本申请实施例提供一种数据处理方法,用以在不影响数据库性能的情况下,保持数据库中表数据与缓存数据的强一致性。
为了更清楚地展示本申请实施例中提供的数据处理方法,首先介绍可用于实现该方法的应用场景。图2示出了一个示例性的应用场景的示意图。如图2所示,分布式数据库中设置多个数据存储节点,例如节点1、节点2和节点3,同时分布式数据库中可同时创建多个数据库连接。这里,数据库连接可以指用于处理用户端与数据库之间的数据交互的进程,如图2所示的第二进程、第一进程。数据库连接也可以简称为连接。具体而言,针对每个用户端或者每次用户请求,数据库的管控后端可以分配一个进程对接该用户端或者处理该用户请求,这些进程可以称为数据库连接。
根据实际用户需求,各个进程可以处理一个或多个事务。如图2所示,第二进程处理第一写事务,第一进程处理第一读事务。在本申请实施例中,写事务可以指包括但不限于数据写入操作的事务,读事务可以指包括但不限于数据读取操作的事务。如图2所示,第二进程基于第一写事务,可以向一个或多个数据存储节点例如节点1和节点2写数据,其中通过如图1所示的两阶段提交来完成事务提交。同时第一进程基于第一读事务在一个或多个数据存储节点例如节点2中读数据。也就是说,同一数据存储节点例如节点2上可以同时有多个数据库连接。可选地,每个数据库连接可以通过协调节点与数据存储节点进行交互。
同时,每个数据库连接可以维护表数据中的部分数据的缓存(以下可以称缓存数据),也就是说,每个数据库连接可以各自维护一份缓存,用于快速读取该部分数据。该部分数据可以是一些读多写少的关键数据,例如数据分片路由信息、数据库的表结构、索引、约束等元数据信息。针对该部分数据,第一进程可以直接从缓存中读取。然而,由于第二进程的第一写事务的两阶段提交,可能会导致缓存数据过时,从而破坏表数据和缓存的强一致性,或者说破坏快照读的一致性。可以理解,该一致性是指读缓存与读表数据是相同的效果。也就是说,由于写事务的两阶段提交,会导致从缓存中无法读取到与表数据一致的数据。本申请实施例主要为了解决该问题。
根据本申请实施例,在第一写事务的两阶段提交过程中,数据存储节点在合适的时间发送预定消息给该节点的其他连接例如图2所示的第一进程。其他连接在需要执行针对该节点的数据读取操作时,先检查是否接收到该预定消息,在确认接收到该预定消息的情况下,从该节点上读取表数据并基于表数据更新缓存。如此,确保每个连接上的缓存数据均可以得到及时刷新,保持表数据和缓存的强一致性。
为了能够更加详尽地了解本申请实施例的特点与技术内容,下面结合附图对本申请实施例的实现进行详细阐述,所附附图仅供参考说明之用,并非用来限定本申请实施例。图3示出根据本申请一实施例的数据处理方法的流程图。该方法可以包括:
步骤S310、响应于第一读事务触发针对第一节点执行第一数据读取操作,确定是否接收到来自第一节点的预定消息;其中,预定消息是在第一节点上的第一写事务处于预备状态的情况下发送的;
步骤S320、在接收到预定消息的情况下,读取第一节点中的表数据,并基于表数据更新缓存数据。
上述方法可以由分布式数据库的管控后端执行。示例性地,可以由管控后端的第一进程执行,该第一进程是指与第一节点连接并用于对第一读事务进行处理的数据库连接,例如图1中所示的第一进程,但不仅限于此。其中,第一节点可以是分布式数据库中的数据存储节点(DN),主要用于存储分布式数据库中的部分数据,支持分布式数据库计算和存储的水平可扩展能力。在本申请实施例中,第一节点是参与第一读事务的节点或者说第一读事务的参与节点。并且,实际应用中,第一节点也可能是第一写事务的参与节点,在第一节点是第一写事务的参与节点的情况下,若第一写事务处于预备状态,则第一节点向第一读事务的处理进程发送预定消息。
示例性地,第一进程为用于处理第一读事务的数据库连接,即第一进程为第一读事务的处理进程。其中,第一读事务可以包括至少一个数据读取操作,或者说,在执行第一读事务的过程中,会触发至少一个数据读取操作。示例性地,事务中的数据处理操作例如数据读取操作或数据写入操作,可以采用SQL语句描述,也就是说,第一进程可以通过执行至少一个SQL语句来完成第一读事务。具体地,在上述步骤S310中,第一进程可以在处理第一读事务的过程中,例如执行SQL语句的过程中,触发第一数据读取操作。这里,触发数据读取操作,可以理解为启动对数据的读取。需要说明的是,在本申请实施例中,各个读事务读取的是对自己可见的数据版本或者说快照,该数据版本是基于读事务的开始时间戳确定的。
可选地,在本申请实施例中,第一数据读取操作可以包括对特定数据的读取操作,其中,该特定数据为既可以在数据库的数据存储节点中读取,又可以在缓存中读取的数据。示例性地,该特定数据可以为被高频使用但较少修改的数据,包括例如数据分片路由信息、数据库的表结构、索引、约束等元数据信息。
根据上述步骤S310,在启动针对第一节点中的第一数据读取操作时,首先检查是否接收到来自第一节点的预定消息。示例性地,该预定消息用于第一节点向第一节点上的各个连接通知第一节点上的第一写事务进入预备状态。这里,预备状态可以指前述说明中的分布式事务两阶段提交中的prepared状态,表明第一写事务在第一节点中写入数据,但未能完全确定该数据是否对其他事务(例如第一节点连接的其他进程处理的事务)可见。此时,第一进程的缓存与第一节点中的表数据可能是一致的,也可能是不一致的。
根据上述步骤S320,第一进程在接收到该预定消息的情况下,读取第一节点中的表数据。这里,表数据指数据存储节点中存储的数据库数据,通过读取表数据,可以读取到最新的数据。需要说明的是,在本申请实施例中,第一进程读取表数据,是指快照读表数据,即读取表数据中对第一读事务可见的数据版本。具体地,是指遵循可见性判断规则读取对第一读事务可见的数据。示例性地,在读取表数据时,若扫描到其他事务的修改信息,可以采用前述说明中的可见性判断规则判断该修改信息是否可见,从而准确地读取到对第一读事务可见的信息。进一步地,根据读取的表数据更新缓存数据,可以使第一进程的缓存数据及时刷新至与第一读事务可见的数据版本一致,从而保证快照读的一致性,即读缓存数据与快照读表数据的结果是一致的。
可见,根据上述方法,写事务处于预备状态时,参与该写事务的节点向节点上的其他连接或者说节点连接的其他进程发送预定消息,来通知各个连接各自在执行数据读取操作时访问表数据而非缓存数据。读事务在读取数据时,先检查是否有预定消息,若有,则读取表数据并刷新缓存数据,从而及时刷新缓存数据,保持分布式数据库中表数据与缓存的强一致性,并且尽可能减少缓存与实际表数据之间同步的开销。
可选地,上述数据处理方法还包括:
在没有接收到预定消息的情况下,读取缓存数据。
也就是说,在没有接收到预定消息的情况下,第一进程可以直接读取缓存数据,即在缓存中读取数据,而不需要读取表数据并刷新缓存数据,如此,可以提高第一进程的数据读取效率。示例性地,该缓存数据可以包括前述说明中的特定数据,例如元数据信息。
在上述各实施例的基础上,进一步地,作为可选的实施方式,数据处理方法还可以包括:
在读取第一节点中的表数据的情况下,若确定第一节点上的第二写事务对表数据的修改信息未处于可见状态,则设置第一标记;其中,第一标记用于指示缓存数据待更新。
需要说明的是,第二写事务可以包括第一节点参与的任一个包含数据写入操作的事务。第二写事务与第一写事务可以是同一个事务,也可以是不同的事务。
如前述说明,在读取数据存储节点中的表数据的过程中,可以扫描表数据中的各信息例如各tuple,在扫描到其他事务例如上述第二写事务的修改信息时,可以基于可见性判断规则判断修改信息是否可见。一般来说,判断结果可以包括可见、不可见以及等待,其中,等待是指等待写事务提交后进行时间戳比较。在本申请实施例中,第二写事务对表数据的修改信息未处于可见状态,具体指该修改信息对第一读事务未处于可见状态,包括判断结果为不可见或等待,在这种情况下,第一进程设置第一标记。如此,第一进程在处理之后的数据读取操作时,可以确定缓存数据待更新,进而选择访问表数据并刷新缓存数据,从而保证了表数据与缓存的强一致性。这里,缓存数据待更新可以理解为缓存数据对于之后的数据读取操作而言,可能与表数据不一致,即读缓存与读表数据的结果可能不同,需要读表数据后更新缓存。
可选地,本申请实施例中的数据处理方法还可以包括确定上述修改信息是否处于可见状态的步骤。示例性地,在设置第一标记之前,数据处理方法还可以包括:
在第二写事务处于预备状态,或者第一读事务的开始时间小于第二写事务的提交时间的情况下,确定第二写事务对表数据的修改信息未处于可见状态。
具体而言,在第二写事务处于预备状态的情况下,例如前述说明中的情况2和情况3,可以确定第二写事务对表数据的修改信息不可见或需要等待第二写事务提交后进行时间戳比较。在第二写事务已有提交时间且第一读事务的开始时间小于第二写事务的提交时间的情况下,可以确定第二写事务对表数据的修改信息不可见。在这些情况下,该修改信息有可能在后续处理中对第一进程处理的读事务可见,因此,通过设置第一标记,可以使第一进程在后续处理中,及时读取可见的信息。
示例性地,上述数据处理方法还可以包括:
在触发针对第一节点执行第二数据读取操作的情况下,若检查到第一标记,则读取第一节点中的表数据,并基于表数据更新缓存数据;其中,第二数据读取操作在第一数据读取操作之后触发。
根据上述步骤,在触发第一数据读取操作之后的第二读取操作时,第一进程会检查是否存在第一标记,若存在则读取第一节点中的表数据以及时读取可见的信息,并基于表数据更新缓存数据,以保持表数据与缓存的强一致性。
可以理解,在读取第一节点中的表数据的情况下,根据前述说明,第一进程若确定第一节点上的第二写事务对表数据的修改信息未处于可见状态,则设置第一标记,以使后续处理继续读取表数据刷新缓存,直至不存在判断为未处于可见状态的信息,即已经读取到了最新版本的数据,则可以不设置第一标记。
实际应用中,针对不同的隔离级别,还可以对读取数据进行不同的处理。由于数据存储节点上的每个连接,即数据存储节点连接的每个进程是为用户端或者说用户请求分配的,因此,这里的隔离级别可以由用户选择。这里,首先说明不同的隔离级别的特点。如前述说明,完成一个事务包括执行一个或多个SQL语句,即执行多个处理操作。如果一个事务的隔离级别为可重复读取(Repeatable Read),则同一事务中不同的处理操作或者说不同的SQL语句使用同一个快照,即看到相同的数据。如果一个事务的隔离级别为读已提交(ReadCommitted),则同一事务中每个处理操作或者说每个SQL语句使用新的快照,即可以看到不同的数据。
示例性地,在隔离级别为可重复读取(Repeatable Read)的情况下,第二数据读取操作包括第一读事务之后的第二读事务触发的数据读取操作。也就是说,对于RepeatableRead隔离级别,第一进程在第一读事务之后的其他读事务例如下一个读事务触发数据读取操作时,会根据第一标记再次读取表数据并刷新缓存。而对于第一读事务中在第一数据读取操作之后的其他数据读取操作,则可以直接读取缓存数据。因为Repeatable Read隔离级别下,一直使用同一个快照,如果某个SQL语句触发的数据读取操作读取不到最新的数据,则该事务后续的SQL语句执行时也不会读到最新的数据。
示例性地,在隔离级别为读已提交(Read Committed)的情况下,第二数据读取操作包括第一读事务在第一数据读取操作之后触发的数据读取操作,或第一读事务之后的第二读事务触发的数据读取操作。也就是说,对于Read Committed隔离级别,第一进程在第一读事务中的第一数据读取操作之后的其他数据读取操作触发时,也会根据第一标记再次读取表数据并刷新缓存。若第一数据读取操作为第一读事务中的最后一个数据读取则在第一读事务之后的其他读事务例如下一个读事务触发数据读取操作时,根据第一标记再次读取表数据并刷新缓存。
上述各实施方式从读事务的角度描述了本申请实施例的技术思路。下面提供另一个实施例,从写事务的角度进行描述。具体地,图4示出了根据本申请另一实施例的数据处理方法,该方法可以包括:
步骤S410、在第一节点上的第一写事务处于预备状态的情况下,向第一节点连接的第一进程发送预定消息。
其中,预定消息用于指示第一进程在第一读事务触发针对第一节点执行第一数据读取操作的情况下,读取第一节点中的表数据并基于表数据更新第一进程的缓存数据。
示例性地,上述方法可以由第一节点执行。可见,根据上述方法,写事务处于预备状态时,参与该写事务的节点向节点上的其他连接或者说节点连接的其他进程发送预定消息,来通知各个连接各自在执行数据读取操作时访问表数据而非缓存数据。则读事务在读取数据时,可以先检查是否有预定消息,若有,则读取表数据并刷新缓存数据,从而及时刷新缓存数据,保持分布式数据库中表数据与缓存的强一致性,并且尽可能减少缓存与实际表数据之间同步的开销。
上述方法中的各信息的技术细节,可以参考前述实施例实现,在此不一一进行赘述。为了便于理解,下面提供一个具体的应用示例。
在本应用示例中,在分布式事务协议的基础上,对分布式事务提交流程和数据读取流程都进行改动。
具体地,对于写事务,可参考图5中的事务T1的处理流程,完整流程如下:
1.在T1的所有参与节点上发起事务的开始,同时协调节点也会将本地时钟作为startTS发送给所有参与节点,每个参与节点在收到startTS后会与本地时钟作比较,如果startTS大于本地时钟,则将本地时钟更新为startTS。
2.在所有参与节点上更新数据,如update表数据,然后开始两阶段提交流程。
3.每个参与节点在收到prepare消息后,先将事务T1标记为prepare状态。
4.每个参与节点生成一个缓存无效消息(即本申请实施例中的预定消息),发送给节点中的其他连接。
5.每个参与节点将本地时钟+1,作为prepareTS,然后向协调节点回复prepareTS。
6.协调节点在收到所有参与节点回复的prepareTS后,取最大值,作为commitTS,发送给各参与节点。
7.每个参与节点收到commitTS,进行提交。
8.结束。
对于读事务,会先检查是否收到缓存数据无效的消息,如果收到了,直接读取表数据,同时刷新缓存;如果没有收到缓存无效的消息(这是大部分情况下的行为),就直接去读缓存。在读取过程中,无论数据是从表中还是从缓存中获取,都要保证是快照读,即当前事务只能读取到在startTS开始前提交的tuple。
具体流程如下:
1.事务开始时,会有一个开始时间戳startTS,用于进行可见性判断,使当前事务只能读取到在startTS开始前提交的tuple。
2.当开始读取数据时,会先检查是否收到缓存无效消息,如果没有收到,则直接从缓存中读取数据;如果收到了缓存无效消息,就快照读表数据,根据读到的数据刷新缓存(因为快照读,此时是无法看到正在提交中的新版本数据)。
3.在读表数据时,会遵从分布式事务的时间戳可见性规则来判断被扫描的tuple是否对当前事务可见,并且在看到有尚不可见的tuple版本时会设置标记,在下次访问数据时,可以再次进行刷新缓存,直到这个连接读到最新版本的数据为止。具体地:
当看到tuple所属事务处于prepared状态且读取事务的startTS小于tuple所属事务的prepareTS时,或者当读取事务的startTS小于tuple所属事务的commitTS时,继续在下次读取数据时直接读取表数据。如果在扫描过程中,没有看到有处于提交中状态的tuple,就表示已经读取到了最新版本的数据。
4.在收到缓存无效消息或被标记为需要再次刷新缓存时,根据用户选择的隔离级别,还可以对读取数据进一步优化。具体地:
当用户使用Repeatable Read(可重复读取)隔离级别时,如果当前事务收到了缓存无效消息或被标记为需要再次刷新缓存,去读表数据,但没有读到最新数据,那么在当前事务中后续执行的SQL语句需要访问该数据时,可以直接使用缓存中的数据,而不需要再去查询表中的数据(因为Repeatable Read隔离级别下,一直使用同一个快照,所以如果本次读不到最新的数据,那么该事务后续的SQL执行时也不会读到最新的数据)。在事务结束的时候,通过设置标记的方式,让这个连接的下一个事务开始时再次刷新缓存,即直接读取表数据,并刷新缓存。
当用户使用Read Committed隔离级别时,每个SQL语句都会重新获取快照,如果当前事务收到了缓存无效消息或被标记为需要再次刷新缓存,去读表数据,但没有读到最新数据,那么需要在当前事务中后续执行的SQL语句中,要访问该数据时,继续先查询表数据并更新缓存,直到读取到最新的数据为止。
整个读写流程总结起来,就是分布式事务提交时,每个参与节点将事务标记为prepared状态后,就向节点上的其他连接发送消息,来通知各个连接各自在访问数据时先刷新缓存。而在读取数据时,先检查是否有缓存无效消息,如有,就进行快照读表数据,并刷新缓存,并且在快照读表数据过程中,如果没有读到最新的数据或者看到了还在提交中的数据,则根据隔离级别的不同,选择在下一个事务(Repeatable Read)或下一个SQL语句执行(Read Committed)中继续依照当前快照读表数据,并刷新缓存,直到缓存被更新为最新数据。
通过上面的读写流程,可以保证一方面,在缓存和实际表数据之间保持强一致性,且满足快照读和隔离性的要求;另一方面,如果当前快照读不能读到最新的表数据,通过多次直接读取表数据,所有连接上的缓存最终都可以得到更新。
上述示例适用于分布式数据库中,对部分读多写少的关键数据,比如数据分片路由信息、数据库的表结构、索引、约束等元数据信息,可以在保证全局数据一致性的前提下,确保了缓存和实际表数据之间的强一致性。在尽可能减少缓存与实际表数据之间同步的开销的情况下,同时也确保了数据的一致性。
与本申请实施例提供的方法的应用场景以及方法相对应地,本申请实施例还提供一种数据处理装置600。参考图6,该装置600可以包括:
节点确定模块610,用于响应于第一读事务触发针对第一节点执行第一数据读取操作,确定是否接收到来自第一节点的预定消息;其中,预定消息是在第一节点上的第一写事务处于预备状态的情况下发送的;
第一读取模块620,用于在接收到来自第一节点的预定消息的情况下,读取第一节点中的表数据,并基于表数据更新缓存数据。
可选地,该装置600还可以包括:
第二读取模块,用于在没有接收到预定消息的情况下,读取缓存数据。
可选地,该装置600还可以包括:
标记模块,用于在读取第一节点中的表数据的情况下,若确定第一节点上的第二写事务对表数据的修改信息未处于可见状态,则设置第一标记;其中,第一标记用于指示缓存数据待更新。
可选地,该装置600还可以包括:
状态确定模块,用于在第二写事务处于预备状态,或者第一读事务的开始时间小于第二写事务的提交时间的情况下,确定第二写事务对表数据的修改信息未处于可见状态。
可选地,该装置600还可以包括:
第三读取模块,用于在触发针对第一节点执行第二数据读取操作的情况下,若检查到第一标记,则读取第一节点中的表数据,并基于表数据更新缓存数据;其中,第二数据读取操作在第一数据读取操作之后触发。
可选地,在隔离级别为可重复读取的情况下,第二数据读取操作包括第一读事务之后的第二读事务触发的数据读取操作。
可选地,在隔离级别为读已提交的情况下,第二数据读取操作包括第一读事务在第一数据读取操作之后触发的数据读取操作,或第一读事务之后的第二读事务触发的数据读取操作。
本申请实施例还提供一种数据处理装置700。参考图7,该装置700可以包括:
消息发送模块710,用于在第一节点上的第一写事务处于预备状态的情况下,向第一节点连接的第一进程发送预定消息;其中,预定消息用于指示第一进程在第一读事务触发针对第一节点执行第一数据读取操作的情况下,读取第一节点中的表数据并基于表数据更新第一进程的缓存数据。
本申请实施例各装置中的各模块的功能可以参见上述方法中的对应描述,并具备相应的有益效果,在此不再赘述。
本申请实施例还提供了一种用于实现上述方法的电子设备。图8示出根据本申请实施例的电子设备的结构框图。如图8所示,该电子设备包括:存储器810和处理器820,存储器810内存储有可在处理器820上运行的计算机程序。处理器820执行该计算机程序时实现上述实施例中的数据处理方法。存储器810和处理器820的数量可以为一个或多个。
该电子设备还包括:
通信接口830,用于与外界设备进行通信,进行数据交互传输。
如果存储器810、处理器820和通信接口830独立实现,则存储器810、处理器820和通信接口830可以通过总线相互连接并完成相互间的通信。该总线可以是工业标准体系结构(Industry Standard Architecture,ISA)总线、外部设备互连(Peripheral ComponentInterconnect,PCI)总线或扩展工业标准体系结构(Extended Industry StandardArchitecture,EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示,图8中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
可选的,在具体实现上,如果存储器810、处理器820及通信接口830集成在一块芯片上,则存储器810、处理器820及通信接口830可以通过内部接口完成相互间的通信。
本申请实施例还提供一种计算机可读存储介质,其存储有计算机程序,该程序被处理器执行时实现本申请任一实施例中提供的方法。
本申请实施例还提供一种计算机程序产品,其包括计算机程序,该计算机程序在被处理器执行时实现本申请任一实施例中提供的方法。
本申请实施例还提供了一种芯片,该芯片包括,包括处理器,用于从存储器中调用并运行存储器中存储的指令,使得安装有芯片的通信设备执行本申请实施例提供的方法。
本申请实施例还提供了一种芯片,包括:输入接口、输出接口、处理器和存储器,输入接口、输出接口、处理器以及存储器之间通过内部连接通路相连,处理器用于执行存储器中的代码,当代码被执行时,处理器用于执行申请实施例提供的方法。
应理解的是,上述处理器可以是中央处理器(Central Processing Unit,CPU),还可以是其他通用处理器、数字信号处理器(Digital Signal Processing,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(FieldProgrammable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。值得说明的是,处理器可以是支持进阶精简指令集机器(Advanced RISC Machines,ARM)架构的处理器。
进一步地,可选的,上述存储器可以包括只读存储器和随机存取存储器,还可以包括非易失性随机存取存储器。该存储器可以是易失性存储器或非易失性存储器,或可包括易失性和非易失性存储器两者。其中,非易失性存储器可以包括只读存储器(Read-onlyMemory,ROM)、可编程只读存储器(Programmable ROM,PROM)、可擦除可编程只读存储器(Erasable PROM,EPROM)、电可擦除可编程只读存储器(Electrically EPROM,EEPROM)或闪存。易失性存储器可以包括随机存取存储器(Random Access Memory,RAM),其用作外部高速缓存。通过示例性但不是限制性说明,许多形式的RAM可用。例如,静态随机存取存储器(Static RAM,SRAM)、动态随机存取存储器(Dynamic Random Access Memory,DRAM)、同步动态随机存取存储器(Synchronous DRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM,DDR SDRAM)、增强型同步动态随机存取存储器(EnhancedSDRAM,ESDRAM)、同步连接动态随机存取存储器(Sync Link DRAM,SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM,DR RAM)。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时,全部或部分地产生按照本申请的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输。
在本说明书的描述中,参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且,描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外,在不相互矛盾的情况下,本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
此外,术语“第一”、“第二”仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中,“多个”的含义是两个或两个以上,除非另有明确具体的限定。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为,表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现,其中可以不按所示出或讨论的顺序,包括根据所涉及的功能按基本同时的方式或按相反的顺序,来执行功能。
在流程图中表示或在此以其他方式描述的逻辑和/或步骤,例如,可以被认为是用于实现逻辑功能的可执行指令的定序列表,可以具体实现在任何计算机可读介质中,以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用,或结合这些指令执行系统、装置或设备而使用。
应理解的是,本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中,多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成,该程序可以存储于一种计算机可读存储介质中,该程序在执行时,包括方法实施例的步骤之一或其组合。
此外,在本申请各个实施例中的各功能单元可以集成在一个处理模块中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器,磁盘或光盘等。
以上,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到其各种变化或替换,这些都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以权利要求的保护范围为准。

Claims (12)

1.一种数据处理方法,包括:
响应于第一读事务触发针对第一节点执行第一数据读取操作,确定是否接收到来自所述第一节点的预定消息;其中,所述预定消息是在所述第一节点上的第一写事务处于预备状态的情况下发送的;
在接收到所述预定消息的情况下,读取所述第一节点中的表数据,并基于所述表数据更新缓存数据。
2.根据权利要求1所述的方法,其中,所述方法还包括:
在没有接收到所述预定消息的情况下,读取所述缓存数据。
3.根据权利要求1或2所述的方法,其中,所述方法还包括:
在读取所述第一节点中的表数据的情况下,若确定所述第一节点上的第二写事务对所述表数据的修改信息未处于可见状态,则设置第一标记;其中,所述第一标记用于指示所述缓存数据待更新。
4.根据权利要求3所述的方法,其中,所述方法还包括:
在所述第二写事务处于预备状态,或者所述第一读事务的开始时间小于所述第二写事务的提交时间的情况下,确定所述第二写事务对所述表数据的修改信息未处于可见状态。
5.根据权利要求3所述的方法,其中,所述方法还包括:
在触发针对所述第一节点执行第二数据读取操作的情况下,若检查到所述第一标记,则读取所述第一节点中的表数据,并基于所述表数据更新所述缓存数据;其中,所述第二数据读取操作在所述第一数据读取操作之后触发。
6.根据权利要求5所述的方法,其中,在隔离级别为可重复读取的情况下,所述第二数据读取操作包括所述第一读事务之后的第二读事务触发的数据读取操作。
7.根据权利要求5所述的方法,其中,在隔离级别为读已提交的情况下,所述第二数据读取操作包括所述第一读事务在所述第一数据读取操作之后触发的数据读取操作,或所述第一读事务之后的第二读事务触发的数据读取操作。
8.一种数据处理方法,包括:
在第一节点上的第一写事务处于预备状态的情况下,向所述第一节点连接的第一进程发送预定消息;其中,所述预定消息用于指示所述第一进程在第一读事务触发对所述第一节点执行第一数据读取操作的情况下,读取所述第一节点中的表数据,并基于所述表数据更新所述第一进程的缓存数据。
9.一种数据处理装置,包括:
节点确定模块,用于响应于第一读事务触发针对第一节点执行第一数据读取操作,确定是否接收到来自所述第一节点的预定消息;其中,所述预定消息是在所述第一节点上的第一写事务处于预备状态的情况下发送的;
第一读取模块,用于在接收到所述预定消息的情况下,读取所述第一节点中的表数据,并基于所述表数据更新缓存数据。
10.一种数据处理装置,包括:
消息发送模块,用于在第一节点上的第一写事务处于预备状态的情况下,向所述第一节点连接的第一进程发送预定消息;其中,所述预定消息用于指示所述第一进程在第一读事务触发针对所述第一节点执行第一数据读取操作的情况下,读取所述第一节点中的表数据并基于所述表数据更新所述第一进程的缓存数据。
11.一种电子设备,包括存储器、处理器及存储在存储器上的计算机程序,所述处理器在执行所述计算机程序时实现权利要求1-8中任一项所述的方法。
12.一种计算机可读存储介质,所述计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现权利要求1-8中任一项所述的方法。
CN202210977394.0A 2022-08-15 2022-08-15 数据处理方法、装置、电子设备和计算机可读存储介质 Pending CN115374133A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210977394.0A CN115374133A (zh) 2022-08-15 2022-08-15 数据处理方法、装置、电子设备和计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210977394.0A CN115374133A (zh) 2022-08-15 2022-08-15 数据处理方法、装置、电子设备和计算机可读存储介质

Publications (1)

Publication Number Publication Date
CN115374133A true CN115374133A (zh) 2022-11-22

Family

ID=84065572

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210977394.0A Pending CN115374133A (zh) 2022-08-15 2022-08-15 数据处理方法、装置、电子设备和计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN115374133A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116737744A (zh) * 2023-08-14 2023-09-12 金篆信科有限责任公司 数据库的控制系统、方法、计算机设备及存储介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116737744A (zh) * 2023-08-14 2023-09-12 金篆信科有限责任公司 数据库的控制系统、方法、计算机设备及存储介质
CN116737744B (zh) * 2023-08-14 2023-11-24 金篆信科有限责任公司 数据库的控制系统、方法、计算机设备及存储介质

Similar Documents

Publication Publication Date Title
US10769108B2 (en) File storage system, cache appliance, and method
JP6244592B2 (ja) 列指向データベース処理方法および処理デバイス
US7809903B2 (en) Coordinating access to memory locations for hardware transactional memory transactions and software transactional memory transactions
US9442858B2 (en) Solid state drives as a persistent cache for database systems
US20150088830A1 (en) Mirroring, in memory, data from disk to improve query performance
AU2018220055B2 (en) Multi-version concurrency control (MVCC) in non-volatile memory
US20160350363A1 (en) Loading and reloading an in-memory copy of a database object without blocking concurrent updates to the database object
US9262415B2 (en) Cache efficiency in a shared disk database cluster
EP4216061A1 (en) Transaction processing method, system, apparatus, device, storage medium, and program product
CN113420052B (zh) 一种多级分布式缓存系统及方法
US8600962B2 (en) Transaction processing device, transaction processing method, and transaction processing program
CN113094430B (zh) 一种数据处理方法、装置、设备以及存储介质
US20200034472A1 (en) Asynchronous cache coherency for mvcc based database systems
CN112307119A (zh) 数据同步方法、装置、设备及存储介质
CN113495872A (zh) 分布式数据库中的事务处理方法及系统
CN113836162A (zh) 一种业务解耦并实现多级缓存的自动化更新的方法及装置
US11099998B2 (en) Method and device for optimization of data caching
CN115443457A (zh) 事务处理方法、分布式数据库系统、集群及介质
CN113010549A (zh) 基于异地多活系统的数据处理方法、相关设备及存储介质
CN115374133A (zh) 数据处理方法、装置、电子设备和计算机可读存储介质
US9317432B2 (en) Methods and systems for consistently replicating data
CN115495495A (zh) 事务处理方法、分布式数据库系统、集群及介质
US10698899B2 (en) Data processing method, data processing device, storage system, and method for controlling storage system
CN113407639B (zh) 数据处理方法、装置、系统及存储介质
CN114201551A (zh) 数据存储方法和数据存储装置

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