今天看见了我的同事马银霜，她穿的是白色的羽绒服，还挺好看的，好想过去把她按在地上。。。
本文作为分布式学习的一个提纲和总结，目前只是随笔，尚未添加文章分类
要想做一个完善的分布式系统，至少要有下面这几种组件
1.远程过程调用
2.分布式同步服务
3.安全认证
4.文件系统
5.资源管理系统 k8s
6.集群管理系统 运维
7.集群监控系统 运维
实现分布式事务，只有三种方式
1.锁：动态的执行事物间的串行顺序，顺序与要锁的对象有关，在一定长度上限制了并发的可能性，其实就是影响一定的效率
2.乐观并发控制：假设所有事务都不相互影响，只有在提交的时候，才验证，就是说验证是最后一道程序，如果出现异常，想要回滚，相对来说比较麻烦，如果不出现异常，乐观并发控制是性能较好的，如果出现异常，则性能很差
3.时间戳排序：静态的决定了串行顺序，顺序与事务开启的顺序有关（注意与锁的区别），言外之意就是哪个事务先开启，就哪个事务先执行，很大程度的限制了并发的可能，其实就是效率很低
分布式事务架构，所有的分布式都一定是这种架构，必须有两种角色
（1）事务的协调者coordinator，
（2）事务的参与者
牢记上述两种角色，接下来阐述事务提交协议的演变
单阶段原子提交协议：参与者事务的提交和放弃都是协调者说了算，不允许参与者单方面放弃事务，这样就会导致如果参与者挂了，就会死锁，如果死锁，协调者就没办法解决
二段提交：为了支持参与者单方面放弃事务，出现了二段提交协议
（1）准备阶段，也叫投票阶段，过程如下
（1.1）协调者向所有参与者询问能否提交请求
（1.2）
- 如果参与者回复yes，则参与者必须将本次事务改变的对象以及自己的各种状态，都存储到持久性介质当中，例如存到某个文件上，或者mysql中，通通可以理解存到硬盘上，回复完毕之后，必须等待协调者进一步指示（此时被参与者的状态被称作"不确定的状态"），在等待期间，参与者除了继续询问协调者结果之外，无法做其他的事情，协调者一段时间内没有回复，则认为协调者宕机，此时应该执行事务回滚（单方面放弃事务）
- 如果参与者回复no，参与者立即放弃事务（意味着后来其他参与者也会因为该参与者的放弃而回滚）
（2）完成阶段，协调者根据阶段1的结果，决定告诉所有参与者是提交事务还是放弃事务，参与者操作完毕之后，返回haveCommited状态
缺点：比方A是协调者，B参与者，A给B发了doCommit，然后A挂了，此时B执行commit，返回给A，此时A重启之后，已经无法接到B是成功还是失败
其实解决这个问题我个人觉得很简单的办法就是A重启之后，再询问B是成功还是失败，不过业界普遍采用的方式是三段提交
三段提交：将二段提交的12阶段之间，增加一个preCommit阶段，也叫准备提交阶段
（1）协调者向所有参与者发送准备提交preCommit命令
如果发送之后，协调者挂了，没关系，所有参与者都没有doCommit，协调者可以从新发送preCommit
如果发送之后，某个参与者挂了，没关系，协调者感知到之后，通知所有参与者撤销事务
（2）完成阶段，就是之前说的二段提交协议的完成阶段
如果发送之后，协调者挂了，没关系，选出新的协调者，新的协调者发现当前是完成阶段，那么告诉其他参与者，没有doCommit的继续，已经doCommit的告诉我已经完成
日记：会不会有参与者不知道自己是否已经doCommit呢？？不会，但是为什么不会，因为目前我的知识还不清楚单机事务是如何实现的，总之既然能实现单机事务，那么就足以说明这个假设不成立