微服务和事务管理器如何处理并发问题

事务和并发是两个独立的概念,虽然事务在我们也看到并发的上下文中变得最重要,但没有并发的情况下事务可能很重要。

回答您的问题:不,事务管理器通常不关心处理并发更新引起的问题。它采用了一种非常简单(通常也是最有意义的)的方法:如果在事务开始后,它检测到状态变得不一致(因为并发更新),它只会将其作为异常引发并回滚事务。如果它能够确定事务的ACID属性的所有条件仍然有效,它将提交事务。

对于这种类型的请求,您可以通过乐观并发处理,其中数据库上有一列(时间戳)作为对版本号的引用。

每次提交更改时,它都会修改时间戳值。

事务管理器(作为JTA规范的实现)使工作在多个资源之上变得透明。它确保所有操作作为单个工作单元进行。“在多个资源之上工作”意味着应用程序可以向数据库插入数据,同时向JMS代理发送消息。事务管理器保证为这两个操作保留ACID属性。以简单的形式,当事务成功完成时,应用程序开发人员可以确保两个操作都已处理。当出现问题时,事务管理器会处理它-可能会引发异常并回滚数据更改。因此,两项操作均未处理。 对于应用程序开发人员来说,这是透明的,他们不需要关心首先更新数据库,然后更新JMS,并检查是否所有数据更改都得到了真正的处理,或者是否发生了故障。

一般来说,JTA规范的编写并没有考虑到微服务体系结构。现在,这取决于您的系统设计(!)但是,如果我认为你有两个微服务,每个都有自己的事务管理器,那么事务管理器就不能帮助你解决并发问题。事务管理器(通常)在某些同步中不工作。您不使用来自一个微服务的多个资源(事务管理器的用例是什么),而是使用来自多个微服务的一个资源。

因为只有一个资源,所以它是所有更新的同步点。这取决于它如何管理并发性。考虑到它是一个SQL数据库,那么它取决于它使用的隔离级别(ACID-I=隔离,请参阅) https://en.wikipedia.org/wiki/ACID_(computer_science) https://vladmihalcea.com/a-beginners-guide-to-database-locking-and-the-lost-update-phenomena/ ). 因为两个微服务都试图更新一条记录。避免此问题的一个解决方案是使用乐观/伪相似锁定(您可以通过如上所述的时间戳自行实现),另一个解决方案是在数据库中使用可序列化隔离级别,或者,您可以将应用程序设计为不基于第一次读取的内容读取和更新数据,而是更改具有更新原子的sql查询(或者可能有其他策略如何使用数据模型来实现所需的结果)。

总之,这取决于事务管理器的实现方式,它可以在某种程度上帮助您,但这不是它的目的。您的目标应该是检查如何在共享存储中设置隔离级别,并考虑应用程序是否需要处理应用程序级别的丢失更新现象,或者存储Cuange为您管理。