这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天
分布式事务的补充内容
分布式模型概述
时间和事件顺序
论文《Time, Clocks, and the Ordering of Events in a Distributed System》，提出happened before，定义a->b是先发生a再发生b，那有发送信息到另一节点为a->b，如果a->b且b->c，则a->c，定义并发为当且仅当a-/->b且b-/->a，
将定型转为定量，设计了Lamport逻辑时钟，定义始终为一个函数，通过设置time-line，通过逻辑时钟对整个系统中的事件来全序排序，在同一节点的两个连续事件之间有一条tick line。分布式节点可能有两个并发事件，但物理时间和逻辑时间顺序反过来，这在分布式系统中是被允许的。通过定义逻辑时间戳，来有效解决分布式隔离性和一致性问题。
理论基础
CAP理论：一致性，指多副本间一致，可用性，指服务始终可用，分区容错，指任何网络分区故障一致且可用。CAP交集是真空的，无法同时全部满足三要素。
ACID理论：事务可以全部执行或者全部不执行，原子，一致，隔离和持久。（截图）AC一定要保证才能是合格数据库。
BASE理论：指导AP系统，出现故障优先保障可用，允许数据的中间状态并且不影响系统的整体可用性。比如游戏重视体验所以不同人呢可以看到不同画面信息，允许存在中间状态。最终保证最终一致性即可。
分布式事务
两阶段提交
基于三个假设，为了使得基于分布式系统架构下的所有节点在进行事务提交的时候
- 协调者和参与者进行网络通信
- 所有节点采用预写式日志，且日志被写入后保持在可靠的存储设备上
- 所有节点不会永久性损坏，即使损坏后也仍然可以恢复
包括如下阶段：
- prepare阶段：c发给p指令prepare，p返回给cDone
- commit阶段：c发给p指令commit，p返回给c ACK
可能存在的问题：
- c不宕机，p宕机，需要进行回滚操作。
- c宕机，p不宕机，新起一个协调者，等待查询状态后重复二阶段提交。
- c宕机，p也宕机，无法确定状态，需要数据库管理员介入防止出现不一样的状态。
两阶段提交注意的问题：
- 性能问题：
- 协调者单点故障：
- 网络分区问题：A转账给B，对于C，prepare成功，但c发给acommit成功但发给bcommit失败，也就是A扣款成功B多款失败，这种不可以。解决方法是通过锁机制保护，防止事务没完成就读取信息。这也导致了性能问题。
三阶段提交
判断是否能commit，如果满足commit条件再开始操作防止资源浪费，避免阻塞和资源浪费。发现节点故障就直接不发起prepare。
MVCC
锁：悲观锁和乐观锁。操作的时候直接将数据锁住，完成后才能释放锁，上锁期间其他人呢不能修改数据，这是悲观锁。而乐观锁是不上锁，在最后的时间检查别人是否修改数据，冲突的话就放弃操作。
而MVCC可以避免锁，保证一个数据的多版本实现读写操作无冲突，为每个修改保存一个版本，和事务的时间戳关联，可以提高并发性能，解决脏读的问题。
- 硬实现：通过truetime物理设备来实现前文逻辑时钟，服务器时钟偏差在1-7ms之间，但可以实现MVCC
- 软实现：与中心化时钟取得通信获得时间戳，算法简单，但是每个节点会与他进行交互，产生网络通信的成本。
