GRIT: Consistent Distributed Transactions across Polyglot Microservices with Multiple Databases

GRIT 基于多个数据库的聚合微服务的一致性分布式事务

GRIT: Consistent Distributed Transactions across Polyglot Microservices with Multiple Databases

摘要

在应用程序当中最受欢迎的微服务架构给我们在多重微服务的分布式事务方面带来了新的挑战。这些微服务可能使用不同语言实现，并且使用多种不同的数据库。在当前环境下，我们非常需要一致性分布式事务，用现存的技术缺非常难实现。在这篇论文中，我们提出了GRIP：一种通过巧妙地利用确定性数据库技术和乐观并发控制协议解决了这个问题的协议。乐观地执行事务，并在执行阶段捕获其读集和写集。在执行阶段，会执行冲突检测，并且做出全局提交决策。逻辑提交事务首先被持久化到log中，然后异步应用到物理机当中。GRIT可以实现一致性，高吞吐量和序列化分布式事务，适用于调用了微服务的任何用用程序。在测试中我们演示了GRIT如何轻松支持跨多个微服务和数据库的分布式事务。

这里省略了一部分不重要的，下面从原论文从第二页开始。

GRIT利用了一些确定性的思想，例如在执行之前，对基于paxos的日志中的事务进行排序。与calvin中的侦查阶段（收集阶段）类似，我们在执行乐观并发控制执行阶段的时候，会乐观的在微服务中执行事务逻辑并且保存临时写结果。我们与calvin和FAUNADB不同的是，我们使用新的确定性冲突解决算法在OCC执行阶段之后立即解决冲突，并在其持久化到提交日志之前执行快速全局交协议。显然，GRIT可以显著减少终止事务的事务延迟。这还表明，只有已经提交的事务会进入事务日志。在事务日志执行过程中（物理化，实例化or落盘？）不需要进一步的执行。此外，日志播放部分也变得很简单，仅仅是应用在OCC执行阶段已经计算好的写操作。这就是为什么我们称它为事务的实体实现。
在这个样例中，我们展示了GRIT：支持跨微服务的一致分布式事务的新系统，微服务是用各种语言实现的，使用多个不同的底层数据库。该系统是高效的、可伸缩的，并为通过微服务公开的多个数据库之间的事务提供了序列化性。我们使用一个简化的应用程序场景来说明我们提出的挑战和解决方案。

架构和设计

图1说明了使用两个数据库的GRIT的架构。数据库可以在扩展部署中进行分区，这不是我们要研究的重点。GRIT的关键部分包括：
GTM：全局事务管理器。它扩多个被DBTM管理的数据库进行全局事务的协调。GTM可以是一个也可以是多个。
GTL：全局事务日志。它表示GTM的事务请求队列。GTL之间的顺序决定了全局事务之间的相对串行性顺序。GTL是否是持久性的是可选的。
DBTM：每个数据库域的事务管理器。冲突的检查和解决，例如本地提交决策就位于这里。数据库域是这个DBTM所覆盖的用于检查冲突的数据库的范围。它可以是一个数据库、一个分片或多个分片（我们简单的使用数据库来代表数据库域）。一个数据库只能由一个DBTM。
DBTL：每个数据库上DBTM的事务提交日志。它记录与此数据库相关的逻辑提交的事务（包括单数据库事务和多数据库事务）。DBTL中的事务顺序决定数据库系统中的序列化顺序，这里反映来自GTLs的全局事务。DBTL中的事务顺序决定数据库系统中的序列化顺序，这里反映来自GTL的全局事务。它类似于传统数据库中提交事务的预写日志（WAL）。
Log Player：它将提交日志条目推送到目标数据库分片服务器以执行写操作。它的作用与日志复制相同。
DB Shard Severs：确定的数据库引擎。每个服务器都使用确定性并发控制来实现逻辑上并发提交的事务。它还需要支持多版本控制和快照读取以进行隔离。
在我们的系统中还有一些其他组件:
Microservice：微服务。为应用程序提供面向业务的服务以实现业务逻辑的构件。每个DB可以支持多个微服务，并且微服务的执行是相互独立的。
DB Service：提供DB服务器读写接口，直接访问DB服务器。在执行阶段，它还缓存每个事务的读/写集，并在提交时将它们发送到它的DBTM以解决冲突。一个系统可以有多少DB服务实例是没有限制的。

我们利用众所周知的乐观并发控制(OCC)来执行微服务和应用程序逻辑。提交时，系统在DBTMs中进行冲突解决，在GTMs中进行全局提交决策。在DBTLs中提交的事务将由底层确定性数据库具体化。分布式事务的一致性通过三个阶段得到保证：乐观执行阶段，逻辑提交阶段和物理（落盘）阶段，如图2所示。

通过将逻辑提交决策与物理具体化分离，可以提高效率。一旦事务的效果持久化到事务提交日志中，就认为事务已提交。数据库的物理物（落盘）化在提交决策循环之外。
现在我们详细描述这三个阶段：

乐观执行阶段：事务通过微服务和数据库服务来获取和更新数据库。获取和更新被每个数据库服务捕获为（看做为）(r-set, w-set)。值得注意的是，为了解决冲突，我们还需要为r-set中的每个数据项捕获版本信息(即日志序列号- LSN)。
逻辑提交阶段：在提交时，冲突解决由事务管理器(DBTMs和GTM)执行。如果存在冲突，事务将被中止。否则，将逻辑地提交并持久化到事务日志(DBTL)中。
物理落盘阶段：数据库将从提交日志(DBTL)中物化事务，并向数据库进行物理提交。

逻辑提交决策是在两个level上完成，如下所述：
DB level：在接收到提交请求时，DB服务代理将事务的请求及其本地(rset、w-set)和元信息提交给负责的DBTM。DBTM基于最近提交的事务的w-set缓存执行冲突检查。检查冲突的逻辑与传统OCC中的类似，不同之处在于DBTM不访问DB来找出冲突，而是使用一个最近更新的缓存。如果不存在冲突，则可以在本地提交。如果事务只涉及单个数据库，那么事务的w-set将被追加到DBTL日志中，并分配LSN，事务在逻辑上被提交。如果事务涉及多个数据库，DBTM将其本地提交决策发送给GTM进行事务处理，并基于GTM的响应进行操作。如果在冲突检查期间有冲突，或者GTM的全局提交决策是“ABORT”，事务将被中止。应用程序需要重试。
Global level：涉及多个数据库的事务的提交必须通过GTM进行协调。在从应用程序中接收事务的提交请求时，GTM将等待涉及的DBTMs提交决策。如果所有来自DBTMs的决策都是”COMMIT”，那么事务将会被提交。如果有任何一个DBTM报告“ABORT”，那么事务abort。GTM通过响应DBTMs提交的全局提交决策通知DBTMs。这种交互比2PC协议更简单，并且不需要在数据库中锁定。

对于物理化阶段（落盘）：我们利用确定性数据库引擎来实现这一点。在正常情况下，日志播放器将按顺序发送日志到目标数据库分片服务器，并且事务写入是按照DB级事务日志(DBTL)中的事务顺序确定执行的。在无法执行更新的异常情况下(硬件错误、软件崩溃等)，恢复必须在特定的分片服务器上执行，我们可以利用确定性恢复算法，它比传统算法简单得多。值得注意的是，只要数据库覆盖范围内的所有更新都经过同一个DBTM，那么对于最近提交的所有事务的w-sets缓存，DBTM上的冲突检查就足够了。冲突检查的目的是查看自事务读取条目以来是否有其他事务更改了该条目。事务在OCC执行阶段直接从DB服务器读取，其中包括事务中的所有提交，直到读取时已实现的最后一个日志条目。每个数据库为自己维护Last_Commit_LSN。当事务开始读时，将记住Last_Commit_LSN，被称为这个数据库上的Read_LSN。一个事务仅仅需要检查的是那些被缓存起来了w-set条目是否在它的r-set条目的Read_LSN之后。如果没有，则意味着所有读取都是新鲜的，事务可以提交。缓存的w-set条目仅在存在可能与之冲突的事务时才有用，因此，如果其LSN小于数据库中正在进行的交易的最早的Read_LSN（Oldest_Read_LSN），则可以清除该消息。

可以提供不同的读隔离级别。每个日志LSN为数据库定义一个逻辑快照。对于每个数据库，给定一个特定的LSN可以支持本地快照读取。通过GTM注册一个只读事务可以提供全局一致性快照上的强一致性读取，GTM可以从涉及的DBTMs请求LSNs，以获得跨多个数据库的一致快照。这里我们不扩展这个流程。对于读-修改-写事务，它总是读取最新提交的数据。

演示场景

我们通过一个简单的模拟应用程序来演示该系统，该应用程序涉及在服务器端的一个电子商务网站上购买物品。应用程序接收一个包含购买列表(商品item，数量quantity)的订单，并调用两个微服务：一个是ItemService，负责保存清单项目及其存货，另一个是OrderService，负责创建订单。微服务由两个gRPC服务来说明：ItemService和OrderService。以演示多语言微服务，我们使用了两种不同的语言来实现这两个服务。ItemService是用Java实现的，它可以从数据库中获取到商品信息（item）。OrderService是用Golang实现的，它可以从数据库中获取到订单信息。数据库服务是用c++实现的gRPC服务。他们实现了OCC逻辑的一部分来为分布式事务捕获每个数据库的(r-set, w-set)。它们还获取事务日志条目，并将它们交付给底层DBMS实现。
应用程序由终端中的CLI模拟，终端调用事务中的微服务，次数为项目所需的次数，然后在提交之前创建一个订单。图3显示了应用程序窗口的屏幕截图。

演示用户能够编辑示例CLI脚本，以自定义模拟的应用程序数据并从终端发出事务。另一个终端将显示GTM当前提交事务请求的信息。另外两个终端将显示DBTMs的信息，例如，事务及其来自数据库服务的(r-set, w-set)，以及每个数据库的提交状态。
为了提高并发性，我们还将演示从多个终端并行提交的模拟应用程序中随机生成的事务。我们还计划显示基于不同负载的事务延迟和吞吐量。

新颖性和贡献

有效地支持分布式事务非常困难，这就是为什么许多NoSQL数据库系统不支持分布式事务的原因，such as Amazon’s Dynamo [14], CouchDB [15], Cassandra [16], Bigtable [17] and Azure [18]。然而，减少事务支持会增加应用程序的代码复杂性和开发工作量。
我们提出了一个新的系统，以支持在可伸缩的设置中涉及多个底层数据库的跨微服务的分布式事务。它将事务抽象为(r-set, w-set)，就像在OCC事务中一样，并结合了许多来自现有技术的思想，但避免了它们的缺点。总的来说，它使用逻辑事务提交日志，并利用确定性的底层数据库引擎来提高性能和可伸缩性。为了协调数据库之间的关系，我们使用类似于2PC的机制，但在逻辑提交阶段应用，这避免了更长的持续时间。在逻辑地提交事务之后，确定性数据库将对事务进行具体化，这通常是向外扩展部署。逻辑提交日志被复制，并且可以替换基于物理日志的复制。可伸缩性和性能的关键是在执行阶段避免协调的技术，以及持续时间相对较长的事务具体化(物理提交，落盘)。协调是在承诺时间内解决冲突，时间短，速度快。类2pc协议仅用于跨数据库事务，与传统的2PC不同，在传统的2PC中，涉及的数据库通常需要在协议播放期间锁定相关数据记录，GRIT在协议期间不需要昂贵的锁定。此外，只有当一个事务真正影响多个数据库，并且单个数据库事务只需要转到它的本地数据库事务管理器时，才需要进行协调。确定性数据库服务器简化了并发控制并加快了提交物化（落盘）过程。GRIT是确定性数据库引擎的完美使用，它需要已知的(r-set, w-set)来执行确定性事务调度。
此外，GRIT能够避免过程语言的实现(如PL/SQL或SQL/PL)，这将是一项巨大的任务，而且微服务逻辑本身不需要更改。

作者总结

流程大概就是，微服务收到事务请求，调用DB Service从数据库中获取到r-set及其LSN和w-set。然后把数据相关信息发送给DBTM。如果只涉及一个数据库（数据库分片），则由DBTM进行冲突检测，没有冲突则把w-set写入到DBTL中，再由LogPlayer进行DBTL日志的分发到对应的数据库，数据库进行数据的更新。如果涉及多个数据库，DBTM则会将相关信息发送到GTM，由GTM进行冲突的检测，如果没有冲突则通知DBTM进行日志的写入，后续流程同单数据库。

写在最后

因为毕设要写相关的东西，就简单的翻译了下这篇论文。其中有很大一部分是机翻，用自己的语言稍加修饰。如果有翻译不好或看不懂的地方，你来打我啊，欢迎来讨论。

附上原文链接

https://ieeexplore.ieee.org/abstract/document/8731442