zookeeper实现服务注册与发现、分布式锁、配置中心以及集群选举的原理和实践

服务注册与发现：

所谓的服务注册与发现，就是提供服务的服务进行注册，使用服务的服务进行发现。

例如一个应用有两个模块，订单和产品，做成分布式的两个服务，订单需要获取产品中的服务

这个时候，产品服务需要将自身的信息（ip和port）添加到zk中去，这个过程就叫做服务注册。

实现：

首先，一个产品服务在启动的时候，会获取自身的IP地址和服务的port，然后连接zk服务端，在某个特定的目录下，例如/product目录下，创建一个临时有序的节点。

当另一个产品服务启动时，同样在相同目录下创建同名的临时顺序节点。

这样，在zk的/product目录下，就存在了同名的多个节点

这就完成了服务的注册

这个时候，zk中已经具有了注册的服务，接下来就是订单去使用这个服务，就是所谓的服务发现

实现：

首先，订单需要连接zk服务端，在连接成功后，去上面的目录/product下获取到所有节点的值（各个商品服务注册的IP和port），在订单的后台使用相关算法从获得的这些IP和port中挑选出一个，使用rpc去进行连接服务。

这样就完成了，服务的发现。

当其中某一台商品服务挂了的时候，由于创建的是临时节点，此商品服务注册的服务就会自动删除，此时订单服务使用zk的监听机制，能够坚定到该节点的变化，从而将该服务信息从保存的服务列表中删除。

这里总结有两点：

1.使用zk的节点的存储区完成服务的注册与发现

2.使用临时节点能够在注册的商品服务挂了之后将相关节点删除，使用zk的监听机制，从而能够通知到订单服务再次获取服务的列表（IP和port）

分布式锁

首先，先明白为什么要使用分布式锁。

在多线程中，为了保护资源，我们需要使用线程锁保证某个资源不能同时被两个线程修改。

这样的线程锁是基于一个进程的，也就是JVM锁。

但是，在分布式系统中，应用并不是基于同一个JVM的，而是多进程的，这样，JVM锁便不能满足需要了。

此时，就需要分布式锁了。

使用zk实现分布式锁是基于zk的节点同名机制

实现：

当服务都连接在zk中之后，服务需要使用分布式锁时，会尝试去获得锁，获得分布式锁的整个过：

1.该服务尝试去创建一个节点（testFenBuShi）

2.当发现能够创建成功，则返回true，表示成功获得锁，如果不能创建成功，返回false，表示获得锁失败，此时进入等待过程，并且开启监听机制监听这个节点（testFenBuShi）是否被删除

3.当获得分布式锁之后，程序开始执行，一直到程序执行结束，释放分布式锁，需要将创建的节点删除，这个时候能够通知到所有的正在监听这个节点变化的客户端。

4.此刻，所有的客户端开始尝试去获得这把分布式锁，进行一种激烈的抢占式夺掠，这时如果服务的节点过多，就会造成群羊效应。

为了补足上述方案的分布式锁，可以采用如下方法：

首先讲个故事：

小明去超市买东西，可是不巧的是，正好是周末，他买完东西后发现排队的人特别多，而且整个超市只有一个收银员在干活，也就意味着，同一时刻，只能有一个顾客去结账。小明是个急性子，他不想排队了，于是他准备插队去付账，但是当他冲到前面的时候，一个中年人拦住了他："小伙子，你要先排队。"小明不听：“你管不着。”中年人说：“看你的样子应该是个大学生，可是为什么素质如此的差劲，如果超市的每个人都像你一样，那么我们还怎么付账？”就是，就是。”周围人议论纷纷。小明羞愧地排到了后面，其实他也不是素质差，就是没有耐心。

上面的例子中，第一个分布式锁就是不排队，当节点过多时，必然会造成混乱。

下面的分布式锁实现就聪明多了，会进行排序。

创建顺序节点。这时每个服务创建的节点都会有一个排序，它会获得一个序号，每次它都要去查看一下（利用zk的监听机制，注意：这里每个服务监听的不再是公共的节点，而是序号在它之前的节点）它前面序号的节点有没有被删除，如果还存在，就说明还没有排到它去执行任务。

配置中心

在zk的节点中添加值，当zk节点中的值发生变化的时候，各个客户端会监听到节点值的变化，从而将节点中的值更新到本地，进而实现配置中心的功能

 

集群选举

在zk中集群选举其实和上面第一种实现分布式锁的方式一致，集群中的一个客户端在zk中创建节点leader，其他的客户端只能够创建seliver节点

当leader节点的创建者宕机之后，该leader节点会消失，其它集群中的服务器会开始抢占式创建节点leader