2pc vs 3pc && spanner

2PC的缺点，有很多约束条件，是一个blocking协议。

• 协调者coordinator，参与者cohort都必须是高可用的，不能永久性故障。
  • 这点无可厚非，这会带来工程实现的复杂度，一般是通过数据复制实现高可用，通过paxos来保持副本一致性。
• coordinator、cohort必须把自己的状态持久化存储，重启后可以回放。
  
  • 这点不仅会带来工程实现的复杂度（rdbms的redo log 和undo log的设计，可以写本书了），而且更复杂的是，单机的dbms这会把数据持久化，而锁不需要持久化，只是占用些内存空间。但是2PC，要求把锁的状态也要持久化，这样重启后可以回放。
• 参与者在prepare阶段如果回复成功后，必须锁定本次事务的资源，倘若协调者长期不给自己发送rollback消息，就一直傻等，导致死锁。
• commit阶段如果同时发生coordinator和某个cohort重启，新的coordinator接管之后，可能并不知道第一阶段的结果消息，而重启后，需要再次向所有cohort询问一遍当前的状态，才能进入到下一步，从这个角度上看coordinator也是blocking状态。

3PC的优点

• 3PC是非阻塞协议，每个阶段每个角色都有超时机制判断是否做状态转换。
• 3PC第一个阶段询问所有参与者是否可以进入提交阶段，带来的好处是，如果有一个节点较长时间离线，那么能够在第一时间发现并通知所有参与者放弃本次事务。

3PC的缺点是进入preCommit之后，如果coordinator跟某个cohort发生网络分区，则会导致原子提交失败，部分节点回滚，部分节点提交。

3PC是大名鼎鼎的stonebraker在83年就发表的一片文章，后续还有人对3PC做了优化。关于二者的不同，还有些疑问

1. google spanner是基于2PC+2PL实现的，为什么没有基于3PC实现？
2. 为什么spanner基于2PL的悲观锁，而不是MVCC的乐观锁呢？

        关于1，具体原因论文中并没提到，可能是3PC无法解决网络分区情况下的不一致问题，spanner设计为一个跨数据中心的分布式数据库，网络分区是常事，必须考虑。另外stonebraker支持的voltdb好像也是2PC，也没用3PC，这个就不太清楚为什么了。

        关于2，spanner论文中是这么说的，“ In both Bigtable and Span-ner, we designed for long-lived transactions (for exam-ple, for report generation, which might take on the orderof minutes), which perform poorly under optimistic con-currency control in the presence of conflicts. ”。MVCC是基于乐观锁，也就是还是有锁的，那么夸分片的事务提交前，还是要在不同的节点之间协商锁的状态，而跨节点的通信时延远大于MVCC带来的读操作不阻塞的好处。对于长事务而言，当一个事务提交之前做了很多工作，占用了不少资源，提交之前检查发现有冲突，不得不rollback后重新执行，索性还不如用悲观锁开始处于阻塞状态。spanner确实也实现了某种意义上的分布式事的MVCC，级支持事务是lock free，不过实现也有些瑕疵，并不保证跨分片的数据的版本号都一样，只是保证版本号都是最新的。

参考

https://www.linkedin.com/pulse/main-difference-between-2pc-3pc-protocols-thiensi-le

https://en.wikipedia.org/wiki/Three-phase_commit_protocol

http://static.googleusercontent.com/media/research.google.com/zh-CN//archive/spanner-osdi2012.pdf

Skeen, Dale; Stonebraker, M. (May 1983). "A Formal Model of Crash Recovery in a Distributed System".  IEEE Transactions on Software Engineering .