zookeeper解决分布的问题
主要解决分布式环境下的服务协调问题。
1、防止单点故障
搭集群,满足高性能分担客户端的请求流量,高可用某一个宕机不影响数据和提供服务的可能性。
2、数据一致性-2PC3PC
3、leader选举-ZAB
leaderg挂了如何恢复数据?
2PC:两个阶段。
阶段一:提交事务请求
1.事务询问
协调者向参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待参与者的响应。
2.执行事务
各个参与者节点执行事务操作,并将Undo和Redo信息记录到事务日志中,尽量把提交过程所消耗的时间和准备都提前完成确保后面100%成功提交事务。
3.各个参与者反馈给协调者事务询问的响应
如果参与者成功执行了事务操作,反馈给协调者yes的响应表示事务可以执行。否则不可以执行。类似于投票过程,接下来参与者投票表是否需要继续执行事务提交操作。
阶段二:执行事务提交
协调者根据各参与者的反馈情况决定是否可以进行事务提交操作,正常情况下包含两种可能:执行事务、中断事务。过半执行事务
在zookeeper集群中:
在 zookeeper 中,客户端会随机连接到 zookeeper 集群中 的一个节点,如果是读请求,就直接从当前节点中读取数 据,如果是写请求,那么请求会被转发给 leader 提交事务, 然后 leader 会广播事务,只要有超过半数节点写入成功, 那么写请求就会被提交(类 2PC 事务)
所有事务请求必须由一个全局唯一的服务器来协调处理, 这个服务器就是 Leader 服务器,其他的服务器就是follower。leader 服务器把客户端的失去请求转化成一个事 务 Proposal(提议),并把这个 Proposal 分发给集群中的所有 Follower 服务器。之后 Leader 服务器需要等待所有Follower 服务器的反馈,一旦超过半数的 Follower 服务器 进行了正确的反馈,那么 Leader 就会再次向所有的Follower 服务器发送 Commit 消息,要求各个 follower 节点对前面的一个 Proposal 进行提交;
集群角色
- Leader(Leader服务器是整个zookeeper集群的核心,主要的的工作有两项。)
- 事务请求的唯一调度和处理者,保证集群事务处理的顺序性
- 集群内部各服务器的调度者
- Follower
- 处理客户端非事物请求、转发事物请求给leader服务器2. 参与事物请求 Proposal 的投票(需要半数以上服务器 通过才能通知 leader commit 数据; Leader 发起的提案, 要求 Follower 投票)
- 参与 Leader 选举的投票
- Observer
- 观察者的角色,观察 zookeeper 集群中的最新状态变化并将这些状态变化 同步到 observer 服务器上
- Observer 的工作原理与follower 角色基本一致,而它和 follower 角色唯一的不同 在于 observer 不参与任何形式的投票
- observer服务器只提供非事物请求服务,通常在于不影响集群事物 处理能力的前提下提升集群非事物处理的能力
集群组成
- zookeeper 是由 2n+1 台 server 组成,每个 server 都 知道彼此的存在。
- 如果一台由 6 台服务构成的集群,同样只能挂掉 2 台机器。因此,5 台和 6 台在容灾能力上并没有明显优势,反而增加了网络通信负担。
- 系统启动时,集群中的 server 会选举出一台server 为 Leader,其它的就作为 follower
- 以上说明observer越多反而减少了网络通信的负担。
ZAB协议
选举leader
初始化都为looking