第六周 CAP-ZK 总结

发布于: 2020 年 07 月 16 日
第六周CAP-ZK总结

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

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

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

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

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

用户头像

吴建中

关注

还未添加个人签名 2018.04.18 加入

还未添加个人简介

评论

发布
暂无评论
第六周CAP-ZK总结