上一章讨论了paxos算法，把paxos推到一个很高的位置。但是，paxos有没有什么问题呢？实际上，paxos还是有其自身的缺点的：
1. 活锁问题。在base-paxos算法中，不存在leader这样的角色，于是存在这样一种情况，即P1提交了一个proposal n1并且通过了prepare阶段；此时P2提交了一个proposal n2(n2>n1)并且也通过了prepare阶段；P1在commit时因为已经通过了n2而被拒绝；于是P1继续提交一个proposal n3并且通过prepare阶段；巧的是此时P2开始commit了，由于n2<n3再次被拒绝……如此循环往复。这种情况被称为活锁。即整个系统都没死，但由于互相请求资源而被互相锁死。为了不发生活锁的情况，最简单的方式当然是缩减proposer到一个，这样就不会发生互相请求锁死的情况，也即退化。事实上很多后来的工业级协议，都是paxos协议的退化或者变种。
2. 复杂度问题。base-paxos协议中还存在这样那样的问题，于是各种变种paxos出现了，比如为了解决活锁问题，出现了multi-paxos；为了解决通信次数较多的问题，出现了fast-paxos；为了尽量减少冲突，出现了epaxos。可以看到，工业级实现需要考虑更多的方面，诸如性能，异常等等。这也是为啥许多分布式的一致性框架并非真正基于paxos来实现的原因。
3. 全序问题。对于paxos算法来说，不能保证两次提交最终的顺序，而zookeeper需要做到这点，可以参考文献1。
For high-performance, it is important that ZooKeeper can handle multiple outstanding state changes requested by the client and that a prefix of operations submitted concurrently are committed according to FIFO order.