分布式

事务的ACID

原子性：要么全部都成功，要么全部都失败

一致性： 保证能看到系统内的所有更改

隔离性：以性能为理由，对一致性的破坏

　　　　序列化读写：排它锁(单位时间内只能有一个人进来)

　　读写锁：

　　　　可重复读：读锁不能被写锁升级，只能做到读读可以并行。

　　　　读已提交：读锁可以被写锁升级，读读并行、读写并行（写读不能并行）

　　　　　　读写并行的时候可能出现读写一个事务里面两次读取数据是不一致的

　　　　读未提交：只加写锁，读不加锁，读读并行、读写并行、写读并行

　　快照隔离级别 : mvcc（copy on write）无锁编程(适合读写比率比较高的系统)

　　　　mvcc所做得事情就是读请求全部放到1版本总执行，不会再2版本中执行.(1版本是历史版本，2版本是当前事务版本)

　　　　针对读多写少场景优化

　　　　并行度能达到或超过读未提交，而隔离级别很高

　　　　快照和读未提交级别对比：快照读的情况下能保证在读到一致性的同时实现读未提交

 持久性：事务完成以后，该事务对数据库所做的更改便持久的保存在数据库中

用raid的持久性保存数据不丢失

数据丢失可能：

　　1、磁盘损坏

　　

1、提交请求到内存后返回

2、将内存的数据打包到磁盘中

事务的调优原则

在不影响业务应用的前提下，

增加锁上可以并行的线程数

读锁、写锁分离、允许并行读取数据

多线程并行读取

允许更多人读取

在不影响业务应用的前提下

选择正确锁类型

悲观锁：使线程到blocking状态

乐观锁　　　　

-------

分布式事务：

　　跨库：无法使用事务解决。

　　解决方案：

　　两阶段提交协议(2pc)

　　两阶段提交

　　　　阶段1  tcc try 请求多个业务预留业务资源

　　　　阶段2  tcc confirm 确认执行每个业务的资源操作

　　　　　　　tcc cancel  取消执行每个业务方的资源操作

　　　　　　　　xa prepare 询问每个rm是否可以提交事务

　　　　　　　　xa commit 提交每个rm上的事务分支

　　　　　　　　xa rollback 回滚每个rm上的事务分支

柔性事务

tcc(try-confirm-cancel) 两阶段补偿性方案

 base理论

基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

软状态：指允许系统中数据存在中间状态，并认为该中间状态的存在不会影响系统整个可用性，既允许系统在不同节点上的数据副本之间进行数据同步的过程存在延迟。

最终一致性：允许经过一段时间之后最终达到数据一致性，而不需要实时保证数据的一致性。

---

tcc与xa/jta对比

xa是资源层面的分布式事务，强一致性。在两阶段提交的过程中一直会持有资源的锁

tcc是业务层面分布式事务，最终一致性，不会一直持有资源的锁