在ZooKeeper的选举中，如果过半的节点都选一个节点为leader的话，那么这个节点就会是leader节点，也就是因为这个原因，ZooKeeper集群，只要有过半的节点是存活的，那么这个ZooKeeper就可以正常的提供服务。比如有5个ZooKeeper节点，其中有2个节点宕机了，这个时候还有3个节点存活，存活个数超过半数，此时集群还是正常提供服务，所以ZooKeeper集群本身是没有高可用问题的。又因为存活的判断依据是超过半数，所以我们一般搭建ZooKeeper集群的时候，都使用奇数台，这样会比较节约机器，比如我们安装一个6台的ZooKeeper集群，如果宕机了3台就会导致集群不可用，因为这个时候存活的节点数没有超过半数了，所以6台和5台的效果是一样的，我们用5台比较合适。
对应一个ZooKeeper集群，我们可能有多个客户端，客户端能任意连接其中一台ZooKeeper节点，但是所有的客户端都只能往leader节点上面去写数据，所有的客户端能从所有的节点上面读取数据。如果有客户端连接的是follower节点，然后往follower上发送了写数据的请求，这个时候follower就会把这个写请求转发给leader节点处理。leader接受到写请求就会往其他节点（包括自己）同步数据，如果过半的节点接受到消息后发送回来ack消息，那么leader节点就对这条消息进行commit，commit后该消息就对用户可见了。因为需要过半的节点发送ack后，leader才对消息进行commit，这个时候会有一个问题，如果集群越大，那么等待过半节点发送回来ack消息这个过程就需要越久，也就是说节点越多虽然会增加集群的读性能，但是会影响到集群的写性能，所以我们一般建议ZooKeeper的集群规模在3到5个节点左右。为了解决这个问题，后来的ZooKeeper中增加了一个observer 的角色，这个节点不参与投票，只是负责同步数据。比如我们leader写数据需要过半的节点发送ack响应，这个observer节点是不参与过半的数量统计的。它只是负责从leader同步数据，然后提供给客户端读取，所以引入这个角色目的就是为了增加集群读的性能，然后不影响集群的写性能。用户搭建集群的时候可以自己设置该角色。
来源：oschina
链接：https://my.oschina.net/u/4427158/blog/3218042