Transactions 事务
这并不是一个很天然的概念，而是为了简化人的操作，设计出的一种机制，事务机制需要保证一些特性以方便人的使用，一般大家认为事务需要保证ACID特性
事务的保障通常需要一些额外的措施，这和目前数据库最求的效率，这是一个需要权衡的方面
1.1 事务的特性ACID
这应该是数据库的基本概念，需要注意，目前并不是所有的数据库都需要保证ACID，这其实是需要根据业务特性进行选择的
Aotumatic
原子性，要么成功，要么不成功，不会有处理一半的情况
Consistency
通常情况下，我们会选择通过应用程序去控制一致性，如转账，转出和转入一定要平衡。数据库一半很难保证这个一致性
Isolation
这是主要针对并发来讲的，你的处理过程中的中间环节，相对于其他的并发，是隔离的，并不会被外界感知
最严格的Isolation就是Serializability，串行执行，但这样效率是在是太低了，数据库Mysql里隔离级别，可以专门见数据库部分
Durability
持久化，应该是最容易理解的了，以前的持久化，我们通常是指持久化到硬盘中，但随着分布式技术的发展，有时候，我们会认为，数据到了副本上也算是持久化成功。
但为了万无一失，通常是副本和磁盘持久化都进行
1.2 事务相关的几个概念
- 1.RM（Resource Manager）,数据资源的储存和管理者，如数据库服务器等
- 2.TP Monitor（Transaction Processing Monitor），它的职责是在分布式事务场景中协调包含多个RM的事务处理
- TM（Transaction Manager） TP Monitor的核心模块，直接负责和多RM之间的事务处理协调工作，提供事务界定，上下文传播等功能
- 4.应用，应用是实际运行的程序，可以认为是事务边界的触发点。根据整个事务中涉及的RM的多寡，可以分为2类事务，全局事务和局部事务
-
5.局部事务，事务中只有一个RM参与，如对一个数据库进行更新，一般都直接由RM内置的事务支持完成即可，不需要TP Monitor进行
image.png -
6.全局事务，事务中有多个RM参与。这是比较复杂的情况，此时会引入TP Monitor进行协调，TP Monitor采用两阶段提交的协议来保证整个事务的ACID属性。
image.png
所有应用提交的事务请求，都经过TP Monitor调配，直接由TM进行统一使用两阶段提交的模式进行处理。
- 两阶段提交，最经典的比喻，西方婚礼主持或牧师是TM，向两位新人（RM）询问是否原因，当2位新人都回答 i do，可以进行，才会正式宣布结尾夫妻，进行提交，其中任何一个新人有疑议，都会失败，进行回滚
1.3 Single Object and Multi-Object Operation
这里的物体可以是row，也可以是document，record等等，总的来说Multi-Object 事务是一个复杂的过程，必须满足很多条件
Single Object write
使得单体写入失败的原因有很多，写入时机器宕机，网络中断等等
保障单体写入事物的手段很多：如之前讲过的WAL，行锁，CAS等等
Multi-Object write 重试机制的弊端
虽然极力避免，但总有些情况，会发生这种情况
丢弃这次操作，进行重试是最常见的一种方式，但这也常常也会带来新的问题
- 如rpc调用等，调用失败，但可能服务提供方实际是成功了，只是网络导致在消费方显示失败，这时候除非你有应用级别删除重复的操作，或幂等性等特性，不然无法简单重试
- 由于过载导致的问题，重试机制会使得问题更糟糕，通常这里使用限制重试次数来缓解
- 你的操作必须没有副作用，如发送邮件，写入数据库等
1.4 ISOLATION LEVEL---隔离级别
并发应该是系统中常见的问题，资源有限的情况下，为了性能，并发是常见的选择。
database如mysql等，为了简化操作，通过隔离级别，来保证执行的效果。
单线程顺序执行，最可靠但是代价最高，所以实际中都会选择弱一些的隔离级别，但这在关键的金融系统等，可能会带来危险。
这块参考mysql隔离级别
