CN110008271B - 基于单数据库的微服务事务提交方法 - Google Patents

Abstract

本发明公开了一种基于单数据库的微服务事务提交方法，包括外部api网关逐层向下调用多个微服务；sql网关为事务id分配一个事务sql缓存空间，在其中存储sql网关接收的所有sql请求。外部api网关在第一次执行请求时执行，步骤1，外部api网关计算事务id发出的sql提交数量，保存至请求类型缓存空间中；步骤2，外部api网关对sql网关发出开启事务id请求，将sql提交数量存储到事务sql缓存空间中；当sql网关接收到sql请求或开启事务id请求时，sql网关判断接收的sql数量是否达到提交数量，如达到则统一提交。在以后再次执行同样请求时，仅执行步骤2即可。本方法既能保证多微服务事务强一致性，又在性能上不需要牺牲过多。

Description

基于单数据库的微服务事务提交方法

技术领域

本发明属于保证微服务事务一致性领域，特别是涉及一种对同一数据库的微服务事务提交方法。

背景技术

随着微服务技术的快速发展，越来越多的微服务应用支撑起了大量的业务，其中有些服务需要保证事务的强一致性，比如一个电商网站的付款与积分系统，当用户进行付款操作后需要对用户的付款进行扣除操作，同时对积分进行修改，这两个操作密不可分，不允许出现一个成功而另一个失败的情况，这就构成了一个事务。

本发明涉及联系较紧密、请求较频繁的两个或多个微服务的数据库合并事务问题。这些微服务一般的特点有：

1.微服务之间联系紧密，甚至可能按比例部署在同一台服务器上。

2.微服务同一个api所需的数据库操作相似(比如，都是执行某两条sql，只是参数不同)。

3.微服务由于联系紧密，所以实现上是共用同一个数据库的，只是表不同。

4.微服务业务不能用最终一致性保证(见后续描述)

本发明所提出的解决方案，适用于满足上述条件的微服务。

一个事务一般需要满足acid条件:

原子性(a):所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。

一致性(c):事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么最后A账户一定是450元，B账户一定是350元。

隔离性(i):所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。

持久性(d):所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。

目前，市面上应用的数据库系统，比如mysql、oracle、sqlserver等都支持事务的提交，比如mysql，可以开启一个事务，在其中写入多条sql语句后提交该事务，数据库就能保证提交的多条语句满足上述的acid特性，在以前的应用系统中也确实都是使用这种方式实现事务，然而，这种实现对于多微服务系统来说却有很大的局限性。

在多微服务系统中，应用由多个微服务构成，每个微服务对外提供接口供其它服务调用，自身仅仅完成自身的操作，不再关心其它服务内部的实现，一旦出现多个服务都需要操作数据库，并且期望是一个事务的话，就很难做到acid特性的保证。

针对上述问题，很多人提出了自己的解决方案，比如:

两阶段提交:

MySQL从5.5版本开始支持2PC，又叫做XA Transactions。其中，XA是一个两阶段提交协议，该协议分为以下两个阶段：

第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.

第二阶段：事务协调器要求每个数据库提交数据。

其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。除了MySQL以外，SQL Server、Oracle等主流数据库都支持两阶段事务。分布式应用的两阶段提交与数据库支持的两阶段提交大同小异，思想都是一样的，只是可能会修改提交的主体不再是数据库中的事务协调器，并且使用了AMQP等消息机制实现通知。两阶段提交的使用方式有很多，不同的系统可能采用不同的方式实现，但是思想都是一致的。

保证最终一致性的思想是认为，分布式系统不需要保证强一致性，在大部分情况下只要保证“最终一致性”就可以满足业务需要。事实上，微服务事务确实没有必要满足强一致性，这种方案可以满足大部分的业务需求。不过，也确实存在着某些对可靠性要求很高的业务，必须满足acid特性。

上述的两种技术主要缺陷如下：

两阶段提交：两阶段提交的主要问题是：第一次分布式提交时，事务发起方需要等待所有的子事务提供方都成功提交“预处理”后，再发送一次提交请求到数据库，后面多了一步同步的提交工作，导致性能损耗非常大，并且影响可用性。本文提出的方式利用缓存与计数的方式省去了第二次提交的过程，可以一定程度上缓解性能损耗的问题。

保证最终一致性：保证最终一致性的问题是，虽然最终一致性能够适应大部分的业务需求，但仍有少部分需求要求必须实现acid特性，所以保证最终一致性不能满足所有的业务需求。本文所述的方法主要满足这部分特殊需求。

发明内容

本发明要解决的技术问题是提供一种微服务事务提交方法，在多个微服务使用的数据库是单库情况下，既能保证多微服务事务强一致性，同时在性能上不需要牺牲过多的方法。

本发明方法包括：

外部api网关接收外部调用方发送的事务请求时，分配一个id，记为事务id；

外部api网关在缓存A中为所述事务id的请求类型分配一个请求类型缓存空间，相同的请求类型具有同样的业务逻辑，调用同样的微服务；

外部api网关携带所述事务id逐层向下调用多个微服务，直至对sql网关发出sql请求，所有sql包装成一个数据库事务，对同一数据库进行请求；

sql网关在缓存B中为所述事务id分配一个事务sql缓存空间，在其中存储sql网关接收的所有sql请求；

外部api网关在所述请求类型缓存空间中查询是否存在与所述事务id相同的请求类型，如果不存在，执行如下步骤：

步骤1，外部api网关计算所述事务id对sql网关发出的所有sql请求数量之和，记为sql提交数量，保存至所述请求类型缓存空间中；

步骤2，外部api网关对sql网关发出开启所述事务id请求，将缓存A中的sql提交数量存储到缓存B中事务sql缓存空间中；

sql网关接收到sql请求或开启所述事务id请求时，sql网关将当前事务sql缓存空间中的sql请求数量与事务sql缓存空间中的sql提交数量比较，如相等则统一提交所述事务sql缓存空间中存储的所有sql请求；

如果在所述事务类型缓存空间中查到与所述事务id相同的请求类型，执行上述步骤2。

进一步地，所述方法还包括：步骤1中sql提交数量计算方法为，外部api网关逐层向下调用微服务时，每一层都返回本层及下层的sql请求数量之和。

进一步地，所述方法还包括：所述相同的请求类型的判断方法为，当请求的方法和url都相同时，请求类型相同。

进一步地，所述方法还包括：所述请求类型缓存空间为key-value形式存储，其中key为所述请求的请求类型，value为sql提交数量；事务sql缓存空间为key-value形式存储，其中key为事务id，Value中存储sql网关接收的所有sql请求以及sql提交数量。

进一步地，所述方法还包括：缓存A和缓存B位于缓存服务器中。

本发明在二阶段提交的基础上，提出了利用缓存统计一个事务的sql数量，利用sql网关通过计数触发提交，从而省去了第二阶段提交的过程。在这个微服务使用单库的情形下，对于二阶段提交来说有一定的性能优势，实现了多微服务系统的数据库的事务提交。sql网关中间件进行高效的sql聚合与提交操作，从而减轻现有技术中的多段提交对性能的影响，而且也保证了acid特性。

附图说明

图1微服务系统交互示意图。

图2sql网关装置交互示意图。

图3系统在缓存B未命中情况下的时序图。

图4缓存B命中情况下的时序图

具体实施方式

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

以下本发明通过优选实施例进行了描述，然而本发明并非局限于这里所描述的实施例，在不脱离本发明范围的情况下还包括所做出的各种改变以及变化。

本发明的思路是，在实际的web应用中，有很多请求涉及到的数据库操作步骤都是固定的，所以可以充分利用缓存机制，做到后续再遇到同样的api调用时，不需要再进行二阶段提交，而是进行计数机制计数提交。

图1，表示一个微服务系统的整体架构，其中的箭头表示数据流向，整个系统对外的表现就是：接收外部请求，执行数据业务(执行sql等)，回应外部一个请求的id，记为事务id。外部可以在后续通过请求id查看该请求的执行结果。

从图中可以看出，外部API网关的向下层调用的是服务A，服务A又会调用服务B和C，而服务A、B、C都会执行一些sql语句，这些sql语句在sql网关汇聚(利用缓存)，最终形成一个事务请求，发送给同一数据库做统一处理。

首先我们先看一下sql网关本身是如何工作的(图2)，这样有利于后面理解整个微服务系统的工作流程。

对于sql网关装置本身，如图2所示，需要做如下操作：

(1)接收请求

接收上层的请求，请求共分两种：sql语句请求和事务开启请求。

Sql语句请求：由上层的服务调用，主要结构是：事务id+sql语句；

事务开启请求：由API网关调用，主要结构是：事务id+事务sql数量。

(2)处理请求

每当收到一个请求，都需要做不同的处理，首先是对于每个事务id，都会分配一个key-value缓存(在缓存空间A中)，如图2所示，缓存空间A中，每条记录的key就是事务id，value分为两部分，第一部分是事务sql的数量，第二部分是各个sql语句。

当收到上述两种中的任何一种请求后，首先判断该事务id当前有没有缓存，如果没有，新建一个缓存条目，key为事务id(比如图中的001)，value中放入请求相关的数据，之后再接收请求时，如果已经存在缓存001，则将数据放入该条目中，同时进行本条目中的数据判断。

数据判断的过程：对于某个id的事务来说，如果缓存中存在事务的sql数量，并且目前接收到的sql数量已经达到该数量，则提交该事务，顺便更新该id的事务状态并清除缓存，否则不提交该事务。

明确了sql网关装置本身的逻辑之后，我们再来看一下系统整体的事务处理操作：

对于第一次收到某请求，缓存空间B无法命中的情况，本装置主要的执行逻辑如图3所示。

图3中，每个箭头表示数据流向，并且在箭头上有步骤来表示此数据流向的含义，每个步骤的标号表示如下信息：第一个数字表示大步骤，第一个字母表示并发操作，举例来说，“2A”、“2B”表示第二个大步骤中，并行进行A和B两种操作。

带有“-R”字样的标号，表示是某个调用的直接返回，比如有些带有双向箭头的数据，从上到下是正常的调用，比如“2A”，调用后从下到上即为直接返回数据，记为“2A-R”。

缓存空间B未命中情况下本方法分为9个步骤。

步骤1：外部调用方发送一个事务操作的请求(1)，括号中为图中表示操作的标号，说明书中以下表示均相同，外部api网关接收外部调用方发送的事务请求时，分配一个id，记为事务id，返回该事务id用于查询事务结果(1-R)；

步骤2：外部网关查询缓存空间B是否命中(2A)，此时返回结果为未命中(2A-R)；外部api网关携带事务id调用服务A进行事务操作，后续所有服务间调用都携带该事务id(2B)；sql网关记录本事务的执行情况为“执行中”(2C)；

步骤3：服务A调用sql网关准备执行3个sql(3A)，同时，服务A分别调用服务B(3B)和服务C(3C)；

步骤4：服务B调用sql网关准备执行3个sql(4A)，服务C调用sql网关准备执行2个sql(4B)；此时sql网关接收到步骤3中的任意请求时，都判断是否提交(4C)；

步骤5：服务B将本服务执行3个sql的数量信息返回服务A(5A)，服务C将本服务执行2个sql的数量信息返回服务A(5B)，此时sql网关接收到步骤4中的任意请求时，都判断是否提交(5C)；

步骤6：服务A将本服务以及本服务调用的下层所有服务的sql数量之和，即3+3+2＝8，返回到外部网关(6-R)；

步骤7：外部api网关记录本类型请求sql数量为8(7A)，外部api网关报告sql网关此事务id需要8个sql(7B)，此时sql网关接收到任意请求时，都判断是否提交(7C)；

步骤8：sql网关收到外部api网关报告和8个sql语句之后，增加一条更新本事务执行情况为“成功”的语句，提交该事务(8)。

步骤9：事务执行完毕时，清除缓存(9)。

缓存空间B命中情况下本方法分为7个步骤，见图4。

步骤1：外部调用方发送一个事务操作的请求(1)，外部api网关接收外部调用方发送的事务请求时，分配一个id，记为事务id，返回该事务id用于查询事务结果(1-R)；

步骤2：外部网关查询缓存空间B是否命中(2A)，此时结果为命中，并返回本类型请求sql数量8(2A-R)；外部api网关携带事务id调用服务A进行事务操作，后续所有服务间调用都携带该事务id(2B)；sql网关记录本事务的执行情况为“执行中”(2C)；

步骤3：服务A调用sql网关准备执行3个sql(3A)，同时，服务A分别调用服务B(3B)和服务C(3C)，外部api网关将收到的sql数量8(2A-R)通知sql网关(3D)；

步骤4：服务B调用sql网关准备执行3个sql(4A)，服务C调用sql网关准备执行2个sql(4B)；此时sql网关接收到步骤3中的任意请求时，都判断是否提交(4C)；

步骤5：sql网关接收到步骤4中的任意请求时，都判断是否提交(5)；

步骤6：sql网关收到外部api网关报告和8个sql语句之后，增加一条更新本事务执行情况为“成功”的语句，提交该事务(6)。数据库返回事务执行“成功”或“失败”结果(6-R)。

步骤7：事务执行完毕时，清除缓存(7)。

Claims (5)

1.基于单数据库的微服务事务提交方法，其特征在于，包括：

外部api网关接收外部调用方发送的事务请求时，分配一个id，记为事务id；

外部api网关在缓存A中为所述事务id的请求类型分配一个请求类型缓存空间，相同的请求类型具有同样的业务逻辑，调用同样的微服务；

外部api网关携带所述事务id逐层向下调用多个微服务，直至对sql网关发出sql请求，所有sql包装成一个数据库事务，对同一数据库进行请求；

sql网关在缓存B中为所述事务id分配一个事务sql缓存空间，在其中存储sql网关接收的所有sql请求；

外部api网关在所述请求类型缓存空间中查询是否存在与所述事务id相同的请求类型，如果不存在，执行如下步骤：

步骤1，外部api网关计算所述事务id对sql网关发出的所有sql请求数量之和，记为sql提交数量，保存至所述请求类型缓存空间中；

步骤2，外部api网关对sql网关发出开启所述事务id请求，将缓存A中的sql提交数量存储到缓存B中事务sql缓存空间中；

sql网关接收到sql请求或开启所述事务id请求时，sql网关将当前事务sql缓存空间中的sql请求数量与事务sql缓存空间中的sql提交数量比较，如相等则统一提交所述事务sql缓存空间中存储的所有sql请求；

如果在所述请求类型缓存空间中查到与所述事务id相同的请求类型，执行上述步骤2。

2.如权利要求1所述的基于单数据库的微服务事务提交方法，其特征在于，步骤1中sql提交数量计算方法为，外部api网关逐层向下调用微服务时，每一层都返回本层及下层的sql请求数量之和。

3.如权利要求1所述的基于单数据库的微服务事务提交方法，其特征在于，所述相同的请求类型的判断方法为：当请求的方法和url都相同时，请求类型相同。

4.如权利要求1所述的基于单数据库的微服务事务提交方法，其特征在于，所述请求类型缓存空间为key-value形式存储，其中key为所述请求的请求类型，value为sql提交数量；事务sql缓存空间为key-value形式存储，其中key为事务id，Value中存储sql网关接收的所有sql请求以及sql提交数量。

5.如权利要求1所述的基于单数据库的微服务事务提交方法，其特征在于，缓存A和缓存B位于缓存服务器中。

Images