乐趣区

关于zookeeper:zookeeper如何解决高可用

架构

节点角色

leader 节点

写和读。

从节点

1. 只读

2. 选举 leader

观察者节点

1. 只读

2. 不选举 leader


和从节点的区别?

就是不参加选举 leader。其余和从节点一样。

那有什么用呢?那为什么还要一个这种类型的节点呢?

作用在于可读,可读的话,就能够替 leader 节点分担流量。就像从节点一样。

然而,比从节点的长处在于,不参加选举的话,性能就更快。比方,如果 leader 节点挂了,这个时候就要选举——问题就在这里,如果参加选举的节点数量过多,就会导致选举速度变慢。所以,观察者节点的作用,就是分担读的流量,然而不参加选举,从而进步选举 leader 的性能。

leader 节点挂了

如果 leader 节点挂了,会选举,过半节点抉择某个从节点,该从节点就晋升为 leader 节点。

选举期间,集群短暂不可写。

过半节点

选举 leader 节点

如果 leader 节点挂了,会选举,过半节点抉择某个从节点,该从节点就晋升为 leader 节点。

数据一致性

每次写数据到 leader 节点的时候,都会复制数据到其余节点。

而且只有过半节点返回胜利,这次写数据才算胜利。也就是说,每次写数据,都要等过半节点确认胜利,能力返回给客户端。

上文有提到观察者节点的作用,分担读申请,然而不参加选举——这里的数据一致性过半节点确认,观察者节点也不参加,这样的话就缩小了参加确认节点的数量,从而进步写性能。

集群过半节点存活

通信

集群的每个节点之间,都会通信。

因为,

1. 须要把 leader 节点的数据复制到从节点和观察者

从节点和观察者,也要提供读服务。

2. 选举

选举的时候,须要投票。投票就要基于相互通信来实现。

转发写申请

1. 读申请

所有节点类型,都能够解决读数据。

2. 写申请

1)leader 节点

本人解决写数据。

2)非 leader 节点

转发给 leader 节点解决。

退出移动版