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节点处理。