分布式系统基本概念 二
分布式系统基本概念 二
前言
最近工作上又开始做C++方面的东西。。。因为对C++不是很熟悉，所以花了一些时间在读代码和做新feature上，下班也比较晚。只能晚上稍微晚一点看一写分布式系统知识和Zookeeper的源码。这里总结下最近学的一些基本概念吧。
2PC&3PC
首先介绍下最近学的一些博客，后面会结合自己查资料和看书说一下一些理解。
分布式系统理论基础 - 一致性、2PC和3PC这篇博客贼逗，很幽默地介绍了一致性和2PC,3PC的概念和过程，但是对存在的问题描述的不是很清楚。
分布式事务中2PC与3PC的区别 这里比较详细的说明了过程和问题，但是举例中结婚的例子似乎有些问题，因为分布式系统中不同的副本或者模块并不一定会直接对话。
2PC到3PC到Paxos到Raft到ISR连贯性比较强，但是内容都比较简略。
- 2PC其实就是协调者会首先向参与者发送提交事务请求，然后各个参与者执行事务，成功或失败返回不同的相应，然后协调者根据返回响应的区别去决定第二步是向参与者发送commit还是abort。当然，如果发生超时现象和失败同理，参与者如果超过timeout时间没有收到第二步执行事务提交的指令也会rollback。
- 2PC主要有4类问题：
- 同步阻塞：所有参与事务处理的逻辑都处于阻塞状态，就是说参与者在等待其他参与者响应的过程中无法进行其他任何操作。无疑，这里会比较影响性能。
- 单点问题：2PC中协调者作用很大，如果协调者在发送执行事务提交过程中发生故障，那么此时参与者就处于了锁定状态，无法继续完成事务操作。这里可以通过协调者的副本来解决，协调者挂了之后选举新的协调者接管工作，但是参与者可能需要保存自己的状态以便新的协调者来发送命令。
- 这里上面推荐的第二篇博客中对各种问题有比较详细的描述，强烈建议学习一波！
- 非常需要说明的是，在参与者故障恢复的情况下，如果协调者和参与者都挂了，那么某些情况下是无法保证数据一致性的。例如，参与者挂之前进行了实务操作，但是不知道进行的是commit还是rollback。这时候新选的协调者如果根据别的参与者的状态发现它们执行的是commit，那么很自然的我们会认为挂的这个进行的也是commit。但是这是不一定的，因为很有可能命令到这台机器超时或者不可达，那么这台机器便认为自己应该做的是rollback，这样数据就不一致了。当然，我们可以通过节点之间的通信或者中间件的方式来做到使它们一致，但是在协调的这段过程中数据依然是不一致的。
- 数据不一致：这里的数据不一致可能由网络引起，例如协调者给参与者发送commit通知，但是和部分参与者节点不可达，那么这部分不可达节点会rollback，这样数据就不一致了。
- 太过保守：参与者出现故障而导致协调者始终无法获取到所有参与者的相应信息的话，协调者只能依靠自身的超时机制来判断是否需要中断事务，这样的策略比较保守。
- 按照查阅的资料总结来说是因为基础的2PC没有设计完善的容错机制，任意一个节点的失败都会导致整个事务的失败。
- 3PC的过程会稍微复杂一些。首先协调者会咨询参与者是否可以执行事务，参与者根据自身状态来判断回复YES还是NO。这第一步避免了无法执行事务机器强行执行事务带来的阻塞问题。如果都是成功（如果有失败或者超时协调者会发送Abort），然后协调者会向参与者发送执行事务的请求。参与者接收到后执行事务且成功，同时向协调者发送ACK响应。最后如果所有的参与者都发送了ACK响应，协调者会向所有参与者发送commit请求，反之发送abort。特别的是，如果这一步中，参与者没有收到协调者的任何信息，那么仍然会完成事务提交。
- 3PC比2PC好的最重要的地方就在于第三步，即时出现和2PC中前面描述的一样的情况，那么新的协调者判断出其他参与者做的是commit，但是根据3PC的过程我们可以知道，那么所有的都要去做commit。同样的，如果有机器做了rollback，那么所有的都会做rollback。
- 用原博文的描述：看上去和二阶段提交的那种数据不一致的情况的现象是一样的，但仔细分析所有参与者的状态的话就会发现其实并不一样。我们假设挂掉的那台参与者执行的操作是commit。那么其他没挂的操作者的状态应该是什么？他们的状态要么是prepare-commit要么是commit。因为3PC的第三阶段一旦有机器执行了commit，那必然第一阶段大家都是同意commit。所以，这时，新选举出来的协调者一旦发现未挂掉的参与者中有人处于commit状态或者是prepare-commit的话，那就执行commit操作。否则就执行rollback操作。这样挂掉的参与者恢复之后就能和其他机器保持数据一致性了。
