Zookeeper单机配置：
方式一、
<dubbo:registry address="zookeeper://10.20.153.10:2181"/>
方式二、
<dubbo:registry protocol="zookeeper" address="10.20.153.10:2181"/>
Zookeeper集群配置:
方式一、
<dubbo:registry address="zookeeper://10.20.153.10:2181?backup=10.20.153.11:2181,10.20.153.12:2181"/>
方式二、
<dubbo:registry protocol="zookeeper" address="10.20.153.10:2181,10.20.153.11:2181,10.20.153.12/>
集群配置方式一，特别适用于dubbo-admin 和dubbo-monitor
Zookeeper工作原理：
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
Zookeeper集群的工作步骤：
1）每个服务器读取自己的配置文件，将历史数据加载到内存中
2）每一个服务器开始监听其他服务器的请求，并且把自己选举的服务器通知给其他的服务器，多次选举产生一个Leader
3）选举完Leader其实还不算真正的Leader，因为这是Leader还要与集群中的其他服务器同步数据，如果同步失败，则返回到步骤2）；否则Leader选举成功，其他的服务器为follower
4）这时，每个服务器的数据同步完成，客户端可以进行连接。如果是读请求，直接返回数据；如果是写请求，Leader会将写请求以广播的形式发送给其他的服务器，如果有半数以上的服务器写入成功，那么Leader就会通知之前接收客户端请求的服务器给客户端一个响应
Zookeeper选举master的算法有3个：LeaderElection、AuthFastLeaderElection、FastLeaderElection（默认的）
master选举的过程：
当一台机器进入Leader选举时，当前集群可能会处于以下两种状态
· 集群中已经存在Leader：
· 集群中不存在Leader：初始化状态，Leader还没有选举出来；Leader选举出来了，但是Leader宕机了。
已经存在Leader:由于Leader已经选举出来，所以新增的服务器只能是follower
集群中不存在Leader，比如以下情况：
假如有1->5号Zookeeper服务器，他们都会最新启动，没有历史数据，也就是每个服务器上的数据一致，这时，如果5台服务器顺序启动，他们的选举master的过程是这样的
1）1号服务器启动，此时只有它一台服务器，发送出去的选举数据没有响应，所以1号是LOOKING状态
2) 2号服务器启动，2号与1号开始发送彼此的选举数据，由于服务器数据一致，所以id相对大的2号服务器胜出，但是此时还不满足半数以上选举它为Leader，所以1号和2号服务器都是LOOKING状态
3）3号服务器启动，同样由于数据相同，id相对大的3号服务器胜出，而且满足半数以上的选举，所以最终的Leader为3号服务器，1号和2号服务器都是follower
4）此时4号、5号按照顺序启动，但是由于Leader已经选举出来，所以4号、5号只能当小弟，也就是follower
选举状态
LOOKING，竞选状态。
FOLLOWING，随从状态，同步 leader 状态，参与投票。
OBSERVING，观察状态,同步 leader 状态，不参与投票。
LEADING，领导者状态。