架构设计事务篇之分布式事务

最新推荐文章于 2024-11-03 19:00:05 发布

花花编程

最新推荐文章于 2024-11-03 19:00:05 发布

阅读量68

点赞数

文章标签：分布式数据库 java mysql sql

本文链接：https://blog.csdn.net/chnzefdsfd/article/details/130429951

版权

概述

事务是一组读写操作，这些操作被当作一个独立的工作单元被执行，操作的执行结果要么全部成功，要么全部失败，不允许部分成功、部分失败的情况出现。
事务可以分为本地事物和分布式事物，本地事务的数据操作是在单个数据库上执行的，而分布式事务是在多个数据库上执行的，分布式事物由两个或以上的本地事物构成，它也被称之为全局事物。
无论是本地事物，还是分布式事物它们的作用都是为了保障数据的一致性。

实列

avatar

在采用微服务架构的应用程序中，需要使用分布式事务技术的典型实列是：当订单支付成功之后，需要同时跟新订单状态以及扣减库存，而订单数据和库存数据位于不同的数据库中。
此时，更新订单状态、扣减库存这两个操作同属一个事务，两个操作作为一个执行单元不能被分割，要么都执行成功，要么都执行事物，不允许出现一个成功另一个失败的情况。
但是，在分布式的架构中，网络抖动、超时、服务故障等异常都是不可避免的。
比如，当上面的事物执行时，可能订单状态的更新在订单数据库上执行成功，但库存的扣减因网络原因在库存数据库中执行失败，这样就造成了数据库中的数据和我们期望的业务数据状态不一致。

avatar

问题

分布式事务是一组操作序列，序列中的任意操作都有可能因故障导致该操作执行失败，从而导致数据不一致。
又因为，故障会发生在任意时刻而且是100%会发生，所以分布式的事务一定会出现事务不一致的情况，无论采用哪一种方案。
因此，我们的技术实现方案便面临两个核心问题：第一、如何减少事务执行时发生故障的概率，第二、故障发生后出现数据不一致的情况如何解决。

方案

针对上面的第一个问题，可行的策略是在执行事务之前，先确保网络和数据库都不存在故障，然后再开始执行事务。
2PC(两阶段)、3PC(三阶段)、TCC采用的都是这种策略，除了TCC在执行失败时会通过撤销操作恢复数据的一致性外，其它的方式在事务执行失败时都没有任何的恢复策略，但TCC也不是绝对能保障数据会被恢复。
针对上面的第二个问题，可行的策略便是在故障发生后，不断地重试直至成功为主，或最大限度的保障其操作执行成功；
基于消息的最终一致性方案便是采用这种策略，相较于上面"快速失败"式的方案这种方案最大的问题是：数据从不一致恢复到一致的状态时，中间间隔的时间可能会过长。
下面我们分别介绍一下上面的几种方案。

2PC(两阶段)

avatar

在两阶段事务中，有两个角色：事务协调者、资源管理者。
事务协调者负责控制全局事务中多个本地事务的执行流程，它会将本地事务分发给对应的资源管理器并触发资源管理器执行本地事务。

avatar

两阶段事务的执行流程分成准备和提交两个阶段：

第一阶段，主要是确保各个资源管理器(数据库)处于正常状态，所以，事务管理器会先"试探"资源管理器："我开始事务了，你准备一下？"，
如果资源管理器准备就绪，那么它会告知事务管理器："我准备好了。"，否则资源管理器便处于异常状态；等所有的资源管理器都有回应无论是准备就绪还是异常，事务处理流程便会进入第二个阶段。

第二阶段，主要是根据第一阶段事务的准备结果来控制事务的流程，如果第一阶段中所有的事务都准备就绪，那么事务管理器便会通知资源管理器提交事务，否则取消事务。

两阶段的实现方式存在以下主要缺点：

同步阻塞：各个本地事务的执行会占用数据库的连接资源，连接的占用时长相当于整个事务的执行时长而不是单个本地事务的时长。

协调者故障：协调者如果不是分布式的那么存在单点故障的问题，如果协调者在第二阶段故障，那么有可能导致数据不一致。

数据不一致：当各个事务管理器收到提交指令后，便会将本地事务提交，但可能出现有些资源管理器在第二阶段没有收到提交指令，那么此时就会造成数据不一致情况。