终于有一篇文章把“事务”讲清楚了！
不知道你是否遇到这样的场景，去小卖铺买东西，付了钱，但店主突然有事情需要去处理，等处理回来之后给到你的货物与你最开始想要买的不一致，或许多了，或许少了，或许拿错了，甚至是间歇性失忆忘记你曾经付过钱反而要求你重新付钱了。
又或是在线购物时，付款成功后可以增加积分，但是个人积分却没有任何变动，或者是明明成功付款了，过一会儿店小二联系你说没有库存了希望你能申请下退款。这所有的事情总结起来就是某个操作的期望与实际不一致，而这背后的原因就是没有事务。
那么事务是什么呢？事务是一种工作机制，它把一个活动所涉及的其他所有操作都放入一个不可分割的执行单元，只有所有的操作都执行成功，事务才算完成，否则整个事务就不成功，回到原始状态。
有了事务，你去小卖铺买东西的时候，你付钱、店主给你对应的货品、店主减掉库存这三个操作都完成后，整个买东西的操作才算完成，如果你没有付钱或者店主没有给到你对应的货品，那么这个事务就算是执行失败，就会回到最初的状态，钱还是你的钱，货还是商家的货，不增不减。
事务主要使用在数据库场合，有本地事务、分布式事务两种业态。
对于数据库本地事务来说，这个很好理解，因为涉及数据的内容都会存在数据库里，而数据改动中最重要的就是对金钱财产有改动的内容，需要通过事务去保障，不然你付了钱，却不给你发货，你是不是要去找卖家申诉，而平台老出问题，卖家是不是要去找平台申诉，环环相扣，最终会影响一大波人，因此事务是非常重要的。
对于分布式事务，这个主要是由于分布式架构、微服务的出现产生的，分布式事务的一致性也同等重要。
数据库事务最重要的特点就是ACID，即原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability。所谓原子性就是事务中所涉及的所有操作，是一个最小的不可分割的，要么全部完成，要么全部不完成，如果事务在执行过程中发生错误，则回滚到事务开始前的状态，就像你买东西一样，要么交钱收货一起完成，否则就不给钱或不发货。
所谓一致性就是事务在执行前后数据库内容要一致，就像你买东西一样，买之前商家的售货额与商品库存分别是100、1000，在你买之前，所有的人来买东西时商家的售货额和库存均是100、1000，你花了50块钱成功买了100件物品，那么商家的售货额与库存变为150、900，所有的人来买东西时商家的售货额和库存均是150、900，商家的个人数据库始终一致。
所谓隔离性就是在并发环境中，不同的食物操作相同的数据时，每个事务独立执行，互不影响，就像你去小卖铺买东西，并不影响其它人也来小卖铺买东西，但是你买货结账时的售货额和库存一定是个确定值，不会看到中间态。所谓持久性是指只要事务成功结束，那么数据库会更新记录，即使发生系统崩溃、重启数据库系统后，数据库也还能恢复到事务成功结束时的状态，就像你去小卖铺买东西，所有的交易记录老板都记录在账本上，即使老板忘记了也还可以查账本。
随着互联网用户和流量的剧增，业务架构模式开始拆分成微服务、业务部署模式变为分布式。
所谓微服务架构就是把原来一体化的应用拆分成能独立完成功能的原子化模块，比如电商系统服务可拆分成用户管理微服务、商品管理微服务、订单管理微服务、库存管理微服务、交易管理微服务等模块，原先在一套系统内可以完成的付款、减库存、加订单的事务操作现在要分散在交易管理、订单管理、库存管理三个子模块完成，本地事务变成分布式事务。所谓分布式部署则是为了容灾与高可用，将重要的、最常用的服务多个节点部署，保障无论何时服务都能正常响应，比如将电商系统服务中的商品管理在北京、上海、杭州、深圳都部署一套，订单管理、库存管理、交易管理等部署杭州，当用户在北京发生一笔交易时，需要杭州的服务与北京的服务通信，共同完成任务，从而本地事务变成分布式事务。
分布式事务的产生是必然，那么又如何保障分布式事务的一致性呢？业内的解法有CAP理论、BASE理论，CAP理论即一致性Consistency、可用性Availability、分区容错性Partitiontolerance三者不能共存，要么保障系统的可用性AP、要么保障系统的一致性CP。
这是因为CAP是在分布式部署、微服务架构的情况下提出来的，所以分区一定存在，如果为了保障数据的一致性，那么当用户在北京服务节点发生交易时，杭州的服务节点就不能使用，得等到整个交易完成了才能进行，这时候就出现了可用性缺失，如果为了保障系统的可用性，用户在北京服务节点的交易和杭州服务节点的数据因为存在数据传输延迟，数据必然会不一致，所以一致性和可用性只能二选一。
对于电商平台来说，因为覆盖的用户广，无论如何都要保障业务随时可用，对于数据的准确性可以接受一定的错误，而对于交易系统来说，涉及到用户财产，那是一分一毫都不能少，所以数据的一致性非常重要。
BASE理论即基本可用BasicallyAvailable、软状态SoftState、最终一致性EventuallyConsistent，是对于CAP定论中的AP的扩展。所谓基本可用是指分布式系统在出现故障时，允许部分非核心业务功能不可用，保障核心功能可用。所谓软状态是指分布式系统中允许存在中间状态，允许部分出错。所谓最终一致是指经过一段时间后，所有分布式节点数据达到一致。
分布式事务是在互联网的飞速发展下应运而生。在我们的业务系统中究竟采取本地事务还是分布式事务应当视具体情况而定，不能为了分布式而分布式。如果真的必须分布式，那么需要结合自己的业务类型选择合适的模式，可用性、强一致性、最终一致性都是可行的。