第六周 CAP-ZK 总结

Zk的定位是分布式协调器，在分布式环境中多个对等的节点构成一个集群，如果这些对等的节点各自为政，必然会出现混乱，尤其存储型的集群，一般都有状态，所以必须有一个管事的节点（主节点）来管理集群的读写。这个主节点是集群的核心，必须重点保护，确保唯一，同时不能出现单点故障，即使出现了单点故障，也能有备用的节点能够快速的接管。



为了提高系统的可用性，比较老的解决方案是使用双机互备（两个节点同时部署数据库和应用，只是某一个时刻只启动一个应用，要么启动数据库，要么启动应用），两个节点使用相同的虚拟Ip，正常情况下从节点不对外提供服务，从节点监听主节点心跳，一旦主节点失效，那么从节点就会接管主节点，由于对外的ip地址没有变化，所以切换过程对客户端是透明的。这种存在很多问题，1.解决方案与操作系统，应用系统耦合程度较高。2.如果超过2个节点，复杂性会提升。3.这种方案只是提高了可用性，没有提高整体并发性能。所以在互联网企业中不可能采取这种方式，就是在传统企业，这种方式也逐渐退出舞台了。



ZK提供了一种耦合性低、独立部署的、通用性强的分布式协调解决方案，可作为企业重要基础设施存在，ZK基于“树形目录+事件通知（订阅发布）”模型，可以用来做配置中心、选主协调，也就是说企业只需要三台机子（至少），就可以搭建协调中心，用来集中解决状态一致性协调问题。



ZK为别的集群选主服务，ZK集群自己也要选主，这两种选主过程集群可能出现短暂的不可用，在CAP模型中，ZK优先选择CP。



CAP，在分布式环境中，为了提高这个集群并发能力、吞吐量、存储量、可用性等质量属性，必然会存在副本，存在多节点复制。多节点要保持数据一致，就必须进行同步，因为网络传输客观存在的，谁也不能确保网络0延时，无法确保网络100%高可用，正因为有这种客观条件和限制，我们无法消灭掉P，那么就要接受P存在的情况下，如何尽可能的提高集群整体的可用性和一致性。数据的一致性和集群可用性是互斥的，这给了我们一种思路，一致性和可用性的互斥是机制上的问题，必须权衡和妥协，找到一个平衡点，不要试图用技术解决理论上行不通的问题。