zookeeper使用场景

zookeeper 分布式锁

非公平锁
zookeeper中节点一但创建再去创建就会报错 当一个节点下的子节点被修改或者删除了就会通知监听这个节点的客户端 利用这个机制 创建一个节点 当一个线程把节点创建好了 就表示它得到锁了 可以为所欲为 而其它的线程都要等着它把这个节点给删了 只要它一删除其他的节点就会收到监听消息 然后其它的线程重新争抢锁 然后再循环 这样的实现方式叫做非公平锁 这样性能会很差 就比如 有1000个线程 其中有一个拿到了锁 另外999个线程都要等待它然后999个线程抢锁释放锁 想想就很慢

公平锁
请求进来之后直接创建一个临时顺序节点 判断自己是不是 最小的节点 是最小的节点就获取锁 不是就监听它前一个节点 当第一个节点释放了锁它后一个节点会收到第一个节点被删除的监听信息 然后让它 判断自己是不是最小的节点如果是 就获取锁 如果不是就监听它前一个节点 公平锁避免了并发竞争锁 缓解服务端的压力 让每个线程派对加锁

Leader Election

有好几个服务同时往zookeeper放数据 但是数据都是一样的 只要有一个去zookeeper放数据就可以 为了避免这种浪费可以使用Leader Election 它会给我们选出一个客户端去放数据 其实就是加了一个分布式锁 让别的客户端进入阻塞状态

以上使用的curator客户端

http://curator.apache.org/getting-started.html  // curator官网

zookeeper与数据 数据不一致问题

zookeeper也是能当缓存来用 当缓存就会有与数据读写不一致问题

也是使用分布式锁解决 这里使用读写锁（共享锁） 当读的请求就放行 写的请求就阻塞住 而zookeeper的curator客户端给我实现了这种锁公平锁也实现了
读写锁大体流程 当是一个读请求不用管 当遇到写请求 它后面的请求都会阻塞

zookeeper 注册中心

注册中心 顾名思义 就是让众多服务都在zookeeper中进行注册 注册就是把一些服务的信息比如ip、端口等 这样有服务需要这种数据可以直接再zookeeper上面获取 当一个模块需要另一个模块中的数据（ip、端口） 只有两个模块写在配置文件中就可以 但是如果有多个模块互相需要对方的数据 再写道配置文件中就很难维护了 这样我们就可以写到zookeeper中 利用它的节点跟监听机制 当有新服务启动就在被监听的节点下创建一个节点通知它们获取数据

标签：场景,zookeeper,curator,节点,线程,使用,监听,客户端
来源： https://blog.csdn.net/qq_36301061/article/details/118862372