在线分布式数据库原理

事务单元之间的处理

事务的ACID要求事务需要满足原子性、一致性、隔离性和持久性。事务具有了隔离性，为什么要分几种隔离级别呢？也就是未提交读、已提交读、可重复读和可串行化？实际上事务的这几种隔离级别对应了多个事务执行时对并发的容忍度，比如在读写场景中，

对应着可串行化，这样做可以具有较高的隔离性，但是系统性能很低，可以把读并行化，读和写加上读写锁，这时隔离级别成为可重复读，系统性能进一步提高。

再进一步，可以将读锁完全去除，只有写的时候再加锁，可以实现读写并行，但是这时可能会两次读的数据不一致，违反一致性。这时一致性和隔离性就产生冲突了。

目前主流数据库实现的方法为MVCC，多版本并发控制，本质就是copy on write，做到写不阻塞读，系统在写的时候，仍然可以并发地读，只有写和写之间加锁。这样做也有问题，使得系统的实现变得更加复杂了。

事务处理的常见问题

(1)谁先谁后?
采用逻辑时间戳
SCN(Oracle)
Trx_id(Innodb)
(2)故障恢复
比如业务属性不匹配，如何保证原子性?基于日志的数据库都可以通过日志回滚，保证原子性。当系统崩溃后怎么处理呢?系统崩溃后线程丢失，锁也随之消失，事务其实只进行了一半。这就要求数据库系统在重启的时候眼做到回滚到上次操作的开始，使得执行失败的事务好像没有被执行一样。
(3)死锁与死锁检测
两个线程沿不同方向访问相同资源就会产生死锁。数据库系统中用两种方法检测死锁，一种是碰撞检测(检测某个对象是否有两个相反方向的锁，去掉一遍即可)，二是等锁超时，检测超时的锁。

深入理解单机事务

原子性很好理解，数据库系统根据日志回滚可以保证原子性，一致性其实是指系统在内部完成所有更改后才会对外部可见;事务的隔离性方面，用排它锁实现了序列化读写，即可串行化，读写锁实现了可重复读，读读可并行，读写锁也实现了读已提交，读锁可以被到来的写请求升级为写锁。读未提交只加了写锁，没有读锁，读和写可以并行，这样做所有写是串行的，读到的数据不一致可能性很大，一般不用。

参考:https://www.youtube.com/watch?v=KMfxAJa2Jtc&list=PLO5e_-yXpYLD88Y5ZBHTT1N22qwDLqB6W