普通事务与分布式事务

普通事务与分布式事务

1.1 普通事务

普通事务就是一般所说的数据库事务。

事务是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。当事务被提交给了DBMS（数据库管理系统），则DBMS（数据库管理系统）需要确保该事务中的所有操作都成功完成且其结果被永久保存在数据库中，如果事务中有的操作没有成功完成，则事务中的所有操作都需要被回滚，回到事务执行前的状态;同时，该事务对数据库或者其他事务的执行无影响，所有的事务都好像在独立的运行。

事务的ACID特性
原子性（A）：所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。
一致性（C）：事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B 50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么最后A账户一定是450元，B账户一定是350元。
隔离性（I）：所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。
持久性（D）：所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。

有了原子性为什么还要提一致性呢，原子性不能保证一致性吗？这就涉及到并发事务的概念。对于单个事务来说，原子性就能保证一致性，但是对于多个并发执行的事务，即使每个事务都是原子执行的，但它们同时执行的话，最终效果可能会不一致。举个例子，假设有A和B两个账户，各有200元钱。事务1是A账户向B账户转账100，则事务1将会执行如下语句：

update A set amount=amount-100 where userId=1;
update B set amount=amount+100 where userId=1;

但是在同一时刻又有一个事务2，事务2是账户C也给账户B转账100元，则事务2会执行如下语句：

update C set amount=amount-100 where userId=1;
update B set amount=amount+100 where userId=1;

如果事务1和事务2同时执行的一致性结果应该是B账户里面有300元钱，但如果事务不能保证一致性的话，事务1和事务2同时执行时，两个事务读到的账户B的当前金额都可能是100(脏读)，不管两个事务谁先执行完成，最终的执行结果都是B账户金额为200。因此，要达到事务的一致性，除了要保证单个事务的原子性之外，还要保证事务之间的隔离性。

1.2 分布式事务（Distributed Transaction DT ）

分布式事务，顾名思义就是在分布式环境下运行的事务，对于分布式事务来说，事务的每个操作步骤是运行在不同机器上的服务的。分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）

在现如今的大型互联网平台中，基本上都是采用分布式的SOA架构，所以分布式事务是非常常见的。比如一个电商平台的下单场景，一般对于用户下单会有两个步骤，一是订单业务采取下订单操作，二是库存业务采取减库存操作，但在大型电子商务平台上这两个业务一般会运行在不同的机器上，这就是一个典型的分布式事务场景。还有一个常见的场景就是支付宝向余额宝转账，而支付宝和余额宝不是一个系统，怎么保证这两个系统之间的一致性就是分布式事务所关注的问题。

1.2.1 分布式系统CAP定律
为了更方便的理解分布式事务，这里插一个分布式系统的CAP定律。在分布式系统里面有一个CAP定律，这个定理的内容是指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP定律是NoSQL数据库的基石，而CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有系统能同时保证这三点，而NoSQL则选了可用性。

NoSQL数据库主要做的是简单的键值查询，因此NoSQL系统通常注重性能和扩展性，而非事务机制（事务就是强一致性的体现）

1.2.2 一致性理论
数据一致性的基础理论：

强一致：当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。

弱一致性：系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。

最终一致性：弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。

1.2.3 分布式事务特性—最终一致性
在互联网大型分布式平台场景中，为了保障系统的可用性，他们一般会把强一致性的需求转换成最终一致性的需求。所以，对于大部分分布式事务场景，我们仅需要保证最终一致性即可。

摘自关于分布式事务