zookeeper

标签：单点   通信   不一致   同步数据   状态   发布   原因   可用性   实时   

zookeeper概述：

　　zookeeper是一个开源的分布式协调服务，提供分布式数据一致性解决方案，分布式应用程序可以实现数据发布订阅、负载均衡、命名服务、集群管理分布式锁、分布式队列等功能。

　　数据一致性分为强一致性和最终一致性，强一致性指的如果数据不一致，就不对外提供数据服务，保证用户读取的数据始终是一致的。数据强一致性只需要通过锁机制即可解决，只有当同步完成以后才对外提供服务。而最终一致性要求数据最终同步即可，没有实时性要求。

　　应用场景：维护配置信息、分布式锁服务、集群管理、生成分布式唯一ID

CAP原则：CAP在分布式系统中主要指的是一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）

　　一致性：一致性指的是强一致性

　　可用性：系统提供的服务一直处于可用状态，用户的操作请求在指定的响应时间内响应请求，超出时间范围，认为系统不可用

　　分区容错性：分布式系统在遇到任何网络分区故障的时候，仍需要能够保证对外提供一致性和可用性服务，除非是整个网络都发生故障。

　　在一个分布式系统中不可能同时满足一致性、可用性、分区容错性，最多满足两个，对于分布式互联网应用而言，必须保证P，所以要么满足AP模型、要么满足CP模型

zookeeper 的三种角色 ：

　　为了避免zk的单点问题，zk采用集群方式保证zk高可用
　　leader
　　　　leader负责处理集群的写请求，并发起投票，只有超过半数的节点同意后才会提交该写请求
　　follower
　　　　处理读请求，响应结果。转发写请求到leader，在选举leader过程中参与投票
　　observer
　　　　observer可以理解为没有投票权的follower，主要职责是当整个zk集群读请求负载很高时协助follower处理读请求。

　　　　为什么不增加follower节点呢？原因是增加follower节点会让leader在提出写请求提案时，需要半数以上的follower投票节点同意，这样会增加leader和follower的通信压力，降低写操作效率。

zookeeper 两种模式：

　　恢复模式
　　　　当服务启动或领导崩溃后，zk进入恢复状态，选举leader，leader选出后，将完成leader和其他机器的数据同步，当大多数server完成和leader的同步后，恢复模式结束
　　广播模式
　　　　一旦Leader已经和多数的Follower进行了状态同步后，进入广播模式。进入广播模式后，如果有新加入的服务器，会自动从leader中同步数据。leader在接收客户端请求后，会生成事务提案广播给其他机器，有超过半数以上的follower同意该提议后，再提交事务。

zookeeper

标签：单点   通信   不一致   同步数据   状态   发布   原因   可用性   实时   

原文地址：https://www.cnblogs.com/roadlandscape/p/12973066.html