事务并发

简单介绍下锁机制：

        锁等待：当一个事务在特定数据（行、表）上持有锁时，只有当该事务终止并释放锁，其他事物才能对加锁的数据资源进行访问（根据锁类型，访问权限有所不同），其他事务等待锁的过程，称为锁等待。

       锁超时：锁等待时，将阻碍其他事务的执行，可以通过配置锁超时值，在指定时间间隔内，若等待的事务还未获得锁，则事务会回滚当前请求，这就是锁超时。

       死锁：两个或多个事务对锁的循环争用，称为死锁。

一、购买某一商品的活动序列：

               1.客户在前端选择了商品，此时该商品的价格、数量等都已经确定，系统也对其做了相应的计算，单未提交；

               2.系统管理员在管理端对该商品进行操作，如：删除、修改数量、修改金额、商品下架等

                3.此时回到步骤1的页面，点击【提交】看系统如何处理？

  二、电子商务网站中用户积分使用的一个活动序列：

                   1.某一客户在机器A上读取自己账户的积分为100元；

                   2.在机器B上读取自己账户的积分同样为100元；

                   3.在A机器上使用该客户80元积分；

                   4.在B机器上使用该客户70元积分；

                   5.此时在A.B两个机器上的操作员对使用积分的购物同时点击【提交】

                   正确的结果是：应该只有一方成功，另一方给出合理提示信息；

                   但处理不当就会导致：两个都成功，用户积分为负值

     三、飞机订票系统中的一个活动序列:

甲售票点（甲事务）读出某航班的机票余额A,设A=16.

乙售票点（乙事务）读出同一航班的机票余额A,也为16.

甲售票点卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库.

乙售票点也卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库.

     结果明明卖出两张机票，数据库中机票余额只减少1。

事务：是访问并可能更新数据库中各种数据项的一个程序执行单元（unit）

由于计算机可能会因为停电、网络中断等而出现故障，因此有可能更新了表中的行，但没有更新另一个表的行。如果事务中的某个点发生故障，则所有更新都可以回滚到事务开始前的状态。如果没有发生故障，则可以通过完成状态提交事务来完成更新。

     我们测试的目的是为了确保事务在发生故障时，所有更新都可以回滚到事务开始之前的状态。

 

通常事务会滚是以单元测试方式进行覆盖，如果是功能测试，要如何测试?

只要事务中最后一个节点故障，那么事务回滚后，最后一个节点之前所有的更新都会不会成功被更新到数据库中？ 那么我们需要知道该事务依次对那些表操作，人为的使事务提交失败而回滚。

 

什么是分布式事务

传统的基于数据库本地事务的解决方案只能保障单个服务的一次处理具备原子性、隔离性、一致性与持久性，但无法保障多个分布服务间处理的一致性。因此，我们必须建立一套分布式服务处理之间的协调机制，保障分布式服务处理的原子性、隔离性、一致性与持久性。

支付宝为什么需要分布式事务

基于SOA架构，整个支付宝系统会拆分成一系列独立开发、自包含、自主运行的业务服务，并将这些服务通过各种机制灵活地组装成最终用户所需要的产品与解决方案。

在多个服务协同完成一次业务时，由于业务约束（如红包不符合使用条件、账户余额不足等）、系统故障（如网络或系统超时或中断、数据库约束不满足等），都可能造成服务处理过程在任何一步无法继续，使数据处于不一致的状态，产生严重的业务后果，所以我们需要一个分布式事务的解决方案,用来协调多个服务的业务一致性。

支付宝的分布式事务框架

支付宝开发的分布式事务是基于两阶段提交的理论(Two Phase Commit)。

阶段一：1.TM（事务管理器）向所有的RM（资源管理器）发送准备请求

        2.RM收到准备请求后，进行准备操作，并向TM回复是否可以提交

阶段二：1.TM收到所有RM的回复后，如果所有RM均可以提交，向所有的RM发送提交请求，否则发送回滚请求

        2.RM根据TM发送的消息控制本地事务提交、回滚