说明：由于2015年10月18号 由朋友龚正组织的技术交流会讨论的分布式事务，故而整理一下，加上自己理解写的
单机事务讲解
分布式事务的讲解（并说出常见的分布式事务的模型）
一．什么是事务
事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。
事务的结束有两种，当事务中的所以步骤全部成功执行时，事务提交。如果其中一个步骤失败，将发生回滚操作，撤消撤消之前到事务开始时的所以操作。
事务的基本属性 ACID
事务具有四个特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和永久性（ Durability ）。这四个特性简称为 ACID 特性。
1 、原子性
事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做
2 、一致性
事 务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是 不一致的状态。
3 、隔离性
一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
4 、永久性
也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。
数据库事务隔离级别
数据库事务的隔离级别有4个，由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。
注意：我们讨论隔离级别的场景，主要是在多个事务并发的情况下，因此，接下来的讲解都围绕事务并发。
Read uncommitted 读未提交
公司发工资了，领导把5000元打到singo的账号上，但是该事务并未提交，而 singo正好去查看账户，发现工资已经到账，是5000元整，非常高兴。可是不幸的是，领导发现发给singo的工资金额不对，是2000元，于是迅速 回滚了事务，修改金额后，将事务提交，最后singo实际的工资只有2000元，singo空欢喜一场。
出现上述情况，即我们所说的脏读，两个并发的事务，“事务A：领导给singo发工资”、“事务B：singo查询工资账户”，事务B读取了事务A尚未提交的数据。
当隔离级别设置为Read uncommitted时，就可能出现脏读，如何避免脏读，请看下一个隔离级别。
Readcommitted 读提交
singo拿着工资卡去消费，系统读取到卡里确实有2000元，而此时她的老婆也正好在网上转账，把singo工资卡的2000元转到另一账户，并在singo之前提交了事务，当singo扣款时，系统检查到singo的工资卡已经没有 钱，扣款失败，singo十分纳闷，明明卡里有钱，为何......
出现上述情况，即我们所说的不可重复读，两个并发的事务，“事务A：singo消费”、“事务B：singo的老婆网上转账”，事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。
当隔离级别设置为Read committed时，避免了脏读，但是可能会造成不可重复读。
大多数数据库的默认级别就是Readcommitted，比如Sql Server , Oracle。如何解决不可重复读这一问题，请看下一个隔离级别。
简单说：就是事务A和事务B都能看到当前数据状态，只是看那个事务先提交，另一个事务的操作是在已提交事务的基础上再操作的
Repeatableread 重复读
当隔离级别设置为Repeatable read时，可以避免不可重复读。当singo拿着工资卡去消费时，一旦系统开始读取工资卡信息（即事务开始），singo的老婆就不可能对该记录进行修改，也就是singo的老婆不能在此时转账。
虽然Repeatable read避免了不可重复读，但还有可能出现幻读。
singo的老婆工作在银行部门，她时常通过银行内部系统查看singo的信用卡消费记录。有一天，她正在查询到singo当月信用卡的总消费金额（selectsum(amount) from transaction where month = 本月）为80元，而singo此时正好在外面胡吃海塞后在收银台买单，消费1000元，即新增了一条1000元的消费记录（insert transaction ... ），并提交了事务，随后singo的老婆将singo当月信用卡消费的明细打印到A4纸上，却发现消费总额为1080元，singo的老婆很诧异，以为出现了幻觉，幻读就这样产生了。
简单说 ：就是事务A看不到事务B对数据的修改，事务A查看的还是事务B之前的数据
注：Mysql的默认隔离级别就是Repeatable read。
Serializable序列化（通常也叫串读）
Serializable是最高的事务隔离级别，同时代价也花费最高，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻像读。
最后剩下一个事务的传播行为，网址：http://blog.csdn.net/loadhai/article/details/17800537
1. 单机事务：
举例：支付宝向余额宝转账100元 假如是在一台服务器上进行 涉及到的操作是：
锁住账户A的支付宝 锁住账户A的余额宝 查询账户A的支付宝是否足够100元 支付宝更新 余额宝更新 提交事务
在单机中非常简单，只要满足事务的基特性即可，现实中支付宝和余额宝是两个应用，也有几个亿的用，不可能只在一台服务器上，这就出现了服务器集群，支付宝是一个应用，余额
宝是一个应用，这才符合实际，那当前事务拆解：
现在怎么保证两个事务同时完成，同时失败呢？也就是怎么保持事务ACID呢？
A.先说下两段提交协议2PC（2 Phase Commit）模型，这是一般情况下分布式事务处理模型
准备阶段：事务管理器通知支付宝事务和余额宝事务，你们可以执行事务了，此时支付宝和余额宝事务开始准备所有相关工作和处理，完事后给TM一个准备就绪消息。
提交阶段：
所有事务都准备OK后，TM发送提交（或取消）消息，相关子事务开始处理本事务
借宿阶段：
TM释放相关资源，分布式事务结束
说明：分布式事务无法保证事务的一致性，但能保证弱一致性，就是最终一致性
反观此种做法，弊端：1.资源消耗大 2.会有宕机情况的发生 此时主要根据日志恢复未完成的事务
有一种说法 ：最好的分布式事务，就是不用分布式事务，就是单机事务，上述业务能否不用2PC这种分布式事务的处理方法呢，因为几个亿的数据量，你都给锁住，在加上TM，那是惊人的消耗内存资源，相当于页面要等待很久的反应，支付宝余额宝会用么？显然不会
B.较第一种做法，另一种做法事务MQ （消息机制）
MQ是 一个消息队列 在实际生产环境中也是一个集群（更深也伴有自己的数据库，也有状态机）
此机制为：支付宝事务 在开始 向MQ发送一条消息，我开始了，在完成后在发一条消息，我完成了，此时，MQ收到后会通知余额宝事务去完成事务
ACK 代表： 确实 好 我知道了
在此机制中，大家想想 支付宝若只在开始发送消息会出现什么问题？只在最后发送消息会出现什么问题？此机制最大的弊端在哪？
只在开始发送， 可能支付宝事务会失败，但余额宝成功了；只在最后发，可能支付宝事务成功，但余额宝时报了
这边全是理论知识，在实际中，我没用过，忘大家提出问题，一起进步，谢谢