跨微服务的全局分布式事务

相关申请的交叉引用

本申请要求于2019年5月1日提交的序列号为第16/400,364号的美国申请的优先权，该美国申请要求于2019年2月12日提交的序列号为第62/804,319号的美国临时专利申请的优先权，这两个申请的每一个通过引用整体并入本文。

背景技术

技术领域

本文公开的主题总体上涉及包括用于跨微服务的一致分布式事务的系统的专用机器，包括这样的专用机器的计算机化变型和对这样的变型的改进，并且涉及这样的专用机器通过其与其他专用机器相比得到改进的技术。

微服务架构在大规模云数据平台和应用开发中使用。微服务架构为细粒度服务的重新使用和应用开发提供了灵活性。微服务可以由不同的领域团队开发以支持业务应用。它们可以用各种语言例如Java或Golang实现，并且可以访问多个底层数据库。微服务架构中的应用通常需要启用多个微服务，这些微服务访问多个数据库。当应用启用多个微服务时，应用依赖分布式事务对底层数据库执行一致性更新。

附图说明

为了容易标识对任何特定元件或动作的讨论，附图标记中的一个最高位数字或多个最高位数字指代该元件被首次引入时所在的图号。

图1是根据一些示例实施方式的可以部署本公开内容的联网环境的图形表示。

图2是示出在一个示例实施方式中作为联网系统的一部分而提供的应用的示例的框图。

图3是示出根据一个示例实施方式的用于分布式事务的架构的示例的框图。

图4是示出在一个示例实施方式中作为联网系统的一部分而提供的全局事务系统的框图。

图5是示出根据一个实施方式的数据库事务日志和日志播放器的示例的框图。

图6是示出根据一个示例实施方式的全局事务系统的示例操作的框图。

图7示出了根据一个实施方式的全局事务系统的各阶段的示例。

图8示出了示出根据一个实施方式的全局事务系统的示例操作的流程图。

图9是示出根据一个示例实施方式的全局事务系统的另一示例操作的框图。

图10示出了根据一个实施方式的全局事务系统的可扩展性的示例。

图11示出了根据一个实施方式的用于操作全局事务系统的方法的流程图。

图12示出了根据一个实施方式的用于操作全局事务系统的方法的流程图。

图13示出了根据一个实施方式的过程。

图14示出了根据一个实施方式的针对多个数据库的事务执行的示例。

图15是根据示例实施方式的计算机系统形式的机器的图形表示，在该计算机系统内可以执行指令集以使机器执行本文所讨论的方法中的任何一种或更多种方法。

具体实施方式

“部件”是指具有由功能或子例程调用、分支点、API或被提供用于对特定处理或控制功能进行分区或模块化的其他技术定义的边界的设备、物理实体或逻辑。部件可以经由它们的接口与其他部件组合以执行机器处理。部件可以是被设计用于与其他部件一起使用的封装功能硬件单元以及通常执行相关功能的特定功能的程序的一部分。部件可以构成软件部件(例如，体现在机器可读介质上的代码)或硬件部件。“硬件部件”是能够执行某些操作的有形单元，并且可以以某种物理方式来配置或布置。在各种示例实施方式中，可以通过软件(例如，应用或应用部分)将一个或更多个计算机系统(例如，独立计算机系统、客户端计算机系统或服务器计算机系统)或计算机系统的一个或更多个硬件部件(例如，处理器或处理器组)配置为进行操作以执行如本文中描述的某些操作的硬件部件。也可以机械地、电子地或以其任何合适的组合来实现硬件部件。例如，硬件部件可以包括被永久地配置成执行某些操作的专用电路系统或逻辑。硬件部件可以是专用处理器，例如现场可编程门阵列(FPGA)或专用集成电路(ASIC)。硬件部件还可以包括通过软件被临时配置成执行某些操作的可编程逻辑或电路系统。例如，硬件部件可以包括由通用处理器或其他可编程处理器执行的软件。一旦通过这样的软件被配置，硬件部件就成为被唯一地定制成执行所配置的功能的特定机器(或机器的特定部件)，而不再是通用处理器。应理解的是，机械地、在专用和永久配置的电路系统中、或在临时配置的电路系统(例如，由软件配置)中实现硬件部件的决定可以由成本和时间考虑来驱动。相应地，短语“硬件部件”(或“硬件实现的部件”)应当被理解成包含有形实体，即为被物理构造、永久配置(例如，硬连线)或临时配置(例如，编程)成以某种方式操作或者执行本文中所描述的某些操作的实体。考虑硬件部件被临时配置(例如，被编程)的实施方式，硬件部件中的每一个无需在任一时刻处均被配置或实例化。例如，在硬件部件包括通过软件配置成专用处理器的通用处理器的情况下，该通用处理器可以在不同时间处分别被配置为不同的专用处理器(例如，包括不同的硬件部件)。软件相应地配置一个或多个特定处理器以例如在一个时刻处构成特定硬件部件并且在不同的时刻处构成不同的硬件部件。硬件部件可以向其他硬件部件提供信息并且从其他硬件部件接收信息。相应地，所描述的硬件部件可以被认为通信地耦接。在同时存在多个硬件部件的情况下，可以通过在两个或更多个硬件部件之间或之中的信号传输(例如，通过适当的电路和总线)来实现通信。在其中多个硬件部件在不同时间处被配置或实例化的实施方式中，可以例如通过将信息存储在多个硬件部件访问的存储器结构中并且在该存储器结构中检索信息来实现这样的硬件部件之间的通信。例如，一个硬件部件可以执行操作，并且将该操作的输出存储在其通信地耦接到的存储器设备中。然后，另外的硬件部件可以在随后的时间处访问存储器设备，以检索和处理所存储的输出。硬件部件还可以发起与输入设备或输出设备的通信，并且可以对资源进行操作(例如，信息的收集)。本文中描述的示例方法的各种操作可以至少部分地由被临时地配置(例如，由软件)或永久地配置以执行相关操作的一个或更多个处理器来执行。无论是被临时地配置还是永久地配置，这样的处理器可以构成进行操作以执行本文中描述的一个或更多个操作或功能的处理器实现的部件。如本文中使用的，“处理器实现的部件”指使用一个或更多个处理器实现的硬件部件。类似地，本文中描述的方法可以至少部分地被处理器实现，其中，特定的一个或多个处理器是硬件的示例。例如，方法的操作中的至少一些操作可以由一个或更多个处理器或处理器实现的部件来执行。此外，一个或更多个处理器还可以进行操作以支持“云计算”环境中的相关操作的执行或操作为“软件即服务”(SaaS)。例如，操作中的至少一些操作可以由一组计算机(作为包括处理器的机器的示例)执行，其中，这些操作能够经由网络(例如，因特网)并且经由一个或更多个适当的接口(例如，API)进行访问。某些操作的执行可以分布在处理器之间，不仅驻留在单个机器内，而且跨多个机器部署。在一些示例实施方式中，处理器或处理器实现的部件可以位于单个地理位置中(例如，在家庭环境、办公室环境或服务器群内)。在其他示例实施方式中，处理器或处理器实现的部件可以跨多个地理位置分布。

“通信网络”是指网络的一个或更多个部分，该网络可以是自组织网络、内联网、外联网、虚拟专用网络(VPN)、局域网(LAN)、无线LAN(WLAN)、广域网(WAN)、无线WAN(WWAN)、城域网(MAN)、因特网、因特网的一部分、公共交换电话网(PSTN)的一部分、普通老式电话服务(POTS)网络、蜂窝电话网络、无线网络、

“机器存储介质”指的是存储可执行指令、例程和/或数据的单个或多个存储设备和/或介质(例如，集中式或分布式数据库、和/或相关联的缓存和服务器)。因此，该术语应被视为包括但不限于固态存储器以及光学和磁性介质，包括处理器内部或外部的存储器。机器存储介质、计算机存储介质和/或设备存储介质的具体示例包括：非易失性存储器，包括例如半导体存储器设备，例如可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、FPGA和闪存设备；磁盘，例如内部硬盘和可移动磁盘；磁光盘；以及CD-ROM和DVD-ROM磁盘。术语“机器存储介质”、“设备存储介质”、“计算机存储介质”意指相同的事物，并且在本公开内容中可以互换使用。术语“机器存储介质”、“计算机存储介质”和“设备存储介质”明确地排除了载波、调制数据信号和其他这样的介质，载波、调制数据信号和其他这样的介质中的至少一些被涵盖在术语“信号介质”中。

“处理器”是指根据控制信号(例如，“命令”、“操作码”、“机器码”等)操纵数据值并且产生应用于操作机器的对应输出信号的任何电路或虚拟电路(由在实际处理器上执行的逻辑模拟的物理电路)。例如，处理器可以是中央处理单元(CPU)、简化指令集计算(RISC)处理器、复杂指令集计算(CISC)处理器、图形处理单元(GPU)、数字信号处理器(DSP)、专用集成电路(ASIC)、射频集成电路(RFIC)或其任何组合。处理器还可以是具有可以同时执行指令的两个或更多个独立处理器(有时称为“核”)的多核处理器。

“载波信号”是指能够存储、编码或携载由机器执行的指令的任何无形介质，并且包括数字或模拟通信信号或其他无形介质以有助于这样的指令的通信。指令可以经由网络接口设备使用传输介质在网络上发送或接收。

“信号介质”是指能够存储、编码或携载由机器执行的指令的任何无形介质，并且包括数字或模拟通信信号或其他无形介质以有助于软件或数据的通信。术语“信号介质”应当被认为包括任何形式的调制数据信号、载波等。术语“调制数据信号”意指使其特性中的一个或更多个特性以对信号中的信息进行编码的方式来设置或改变的信号。术语“传输介质”和“信号介质”意指相同的事物并且可以在本公开内容中互换使用。

“计算机可读介质”是指机器存储介质和传输介质两者。因此，这些术语包括存储设备/介质和载波/调制数据信号两者。术语“机器可读介质”、“计算机可读介质”和“设备可读介质”意指相同的事物，并且可以在本公开内容中互换使用。

以下描述描述了示出本主题的示例实施方式的系统、方法、技术、指令序列和计算机程序产品。在以下描述中，出于说明的目的，阐述了许多具体细节以便提供对本主题的各种实施方式的理解。然而，对于本领域技术人员而言将明显的是，可以在没有这些具体细节中的一些细节或其他细节的情况下实践本主题的实施方式。示例仅代表可能的变化。除非另有明确说明，否则结构(例如，诸如模块的结构性部件)是可选的，并且可以被组合或再分，并且操作(例如，在过程、算法或其他功能中)可以按顺序变化或被组合或再分。

本申请描述了一种新的系统，该系统支持跨微服务的一致分布式事务，所述微服务以各种语言实现并使用多个底层数据库。该系统高效且可扩展，并且针对跨通过微服务公开的多个数据库的事务提供了可串行化。

传统的技术是使用两阶段提交(2PC)协议来实现分布式事务。遗憾的是，对于具有一定数量的事务冲突的应用，2PC在大规模高吞吐量系统中不能很好地工作。一个原因是锁在整个2PC处理期间被保持，这显著地增加了事务冲突和延迟。其他方法包括用于松散耦合分布式事务的持久消息队列模式。然而，这样的持久消息队列模式需要一些框架和应用逻辑来补偿失败的事务步骤，或者甚至需要业务策略来通过业务措施进行补救，从而耗费业务资金并影响用户体验。其他系统可以在单个数据库上实现分布式事务。然而，这些系统不能应用于跨多个微服务。

本申请描述了一种跨多个数据库协调针对分布式事务的事务和处理的全局事务系统。用于应用的微服务架构为跨多个微服务的一致分布式事务带来了新的挑战，这些微服务使用多个底层数据库来实现其功能。这些微服务可以用不同的语言实现，并且访问多个底层数据库。本申请描述了一种通过使用确定性技术和乐观并发控制协议(OCC)来解决该挑战的系统。在乐观执行阶段期间，在相关的数据库服务点的每个点处捕获事务的读集(read set)和写集(write set)，并且在提交时，在每个数据库级别执行冲突检查，并且通过协调所涉及的数据库来实现全局提交决定。逻辑提交的事务(写集)首先被保存在日志中，并且然后被确定性地异步应用到物理数据库。本系统能够针对任何启用微服务的应用实现一致的、高吞吐量的和可串行化的分布式事务。

在一个示例实施方式中，全局事务系统接收针对微服务的数据库服务的事务请求。全局事务系统还从微服务的数据库服务的本地事务管理器接收对本地提交请求的本地提交决定。本地提交请求对应于事务请求。全局事务系统基于本地提交决定和全局提交决定生成向本地事务管理器的物理提交请求。本地事务管理器向与事务请求相对应的数据库服务的数据库服务器提交物理提交请求。

因此，本文描述的方法中的一种或更多种方法有助于解决诸如两阶段提交的常规方法的延迟和吞吐量的技术问题。照此，本文描述的方法中的一种或更多种方法可以消除对某些工作(effort)或计算资源的需要，否则这些工作或计算资源将会涉及阻塞事务。例如，在整个2PC处理期间保持锁，这显著增加了事务冲突和延迟。结果，可以减少由(例如，在环境内)一个或更多个机器、数据库或设备使用的资源。这样的计算资源的示例包括处理器周期、网络流量、存储器使用、数据存储容量、功耗、网络带宽和冷却能力(coolingcapacity)。

图1是其中可以实现或部署本公开内容的一些示例实施方式的网络环境100的图形表示。

一个或更多个应用服务器104经由网络102向呈客户端设备110形式的联网用户设备提供服务器端功能。web客户端110(例如，浏览器)和编程式客户端108(例如“应用”)在web客户端110上托管和执行。

应用程序接口(API)服务器118和web服务器120向应用服务器104提供相应的编程式接口和web接口。特定应用服务器116托管应用122和全局事务系统138，全局事务系统138包括部件、模块和/或应用。

应用122可以向访问应用服务器104的用户提供许多功能和服务。例如，应用122可以包括使得用户能够在托管web页面上发布内容(例如，产品项目信息)的发布应用。虽然应用122在图1中被示为应用服务器104的一部分，但是应当理解，在可替选的实施方式中，应用122可以与应用服务器116分离并且不同于应用服务器116。

全局事务系统138协调来自应用122的用于访问由微服务130提供的服务的请求。例如，全局事务系统138跨微服务130的分布式数据库服务器协调来自应用122的事务请求。在一个示例实施方式中，微服务130包括实体服务132、数据库服务134和数据库分片服务器136。

此外，虽然图1所示的网络环境100采用客户端-服务器架构，但是实施方式当然不限于这样的架构，并且可以同样很好地在例如分布式或对等架构系统中得到应用。应用122还可以实现为不一定具有联网能力的独立软件程序。

web客户端110经由web服务器120支持的web接口访问应用122。类似地，编程式客户端108经由应用程序接口(API)服务器118提供的编程式接口来访问由应用122提供的各种服务和功能。在一个示例中，编程式客户端108可以例如是卖方应用(例如，由加利福尼亚州圣何塞市的eBay公司开发的eBay应用)，以使得卖方能够以离线方式在网络环境100上创作和管理列表，并且执行编程式客户端108与应用服务器104之间的批处理模式通信。

图1还示出了在第三方服务器112上执行的第三方应用114，该第三方应用114被示出为具有经由通过应用程序接口(API)服务器118提供的编程式接口对应用服务器104的编程式访问。例如，使用从应用服务器116检索的信息的第三方应用114可以支持由第三方托管的网站上的一个或更多个特征或功能。例如，第三方网站可以提供由应用服务器104的相关应用支持的一个或更多个促销功能、市场功能或支付功能。

图1示出的任何系统或机器或与图1相关联的任何系统或机器(例如，数据库、设备、服务器)可以以专用(例如，专门的或其他非通用的)计算机实现，该专用计算机已经被修改(例如，通过软件例如应用、操作系统、固件、中间件或其他程序中的一个或更多个软件模块而被配置或编程)成执行本文所描述的针对该系统或机器的功能中的一个或更多个功能。例如，下面关于图11讨论能够实现本文所描述的方法中的任一种或更多种的专用计算机系统，并且因此这样的专用计算机可以是用于执行本文所讨论的方法中的任何一种或更多种的装置。在这样的专用计算机的技术领域中，与缺少本文所讨论的结构或者无法另外执行本文所讨论的功能的其他专用计算机相比，通过本文所讨论的结构修改以执行本文所讨论的功能的专用计算机在技术上得以改进。因此，根据本文所讨论的系统和方法配置的专用机器提供了对类似专用机器的技术的改进。

此外，图1示出的系统或机器中的任何两个或更多个可以组合成单个系统或机器，并且本文中针对任何单个系统或机器描述的功能可以在多个系统或机器之间细分。另外，可以在网络环境100内实施任何数目和类型的客户端设备106。此外，网络环境100的一些部件或功能可以在网络环境100中的其他位置被组合或位于网络环境100中的其他位置。例如，可以在应用服务器116处实施客户端设备106的功能中的一些功能。

图2是示出在一个示例实施方式中作为网络环境100的一部分提供的应用122的框图。应用122可以托管在专用服务器机器或共享服务器机器(未示出)上，这些服务器机器被通信地耦接以使得能够在服务器机器之间进行通信。应用122本身通信地耦接(例如，经由合适的接口)至彼此并且耦接至各种数据源，以便允许信息在应用122之间传递或者以便允许应用122共享和访问公共数据。此外，应用122可以经由数据库服务器124访问一个或更多个数据库126。

应用服务器116可以提供多个发布、列表和价格设定机制，由此卖方可以列出销售的物品或服务(或者发布有关的信息)，买方可以表达对这样的物品或服务的兴趣或者表明购买这样的物品或服务的意愿，并且可以为与物品或服务有关的事务设定价格。为此，应用122被示出为包括至少一个发布应用202和一个或更多个订单应用204。

图3是示出根据一个示例实施方式的用于分布式事务的架构300的示例的框图。架构300包括应用122、全局事务系统138、微服务A 304和微服务B 306。全局事务系统138包括全局事务管理器302、全局事务日志324、微服务A事务管理器320和微服务B事务管理器322。微服务B306包括实体服务308、数据库服务310、数据库分片服务器312。微服务A 304包括实体服务314、数据库服务316、数据库分片服务器318。

图3示出了用于应用122的水平扩展数据库服务(例如，数据库服务316、数据库服务310)和微服务(例如，微服务A 304、微服务B 306)的架构。整个数据集被划分(例如，分片)成不重叠的分片(例如，数据库分片服务器318、数据库分片服务器312)。每个分片呈现在相同副本的副本集中，分布在数据中心的多个物理机器上，由复制协议(例如，多Paxos或Raft)或者通过播放相同的日志来支持，以实现高可用性以及读取吞吐量。

DB服务器(例如，数据库服务316、数据库服务310)包括键值存储模型。DB服务(例如，数据库服务316、数据库服务310)向客户端提供操作影响(例如，分片的分割)和分区的透明性。DB服务还提供数据对象级别的服务，例如表行或编码为值的JSON文档。实体服务(例如，实体服务314、数据库服务310)、用于应用122的微服务向应用122提供了具有从业务实体到数据对象的抽象和映射的业务实体接口。来自应用122的应用启用多个微服务，以使用微服务(例如，微服务A 304、微服务B 306)的功能来实现业务功能。微服务启用底层DB服务(例如，数据库服务316、数据库服务310)。

每次数据库访问都要通过DB服务实例之一(例如，数据库服务316、数据库服务310)。为了保证可串行化的正确性，所有的读和写都通过DB服务进行，而没有隐藏在将作为针对事务的读集的一部分的DB服务器内部的隐式读。事务可以在每个DB分片服务器内都被支持。

全局事务系统138跨来自微服务(例如，微服务A 304和微服务B 306)的多个数据库(例如，数据库分片服务器318、数据库分片服务器312)协调事务。在一个示例实施方式中，全局事务系统138包括全局事务管理器302、全局事务日志324。

全局事务管理器302(GTM)接收事务请求，并且跨多个数据库协调全局事务。在另一示例实施方式中，全局事务系统138包括多个GTM。

全局事务日志324(GTL)表示针对全局事务管理器302的事务请求队列。全局事务日志324中的顺序确定了全局事务之间的相对可串行化顺序。GTL的持久性是可选的。

全局事务系统138包括微服务A事务管理器320和微服务B事务管理器322。每个微服务事务管理器(针对每个数据库服务)执行冲突检查和解决。例如，本地提交决定是在DB事务管理器级别执行的。

实体服务314为应用提供面向业务的服务，以实现业务逻辑。每个DB可以支持多个微服务，并且每个微服务彼此独立。数据库服务316(DB服务)提供DB引擎读/写接口，并且直接访问DB服务器(例如，数据库分片服务器318)。数据库服务316还在执行阶段期间缓存每个事务的读/写结果，并且将它们发送至其本地事务管理器，以用于提交时冲突解决。数据库分片服务器318包括确定性数据库引擎。每个服务器都使用确定性并发控制协议来同时使逻辑地提交的事务具体化。

图4是示出在一个示例实施方式中作为联网系统的一部分而提供的全局事务系统的框图。全局事务系统138包括全局事务管理器302、微服务A事务管理器320、微服务B事务管理器322和全局事务日志324。微服务A事务管理器320包括数据库事务管理器402、数据库事务日志404、日志播放器406。微服务B事务管理器322包括数据库事务管理器408、数据库事务日志410和日志播放器412。

每个微服务事务管理器(例如，微服务A事务管理器320、微服务B事务管理器322)包括本地数据库事务管理器DBTM(例如，数据库事务管理器402、数据库事务管理器408)。每个数据库级别的DBTM执行冲突检查和解决(例如，本地提交决定位于此处)。

数据库事务日志(DBTL)(例如，数据库事务日志404、数据库事务日志410)在每个数据库级别记录与其相应数据库相关的逻辑地提交的事务(包括单数据库事务和多数据库事务)。DBTL中的事务顺序决定了整个数据库系统的可串行化顺序，并且此处反映了来自GTL的全局事务。

在一个示例中，对于逻辑地提交的事务，数据库事务管理器402严格基于事务提交的顺序将其事务提交数据保存到数据库事务日志404中。日志播放器406跟踪数据库事务日志404日志存储，并且将相关的W集(W-set)发送至相应的DB分片服务器，以确定性地应用于DB分片。日志播放器406向数据库事务日志404和数据库事务管理器402提供其最新物理地提交的DBTL LSN的反馈。该信息对于数据库事务管理器402的本地缓存的维护和冲突检查是有用的。

图5示出了使用确定性方法对跨分片的分布式事务使用日志存储(例如，数据库事务日志502)的架构。日志播放器504从数据库事务日志502中读取数据。每个日志存储条目包括针对要被物理地具体化到DB分片服务器(例如，DB分片服务器518、DB分片服务器522、DB分片服务器520)的提交的事务的W集。

在一个示例实施方式中，日志播放器504包括读取器506、缓冲器516和调度器514。读取器506、缓冲器516和调度器514从数据库事务日志502中读取数据，分析W集，并且基于划分方案将其分成多个W集。调度器514将它们发送到相应的DB分片服务器(例如，DB分片服务器518、DB分片服务器520、DB分片服务器522)。为了更好的性能，队列(例如，队列508、队列510、队列512)对来自多个日志条目的多个w集进行批处理。在每个分片服务器内，分片服务器按顺序应用从日志播放器504接收的W集，而不需要与其他服务器协调。针对分片服务器的相同副本之间不需要复制协议。

图6是示出根据一个示例实施方式的全局事务系统的示例操作的框图。在步骤(1)中，应用122通过从全局事务管理器302请求事务ID(TXID)来启动全局事务。在步骤(2)中，应用122启用携载TXID的(微服务A304的)实体服务314。在步骤(3)处，实体服务314启用携载TXID的数据库服务316。在步骤(4)处，数据库服务316捕获针对TXID的(读集，写集)。在步骤(5)处，应用122请求全局事务管理器302提交TXID。在步骤(6)处，数据库服务316向数据库事务管理器402发送对具有(读集，写集)的TXID的提交请求。在步骤(7)处，数据库事务管理器402对提交请求进行排序，并且检查针对TXID的冲突。在步骤(8)处，数据库事务管理器402向全局事务管理器302发送针对TXID的本地提交决定。在步骤(9)处，全局事务管理器302在收集所有DBTM决定之后，向所有DBTM发送针对TXID的全局提交决定。在步骤(10)处，数据库事务管理器402从全局事务管理器302接收提交决定，并且在数据库事务日志404中保存针对TXID的w集。数据库事务管理器402还将带有LSN的w集放入w缓存中以用于冲突检查。数据库事务管理器402回应全局事务管理器302。在步骤(11)处，全局事务管理器302向应用122发送提交成功。

事务处理的三个阶段描述如下：

乐观执行阶段：步骤1至步骤4。事务通过微服务(例如，微服务A304)和数据库服务(例如，数据库服务316)获取和更新数据库。由每个数据库服务捕获所述获取和更新作为(r集，w集)。在一个示例实施方式中，捕获针对用于冲突解决的r集中的每个数据项的版本信息(即，日志序列号-LSN)。

逻辑提交阶段：步骤5至步骤13。在提交时，提交决定由事务管理器(例如，数据库事务管理器402、全局事务管理器302)做出。如果存在冲突，则事务被中止。否则，事务被逻辑地提交并放入事务日志(步骤6至步骤11)。

物理具体化阶段：数据库(例如，数据库分片服务器318)使来自日志(数据库事务日志404)的事务具体化，并且对数据库进行物理提交(步骤12至步骤13)。

在一个示例实施方式中，逻辑提交决定在如下所述的两个级别完成：

在DB级别(例如，微服务A304)：在接收到提交请求时，DB服务代理(例如，数据库服务316)向DBTM(例如，数据库事务管理器402)提交该请求以及针对事务TXID的元信息和其本地(r集，w集)。DBTM基于其最近提交的事务的w集缓存执行冲突检查。检查冲突的逻辑类似于传统OCC中的逻辑，只是DBTM不访问DB来找出冲突，而是使用过去事务更新的缓存。如果不存在冲突，则事务请求可以在本地提交。并且如果事务仅涉及单个数据库，则事务w集将被放入分配有LSN的DBTL日志(例如，数据库事务日志404)中。然后，事务被逻辑地提交。如果事务涉及多个数据库，则DBTM(例如，数据库事务管理器402)将其针对TXID的本地提交决定发送给GTM(例如，全局事务管理器302)，并且基于来自GTM的响应进行行动。如果在冲突检查期间存在冲突，或者来自GTM的全局提交决定为中止，则事务被中止。

在全局级别：GTM(例如，全局事务管理器302)协调涉及多个数据库的事务的提交请求。GTM在接收到针对事务TXID的提交请求时，等待所涉及的DBTM的(例如，数据库事务管理器402)提交决定。如果来自DBTM的所有提交决定都是提交，则可以提交事务。如果任何DBTM报告中止，则事务被中止。GTM通过响应DBTM的提交来向DBTM通知全局提交决定。这种交互比2PC协议更简单，并且无需在数据库中锁定。对于提交具体化阶段，利用确定性数据库引擎来实现这一点。在正常情况下，事务按照DBTL(例如，数据库事务日志404)中的事务顺序被确定地执行。在无法执行更新的异常情况下(由于硬件错误或软件崩溃)，通过将日志条目重放到DB分片的快照(snapshot)，利用确定性恢复算法执行恢复。

图7示出了根据一个实施方式的全局事务系统的各阶段的示例。

分布式事务的一致性通过三个阶段来保证：(A)乐观执行阶段702，(B)逻辑提交阶段704，以及(C)物理具体化阶段706。在(A)乐观执行阶段702中，应用122向实体服务314提交事务请求以更新数据库服务316。在一个示例中，(A)乐观执行阶段702，事务通过微服务(例如，实体服务314)和数据库服务(例如，数据库服务316)获取和更新数据库，并且所述获取和更新被每个数据库服务实例(例如，数据库分片服务器318)捕获作为(r集，w集)。在另一示例中，(A)乐观执行阶段702捕获针对用于冲突解决的r集中的每个数据项的版本信息(即，日志序列号-LSN)。

在(B)逻辑提交阶段704中，全局事务管理器302在全局级别执行冲突解决和协调。数据库事务管理器402在每个数据库级别执行冲突解决和协调。一旦事务被提交，该事务首先被放到提交日志(例如，数据库事务日志404)中。

在(C)物理具体化阶段706中，日志播放器406读取数据库事务日志404，并且通过将写应用于数据库(例如，数据库分片服务器31)来将提交事务具体化。

图8示出了示出根据一个实施方式的全局事务系统的示例操作的流程图。DBTM(例如，数据库事务管理器402、数据库事务管理器408)的功能之一是检查事务提交请求之间的冲突。与传统的OCC不同，DBTM基于其本地缓存执行冲突检查以提高效率。

在框802处，从输入事务队列接收事务请求。在框804处，DBTM对事务请求执行冲突检查。在决定框806处，DBTM确定事务请求是否使用OCC。响应于决定框806的OCC测试失败，在框808处，DBTM中止事务请求。然后，在决定框810处，DBTM确定事务请求是否是本地事务。对于非本地事务请求，在框812处，DBTM向协调器(例如，(全局事务管理器302)提供响应。对于本地事务请求或提交全局事务请求，DBTM向本地缓存生成w集(例如，事务w缓存816)。在冲突检查之后，DBTM经由块818向DB存储发送提交请求以进行物理提交。

以下示出了可以用于描述图8的算法的符号：

DB：{(key,value,lsn)}

Input Queue：[Tranx]

DBTL：[]TranxState：ID->(State,Commit_LSN)

State：In_Flight,Logically_Committed,Physically_Committed,AbortedCommitState：Logically_Committed,Physically_Committed

InFlight＝{ID|TranxState(ID)＝In_Flight}

LogicallyCommitted＝{ID|TranxState(ID)＝Logically_Committed}

PhysicallyCommitted＝{ID|TranxState(ID)＝Physically_Committed}

Tranx:(ID,R-Set,W-Set,Read_LSN,Commit_LSN)，其中，Commit_LSN只有在事务提交后才有意义。

R-Set：{(key,value,lsn)}W-Set：{(key,value,lsn)}

Tranx-W Cache：针对属于LogicallyCommitted的所有事务，U。

对于冲突检查，仅使用key和lsn，因此值不必保存在针对r集的事务数据中，并且不必保存在针对w集的Tranx-W缓存中。

以下示出了用于ConflictChecking(Tranx)的算法的示例：

Input:Tranx(ID,R-Set,W-Set,Read_LSN)

Output:Commit decision(COMMIT/ABORT)

Algorithm:

For each entry(key,_,lsn)in R-Set do e1(key1,_,lsn1)＝find_in_cache(key)；If not found then continue；else if lsn1>lsn then return ABORT；

return COMMIT；

End；

对于输入事务队列，该算法的描述是顺序的，因为它假设在那些已提交的请求之外没有挂起的提交请求并且其W集已经在Tranx-W缓存中。当DBTM需要与全局事务管理器一起工作时，这会忽略性能。在冲突检查与成功写入提交日志之间，可能存在其w集不在缓存中的挂起事务。从逻辑上讲，这些事务可以在队列中并且包括在这些w集中以用于检查。

对于全局事务，由于等待全局提交决定，DBTM会阻止输入队列后面的提交请求。对以上算法的增强之一是具有锁管理器以处理对挂起事务的检查。没有冲突的事务可以继续提交，而有冲突的事务需要在冲突事务后面等待。

以下示出了用于缓存清除逻辑的另外的符号：

Last_Commit_LSN：对于lsn<＝Last_Commit_LSN，LOG(lsn)包括状态全部为Physically_Committed的事务

Last_Commit_LSN＝max{Commit_LSN|对于LSN

Read_LSN＝Tranx开头(或首次读取)的Last_Commit_LSN。

Oldest_Read_LSN：存在事务ID，其TranxState(ID)＝In_Flight，并且其Read_LSN>＝Oldest_Read_LSN(＝min{Read_LSN(ID)|ID in InFlight})

Tranx-W缓存清除：缓存的w集条目仅在存在将与它冲突的可能的事务时才有用。冲突检查的目的是查看自事务读取条目以来是否有任何其他事务更改了条目。在OCC执行阶段中，事务直接从DB服务器读取，这包括从事务直到Last_Commit_LSN(可能还有更多)的所有提交。事务仅需要检查在其Read_LSN(例如，使用Oldest_Read_LSN)之后缓存的那些w集条目。一旦Oldest_Read_LSN移动，就可以移除LSN

图9是示出根据一个示例实施方式的全局事务系统的另一示例操作的框图。事务可以涉及跨多个DB的数据。每个数据库服务由相应的本地DBTM(例如，数据库事务管理器902、数据库事务管理器904、数据库事务管理器906)覆盖。全局事务管理器302在事务提交阶段期间涉及的多个DBTM之间进行协调。例如，在步骤(1)中，全局事务管理器302向每个本地数据库事务管理器提交提交请求。在步骤(2)中，每个本地数据库事务管理器基于使用本地缓存的本地冲突检查来提供响应(例如，本地提交响应)。在步骤(3)中，全局事务管理器302基于来自所有本地数据库事务管理器的本地提交响应来提供全局提交决定。

如果参与者在处理期间花费时间获取资源并执行真正的提交，则传统的2PC就不能很好地执行。此处，冲突检查和提交处理持续时间短，因为提交处理分为逻辑提交和物理提交。该协调处理仅需要通过逻辑提交。

以下示出了示出图9的操作的示例算法：

Algorithm:commit_coordinate

Input:tranx(ID,{DBTMi})

Output:glocal commit decision(commit/abort)Algorithm:

commit＝true；

For dbtm in{DBTMi}do

commit＝commit&&

(dbtm.ConflictChecking(tranx)＝＝COMMIT)；

For dbtm in{DBTMi}do

dbtm.send(tranx,commit？COMMIT:ABORT)；

Return commit；

End；

在另一示例实施方式中，可以通过在GTM侧等待DBTM的本地提交决定来减少请求消息。这将提交协调减少到一次往返。2PC的另一问题是处理故障。超时可以用于检测故障以避免阻塞流。

图10示出了根据一个实施方式的全局事务系统的可扩展性的示例。简写符号如下：CC代表提交协调，它是GTM实例；CD代表提交决定，它是DBTM/DBTL实例对；以及CM是提交具体化，它是日志播放器和相应的DB分片服务器。图10中的图表示出了可能的部署模式：

(A)具有在三个CD之间协调的一个CC。

(B)具有协调三个CD的两个CC，每个CC在两个CD之间协调。一个(中间)CD从两个CC接受提交请求。

(C)向(B)增加一个(中间)CC，其处理涉及三个DB的事务，每个DB由一个CD覆盖。

(D)将(A)中的顶部CC的流量分成两个CC，以支持更多的流量。或者它是利用两个CC的用于跨三个DB的事务的部署。

图11是示出根据示例实施方式的用于跨利用多个数据库的微服务的一致分布式事务的方法1100的流程图。方法1100中的操作可以由全局事务系统138使用上面关于图4描述的部件(例如，模块、引擎)来执行。因此，参照全局事务系统138通过示例的方式来描述方法1100。然而，应当理解的是，方法1100的至少一些操作可以被部署在各种其他硬件配置上或者由驻留在其他地方的类似部件执行。例如，一些操作可以在第三方服务器112处执行。

在框1102处，全局事务系统138、全局事务管理器302接收事务请求(例如，来自应用122)。在框1104处，全局事务管理器302针对事务请求生成事务id。在框1106处，全局事务管理器302生成向第一本地事务管理器(例如，微服务A事务管理器320)的本地提交请求。在框1108处，全局事务管理器302生成向第二本地事务管理器(例如，微服务B事务管理器322)的本地提交请求。在框1110处，全局事务管理器302从第一本地事务管理器接收第一冲突检查确认。在框1112处，全局事务管理器302从第二本地事务管理器接收第二冲突检查确认。一旦全局事务管理器302基于第一冲突检查和第二冲突检查确定不存在冲突，则在框1114处，全局事务管理器302生成向第一本地事务管理器的物理提交请求。在框1116处，全局事务管理器302生成向第二本地事务管理器的物理提交请求。

图12是示出根据示例实施方式的用于跨利用多个数据库的微服务的一致分布式事务的过程1200的流程图。过程1200中的操作可以由全局事务系统138使用上面参照图4描述的部件(例如，模块、引擎)来执行。因此，参照全局事务系统138通过示例的方式来描述过程1200。然而，应当理解的是，过程1200的至少一些操作可以被部署在各种其他硬件配置上或者由驻留在其他地方的类似部件执行。例如，一些操作可以在第三方服务器112处执行。

在框1202中，过程1200接收事务请求。在框1204中，过程1200响应于接收到事务请求，生成向与事务请求相关联的微服务的数据库相对应的本地事务管理器的本地提交请求。在框1206中，过程1200基于来自本地事务管理器的本地提交请求来确认无冲突。在框1208中，过程1200响应于无冲突，生成向本地事务管理器的物理提交请求，其中，本地事务管理器被配置成向与事务请求相对应的数据库服务的数据库服务器提交物理提交请求。

图13是示出根据示例实施方式的用于跨利用多个数据库的微服务操作全局事务管理器协调的过程1300的流程图。可以由全局事务系统138使用上面参照图4描述的部件(例如，模块、引擎)来执行过程1300中的操作。因此，参照全局事务系统138通过示例的方式来描述过程1300。然而，应当理解的是，过程1300的至少一些操作可以被部署在各种其他硬件配置上或者由驻留在其他地方的类似部件执行。例如，一些操作可以在第三方服务器112处执行。

在框1302中，过程1300接收针对微服务的数据库服务的事务请求。在框1304中，过程1300从微服务的数据库服务的本地事务管理器接收本地提交请求的本地提交决定，该本地提交请求对应于该事务请求。在框1306中，过程1300基于本地提交决定和全局提交决定生成向本地事务管理器的物理提交请求，本地事务管理器被配置成向与事务请求相对应的数据库服务的数据库服务器提交物理提交请求。

图14示出了根据一个实施方式的针对多个数据库的事务执行的示例。该图示出了一个跨DB事务的事务执行处理的示例。我们忽略了单个DB事务执行细节的细节，因为我们已经在前面的图中描述过了。T1和T2是更新DB1和DB2两者中的记录的全局分布式事务(跨DB事务)。T0是仅对DB1的本地事务，并且T3是仅对DB2的本地事务。仅跨DB事务需要通过GTM(全局事务管理器)，本地事务仅需要通过其本地DB_TM，因此在该示例中，T1和T2被发送至GTM，并且在OCC执行阶段后被推入GTM的事务输入队列以进行排序(注意，OCC执行阶段在每个DB_TM中执行)，T0被发送至DB1_TM并被推入到DB1_TM的事务输入队列中，T3被发送至DB2_TM并被推入到DB2_TM的事务输入队列中。

执行处理描述如下：

(1)GTM将定期按顺序将分解的事务从其事务输入队列发送至涉及的DB。在该示例中，GTM将T1 T2发送至DB1_TM和DB2_TM，DB1_TM和DB2_TM将把T1 T2放到自己的事务输入队列中。

(2)DB1_TM和DB2_TM将在T1/T2的本地读/写集上进行OCC验证和冲突解决。

(3)DB1_TM和DB2_TM将向GTM发送它们自己的提交/中止决定，在该示例中，在DB1侧，可以提交T1，并且将中止T2；在DB2侧，T1和T2两者都可以被提交。

(4)当GTM接收到来自所涉及的DB_TM的所有决定时，它可以对跨DB事务做出最终决定。在该示例中，可以提交T1，因为DB1和DB2两者都同意提交，但是T2将被中止，因为DB1将中止事务。GTM将通过将提交的事务放到提交事务日志中来保存它们。然后GTM将决定发送给所有涉及的DB_TM。

(5)当DB_TM接收到对跨DB事务的最终决定时，DB_TM可以通过将事务放到自己的提交事务日志中来提交事务。GTM和所有DB_TM中的提交事务日志确定了全局可串行化顺序。该示例中的事务可串行化顺序是T0------>T1------>T3。

图15是机器1500的图形表示，在该机器1500中可以执行使机器1500执行本文中所讨论的任何一种方法或更多种方法的指令1504(例如，软件、程序、应用、小程序、app或其他可执行代码)。例如，指令1504可以使机器1500执行本文中所描述的任何一种方法或更多种方法。指令1504将通用的未编程的机器1500转换成被编程为以所描述的方式执行所描述和所示出的功能的特定机器1500。机器1500可以作为独立设备操作，或者可以耦接(例如，联网)至其他机器。在联网部署中，机器1500可以以服务器-客户端网络环境中的服务器机器或客户端机器的身份进行操作，或者作为对等(或分布式)网络环境中的对等机器进行操作。机器1500可以包括但不限于服务器计算机、客户端计算机、个人计算机(PC)、平板计算机、膝上型计算机、上网本、机顶盒(STB)、PDA、娱乐媒体系统、蜂窝电话、智能电话、移动设备、可穿戴设备(例如，智能手表)、智能家居设备(例如，智能家用电器)、其他智能设备、web设备、网络路由器、网络交换机、网络桥接器或能够顺序地或以其他方式执行指定机器1500要采取的动作的指令1504的任何机器。此外，虽然仅示出了单个机器1500，但是术语“机器”还应被认为包括单独地或联合执行指令1504以执行本文中讨论的方法中的任何一种或更多种方法的机器的集合。

机器1500可以包括处理器1506、存储器1508和I/O部件1542，处理器1506、存储器1508和I/O部件1542可以被配置成经由总线1544彼此进行通信。在示例实施方式中，处理器1506(例如，中央处理单元(CPU)、简化指令集计算(RISC)处理器、复杂指令集计算(CISC)处理器、图形处理单元(GPU)、数字信号处理器(DSP)、ASIC、射频集成电路(RFIC)、另一处理器或其任何合适的组合)可以包括例如执行指令1504的处理器1502和处理器1510。术语“处理器”旨在包括多核处理器，该多核处理器可以包括可以同时执行指令的两个或更多个独立处理器(有时称为“核”)。尽管图15示出了多个处理器1506，但是机器1500可以包括具有单个核的单个处理器、具有多个核的单个处理器(例如，多核处理器)、具有单个核的多个处理器、具有多个核的多个处理器、或者其任意组合。

存储器1508包括主存储器1512、静态存储器1514以及存储单元1516，其均经由总线1544而可由处理器1506访问。主存储器1508、静态存储器1514和存储单元1516存储实现本文描述的方法或功能中的任一种或更多种的指令1504。在由机器1500执行指令1504期间，指令1504还可以全部地或部分地驻留在主存储器1512内、在静态存储器1514内、在机器可读介质1518内、在存储单元1516内、在处理器1506中的至少一个内(例如，在处理器的高速缓冲存储器内)或者在其任何合适的组合内。

I/O部件1542可以包括用于接收输入、提供输出、产生输出、发送信息、交换信息、捕获测量等的各种部件。特定机器中包括的特定I/O部件1542将取决于机器的类型。例如，诸如移动电话的便携式机器可以包括触摸输入设备或其他这样的输入机构，而无终端服务器机器将可能不包括这样的触摸输入设备。将理解的是，I/O部件1542可以包括图15中未示出的许多其他部件。在各种示例实施方式中，I/O部件1542可以包括输出部件1528和输入部件1530。输出部件1528可以包括视觉部件(例如，诸如等离子显示面板(PDP)、发光二极管(LED)显示器、液晶显示器(LCD)、投影仪或阴极射线管(CRT)的显示器)、声学部件(例如，扬声器)、触觉部件(例如，振动马达、阻力机构)、其他信号发生器等。输入部件1530可以包括字母数字输入部件(例如，键盘、被配置成接收字母数字输入的触摸屏、光学键盘或其他字母数字输入部件)、基于指向的输入部件(例如，鼠标、触摸板、轨迹球、操纵杆、运动传感器或另一指向仪器)、触觉输入部件(例如，物理按钮、提供触摸或触摸手势的位置和/或力的触摸屏或其他触觉输入部件)、音频输入部件(例如，麦克风)等。

在其他示例实施方式中，I/O部件1542可以包括：生物计量部件1532、运动部件1534、环境部件1536、或定位部件1538，以及各种各样的其他部件。例如，生物计量部件1532包括用于检测表达(例如，手表达、面部表达、声音表达、身体姿势或眼睛跟踪)、测量生物信号(例如，血压、心率、体温、出汗或脑电波)、识别人(例如，语音识别、视网膜识别、面部识别、指纹识别或基于脑电图的识别)等的部件。运动部件1534包括加速度传感器部件(例如，加速计)、重力传感器部件、旋转传感器部件(例如，陀螺仪)等。环境部件1536包括例如照明传感器部件(例如，光度计)、温度传感器部件(例如，检测环境温度的一个或更多个温度计)、湿度传感器部件、压力传感器部件(例如，气压计)、声学传感器部件(例如，检测背景噪声的一个或更多个麦克风)、接近度传感器部件(例如，检测附近对象的红外传感器)、气体传感器(例如，为了安全而检测危险气体的浓度或者测量大气中的污染物的气体检测传感器)、或者可以提供与周围物理环境对应的指示、测量或信号的其他部件。定位部件1538包括位置传感器部件(例如，GPS接收器部件)、海拔传感器部件(例如，检测可以得到海拔的气压的高度计或气压计)、取向传感器部件(例如，磁力计)等。

可以使用各种技术来实现通信。I/O部件1542还包括通信部件1540，该通信部件1540能够进行操作以分别经由耦接(coupling)1524和耦接1526将机器1500耦接至网络1520或设备1522。例如，通信部件1540可以包括与网络1520对接的网络接口部件或另一合适的设备。在另外的示例中，通信部件1540可以包括有线通信部件、无线通信部件、蜂窝通信部件、近场通信(NFC)部件、

此外，通信部件1540可以检测标识符或包括可操作以检测标识符的部件。例如，通信部件1540可以包括射频识别(RFID)标签读取器部件、NFC智能标签检测部件、光学读取器部件(例如，用于检测下述项的光学传感器：一维条形码，例如通用产品代码(UPC)条形码；多维条形码，例如快速响应(QR)代码、Aztec代码、数据矩阵、数据图示符(Dataglyph)、麦克斯码(MaxiCode)、PDF417、超代码、UCC RSS-2D条形码和其他光学代码)、或者声学检测部件(例如，用于识别标记的音频信号的麦克风)。另外，可以经由通信部件1540得到各种信息，例如经由互联网协议(IP)地理定位的位置、经由

各种存储器(例如，存储器1508、主存储器1512、静态存储器1514和/或处理器1506的存储器)和/或存储单元1516可以存储由本文描述的任何一个或更多个方法或功能实现或使用的一组或更多组指令和数据结构(例如，软件)。这些指令(例如，指令1504)在由处理器1506执行时使得各种操作实现所公开的实施方式。

可以经由网络接口设备(例如，通信部件1540中包括的网络接口部件)，使用传输介质并且使用许多公知的传输协议中的任意一种传输协议(例如，超文本传输协议(HTTP))，通过网络1520来传输或接收指令1504。类似地，可以使用传输介质经由耦接1526(例如，对等耦接)将指令1504发送或接收至设备1522。

本申请描述了一种在可扩展设置中支持跨涉及多个底层数据库的微服务的分布式事务的系统。该系统采用逻辑事务提交日志，并且利用确定性底层数据库引擎以提高性能和可扩展性。对于跨数据库的协调，原则上使用类似于2PC的机制，但仅适用于逻辑提交级别。在事务被逻辑提交后，它们被通常是向外扩展部署的确定性数据库具体化。逻辑提交日志被复制，并且可以取代基于物理日志的复制。

可扩展性和性能的关键是避免持续时间相对较长的执行阶段以及事务具体化(物理提交)期间的协调的技术。协调在针对冲突解决的持续时间短且快速的提交时间处。类似2PC的协议仅用于跨数据库事务，并且不同于传统的2PC，在传统的2PC中，所涉及的数据库通常需要在协议播出期间锁定相关的数据记录，本系统在协议期间不需要锁定。另外，仅当事务真正影响多个数据库时，才需要这个协议，并且单数据库事务仅需要转到它的本地数据库事务管理器。确定性DB简化了并发控制并且加快了提交处理。本系统适用于使用需要已知的(r集，w集)来执行确定性事务调度的确定性数据库引擎。

尽管已经参照具体示例实施方式描述了实施方式，但是将明显的是，在不偏离本公开内容的更宽范围的情况下，可以对这些实施方式进行各种修改和变化。因此，说明书和附图要被视为说明性意义而不是限制性意义。形成本文的一部分的附图以图示的方式并且非限制性地示出其中可以对本主题进行实践的具体实施方式。足够详细地描述了所示的实施方式，以使得本领域技术人员能够实践本文中公开的教导。可以利用并且由此得到其他实施方式，使得可以在不偏离本公开内容的范围的情况下做出结构性和逻辑性替换和变化。因此，该详细描述不以限制性意义而被采用，并且各种实施方式的范围仅通过所附权利要求与称为这样的权利要求的等同方案的全部范围一起来限定。

本发明主题的这样的实施方式在本文中可以仅出于便利而被单独地和/或共同地称为术语"发明"，而不意在在实际上公开了多于一个发明或发明概念的情况下将本申请的范围主动地限制为任何单个发明或发明概念。因此，虽然已经在本文中示出和描述了具体实施方式，但是应当意识到的是，被计算以实现相同目的的任何布置可以针对所示出的具体实施方式而被替换。本公开内容旨在涵盖各种实施方式的任何以及全部调整或变型。当对上述描述进行回顾时，上述实施方式以及本文中未具体描述的其他实施方式的组合对于本领域技术人员而言将是明显的。

提供了本公开内容的摘要以使得读者能够快速地确定本技术公开内容的本质。应当理解提交摘要不用于解释或限制权利要求的范围或含义。另外，在前述具体实施方式中，可以看到的是，出于使本公开内容精简的目的，各种特征在单个实施方式中被组合在一起。本公开内容的方法不被解释为反映如下意图：所要求保护的实施方式需要比在每个权利要求中明确列举的特征更多的特征。相反，如所附权利要求所反映的，发明主题在于少于单个公开的实施方式中的所有特征。因此，所附权利要求由此被并入具体实施方式中，其中每个权利要求自身独立地作为单独的实施方式。

示例

示例1是一种计算机实现的方法。该方法包括：接收针对微服务的多个数据库服务的事务请求；从微服务的所述多个数据库服务的本地事务管理器接收对本地提交请求的多个本地提交决定，该本地提交请求对应于针对每个数据库服务的事务请求；以及基于本地提交决定和全局提交决定生成向本地事务管理器中的每一个的物理提交请求，本地事务管理器中的每一个被配置成向与事务请求相对应的数据库服务的每个数据库服务器提交该物理提交请求。

在示例2中，示例1的主题可以可选地包括：从应用接收事务请求；针对事务请求生成事务标识符，该事务标识符标识与事务请求相关联的微服务的数据库服务；以及向应用提供事务标识符，该应用被配置成使用事务标识符发起对微服务的数据库服务的本地提交请求。

在示例3中，示例1的主题可以可选地包括：其中，事务请求包括对数据库服务器的读请求和写请求，其中，对事务请求的接收在乐观执行阶段期间被捕获。

在示例4中，示例1的主题可以可选地包括：基于本地事务管理器的本地缓存和事务标识符来确认对于事务请求无冲突，本地提交决定指示无冲突。

在示例5中，示例4的主题可以可选地包括：其中，本地缓存存储在数据库服务的数据库服务器上执行的提交的事务的日志。

在示例6中，示例1的主题可以可选地包括：从应用接收标识事务标识符的全局提交请求；从数据库服务接收标识事务标识符的本地提交请求；访问本地事务管理器的本地缓存，该本地缓存指示提交的事务；以及基于本地缓存和事务标识符来确认对于本地提交请求无冲突，本地提交决定指示无冲突。

在示例7中，示例1的主题可以可选地包括：从与事务请求相关联的多个本地事务管理器接收多个本地提交决定；基于所述多个本地提交决定生成全局提交决定；以及将全局提交决定传送至所述多个本地事务管理器，每个本地事务管理器被配置成基于全局提交决定向相应数据库服务的相应数据库服务器提交物理提交请求。

在示例8中，示例1的主题可以可选地包括：保存针对相应的本地事务管理器的提交的事务的日志；以及将来自日志的提交的事务应用到对应于本地事务管理器的数据库服务器。

在示例9中，示例1的主题可以可选地包括：在不访问数据库服务器的情况下基于本地提交请求与本地事务管理器的本地缓存的比较来执行冲突检查，本地缓存指示对数据库服务器的最近事务更新，其中，本地事务管理器被配置成在不锁定挂起事务请求的数据库服务器的情况下向数据库服务器提交物理提交请求，其中，全局提交决定基于来自针对事务请求的数据库服务的多个本地事务管理器的多个本地提交决定。

在示例10中，示例1的主题可以可选地包括：从应用接收事务请求；针对事务请求生成事务标识符，事务标识符标识与事务请求相关联的第一微服务的第一数据库服务和与事务请求相关联的第二微服务的第二数据库服务；在对应于第一数据库服务的第一本地事务管理器处，从第一数据库服务接收第一本地提交请求，第一本地提交请求包括事务标识符；在对应于第二数据库服务的第二本地事务管理器处，从第二数据库服务接收第二本地提交请求，第二本地提交请求包括事务标识符；对于来自第一本地事务管理器的第一本地提交请求确认第一无冲突；对于来自第二本地事务管理器的第二本地提交请求确认第二无冲突；以及基于第一无冲突，从第一本地事务管理器接收第一本地提交决定；基于第二无冲突，从第二本地事务管理器接收第二本地提交决定；响应于接收到第一本地提交决定和第二本地提交决定，向第一本地事务管理器和第二本地事务管理器提供全局提交决定；响应于全局提交决定，生成对第一数据库服务的第一数据库服务器的第一物理提交请求；以及响应于全局提交决定，生成对第二数据库服务的第二数据库服务器的第二物理提交请求。