背景
上期组内分享了分布式事务的内容，自己收获很大，因此，小泉也来浅浅的聊一下分布式事务。
分布式事务将会分两篇进行讲解，一篇基础篇，介绍分布式事务的基础理论以及分布式事务解决的问题；一篇为解决方案篇，主要会讲分布式事务解决方案。本篇即为基础篇。
事务
事务的概念最早出现在数据库管理系统（DBMS）中，它由一组操作组成，这些操作要么全部执行成功，要么全部执行失败。
ACID
说到事务，就不得不提到它的四大特性。
原子性(Atomicity): 事务内所有操作要么全部执行完成，要么全部执行失败，不会出现部分完成部分失败的情况。
一致性(Consistency): 事务必须使系统从一个一致性状态变到另一个一致性状态。事务完成时，所有的数据都必须符合预定义的规则和约束。 如数据完整性约束：如主键约束、外键约束、唯一性约束等；业务逻辑约束：如银行账户余额不能为负数、库存数量不能小于零等。
隔离性(Isolation): 事务在执行过程中，不应受到其他正在执行的事务的影响即事务之间是相互隔离的，未提交的事务对于其他事务而言理应不可见。
持久性(Durability): 一旦事务提交，结果就会被永久保存，即使系统崩溃，结果也不会丢失。
什么是分布式事务？
在没有分布式的概念之前，事务中的操作都是在一台机器服务上执行的，我们也称之为本地事务/单机事务。而随着分布式系统的演进，事务中的操作分布在不同节点上即在不同的节点机器执行，分布式事务则需要保证这些操作执行前后全局资源的一致性与完整性，特别是在微服务架构下尤为重要。
购物车下单
分布式事务最经典的场景无疑就是购物车下单场景。
下单首先会触达购物系统，购物系统则会分别去订单系统下创建订单和库存系统下扣除库存量。
那么如果订单创建失败或者库存扣除失败，那么此次下单都应该回滚，既不创建订单也不扣除库存。
朋友圈发布
再比如用户发布记录到朋友圈。
那么此次发布就需要状态更新服务记录发布状态更新，通知服务来通知好友，状态统计服务来统计状态更新次数。
同样如果三个系统有一个失败了，此次发布就应当算作失败，其余系统都要回滚自己的操作。
分布式事务的基础
CAP理论
在一个分布式计算系统来说，一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)不可能同时满足，因此分布式系统一般选择AP或者CP架构，因为在分布式系统中，网络分区是无法避免的，如果无法容忍网络分区，就意味着系统需要拒绝请求进而导致不可用。
BASE理论
根据CAP理论，要想保证事务的ACID特性，那么无疑需要CP架构，但是可用性又是互联网环境下需要得到保障的。
BASE理论则是在AP架构上扩展兼容了C，即不严格要求分布式系统中的节点保持强一致性，只需要保障经过一段时间同步后节点最终达到一致性即可。
BA: Basically Available，基本可用，在系统内有节点出现故障时，牺牲部分可用性，仍保持核心功能的可用性。
S: Soft state， 软状态，允许系统出现短暂的节点数据不一致，即允许数据状态存在中间态。
E: Eventually consistent，最终一致性，经过一段时间同步后，不同节点中的数据最终达到一致性状态。
一致性模型
分布式的一致性模型一般分为三种，强一致性、弱一致性、最终一致性，但实际上最终一致性也属于弱一致性中的一种。这里的一致性对应的其实是事务中的原子性。
-
强一致性
-
强一致性是指在数据写入系统后，后续任何一次对数据的读取都必须读到最近一次写入的数据，也就是从不同节点读到的数据必须是最新的。
-
线性一致性
- 也称为严格一致性，线性一致性要求每个操作都可以被认为是瞬时的，并且在一个全局时间点(这就要求有全局时钟的概念) 立即生效。所有读操作都能看到最新的写操作。如分布式锁。
-
顺序一致性
- 相较于线性一致性，顺序一致性不依赖全局时钟，它保证的是所有节点看到的操作顺序一致，按照操作的全局顺序保持一致，这个全局顺序可能不是时序。
-
-
弱一致性 && 最终一致性
-
弱一致性与强一致性相反，他并不保证每次读取数据的操作都是最新的数据，允许数据有一定的同步、传播时间。
-
而最终一致性是一种特殊的弱一致性，它可以保证在合理时间内节点达到一致性，并维持较长时间的一致性。
-
单调读一致性
- 单调读一致性保证每个读操作都能看到之前所有读操作的结果或更新后的结果，比如版本控制系统，每次
git log都要能看到当前分支最新提交后的记录。
- 单调读一致性保证每个读操作都能看到之前所有读操作的结果或更新后的结果，比如版本控制系统，每次
-
单调写一致性
- 单调写一致性保证的是写操作按序执行，不可逆序。如分布式文件系统的文件写入。
-
因果一致性
- 因果一致性保证因果关系的操作在所有节点上的执行顺序一致，保障的是局部一致性，比如操作A引发操作B，那么所有节点都需要先执行A再执行B。
-
会话一致性
- 会话一致性像是因果一致性的实际使用模型，即保证会话(窗口)内数据的一致性，即在同一会话(窗口)中的读操作总能看到之前写操作的结果。但会话外不保证一致性。
-
Git系统的一致性
Git 系统其实也是一种基于分布式的版本控制系统，这里衍生聊一下git系统的分布式相关一致性。
-
单调读一致性（Monotonic Read Consistency）
在Git中，单调读一致性表现为在不同时间点查看仓库状态时，后续查看操作包含所有之前的提交和变更记录。
-
最终一致性（Eventual Consistency）
Git也展示了最终一致性，如多个开发者在各自的本地仓库中进行独立的提交操作，通过同步操作如
pull、push、merge等操作，最终使仓库达到一致状态。
非拜占庭问题
非拜占庭问题与拜占庭问题正好相反。
一组拜占庭将军分别各率领一支军队共同围困一座城市，各支军队的行动策略只有为进攻或撤离两种。由于部分军队进攻部分军队撤离可能会造成灾难性后果，各位将军必须通过投票来达成一致策略，要么一起进攻，要么一起撤离。
各位将军分处城市不同方向，所以他们只能通过信使互相联系。在投票过程中每位将军都将自己投票给进攻还是撤退的信息通过信使分别通知其他所有将军，每位将军根据自己的投票以及其他将军送来的信息就可以知道共同的投票结果而决定行动策略。
拜占庭问题则是指此时这几个将军中出现了“叛徒”，给不同的将军发送了不同的信息，导致将军做出了不同的策略，从而破坏了一致性。
非拜占庭问题则是指此时这几个将军中没有出现“叛徒”，只是没法发送消息或者发送延迟（节点宕机或者网络故障）等，没有恶意发送错误消息。
分布式事务的难点
在分布式系统中，由于数据和服务分散在不同的节点上，执行事务时可能面临一些挑战。
- 网络不可靠性
在分布式系统中，网络通信是不可避免的，这也就意味着网络延迟、丢包、分区等情况也是不可避免的，这些情况都会严重影响分布式事务的执行。
- 延迟、丢包：网络延迟、丢包会导致事务执行时间变长，影响系统的性能和响应时间。
- 网络分区：网络分区则会导致部分节点无法通信，导致无法协调事务的提交或回滚。
- 节点故障
分布式系统中的任何节点都可能发生故障（如崩溃、宕机等），这会影响事务的执行和完成。
- 协调者故障：在两阶段提交协议中，如果协调者在准备阶段或提交阶段发生故障，整个事务可能会陷入不确定状态，无法确定是否提交或回滚。
- 参与者故障：参与者故障会导致无法完成准备或提交操作，从而影响事务的一致性。
- C和A的权衡（ CAP 理论）
根据CAP定理以及BASE理论，分布式事务往往需要在一致性和可用性之间进行权衡。
分布式事务解决了什么？
分布式事务旨在解决多个节点或系统之间的事务处理的一致性和可靠性问题。而分布式事务解决方案的前提都是无节点恶意发送错误消息，分布式解决方案针对的是分布式系统下的非拜占庭问题。
以下是分布式事务解决的主要问题：
- 数据一致性：在分布式环境中，不同节点上的数据可能会因为网络延迟或故障而出现不一致。分布式事务确保在所有参与节点上，事务的操作要么全部成功，要么全部失败，从而保持数据的一致性。
- 跨多个资源的管理：分布式事务可以在多个数据源或服务之间执行操作，比如同时更新数据库和消息队列，确保它们保持一致性。
- 性能与可用性权衡：分布式事务实现了一致性和可靠性的保证，同时设计上也需要考虑性能和可用性，避免因过于严格的锁机制导致系统性能下降。
总结
本文主要讲解了一些分布式事务的理论基础以及分布式事务解决的问题与难点所在。下一篇会给大家介绍分布式事务的解决方案。
参考
数据一致性 数据一致性有哪几种?数据一致性详解-PingCAP | 平凯星辰
