跨语言，跨平台，跨应用

1、Watcher 的基本流程ZooKeeper 的 Watcher 机制，总的来说可以分为三个过程：(1)客户端注册 Watcher;(2)服务器处理 Watcher;(3)客户端回调 Watcher。客户端注册 watcher 有 3 种方式，getData、exists、getChildren;以如下代码为例来分析整个触发机制的原理。2、基于 zkclient 客户端发起一个数据操作maven 依赖<dependency> <groupId>com

1、Zookeeper 的一致性1.1 Zookeeper 的来源对于 zookeeper 的一致性问题，先从来源层面梳理一遍一致性的问题。zookeeper 的来源，是来自于 google chubby。为了解决在分布式环境下，如何从多个 server 中选举出 master server。那么这多个 server 就需要涉及到一致性问题，这个一致性体现的是多个 server 就 master 这个投票在分布式环境下达成一致性。简单来说就是最终听谁的。但是在网络环境中由于网络的不可靠性，会存在消息

1、分布式锁1.1 分布式锁的基本场景如果在多线程并行情况下去访问某一个共享资源，比如说共享变量，那么势必会造成线程安全问题。那么我们可以用很多种方法来解决，比如 synchronized、 比如 Lock 之类的锁操作来解决线程安全问题，那么在分布式架构下，涉及到多个进程访问某一个共享资源的情况，比如说在电商平台中商品库存问题，在库存只有 10 个的情况下进来 100 个用户，如何能够避免超卖呢?所以这个时候我们需要一些互斥手段来防止彼此之间的干扰。然后在分布式情况下，synchronized 或者

1、zookeeper 的名词1.1 集群角色1.2 数据模型zookeeper 的视图结构和标准的文件系统非常类似，每一个节点称之为 ZNode，是 zookeeper 的最小单元。每个 znode 上都可以保存数据以及挂载子节点。构成一个层次化的树形结构。持久节点(PERSISTENT)创建后会一直存在 zookeeper 服务器上，直到主动删除持久有序节点(PERSISTENT_SEQUENTIAL)每个节点都会为它的一级子节点维护一个顺序临时节点(EPHEMERAL)

1、单体架构到微服务架构的带来的变化单体架构分布式架构假设一个电商的下单场景，完成一笔订单入库，需要做几个操作：创建订单卡券抵扣库存扣减那么在分布式架构下的调用链，可能是下面这种情况。那么服务和服务之间势必会存在远程通信。如上图，一个下单流程就包括，订单服务创建订单，然后通过调用卡券服务进行卡券抵扣，再库存服务进行库存扣减。微服务之间都存在着远程通信。远程通信主要有两种方式，Http 和 RPC。Http 和 RPC 框架的区别虽然现在服务间的调用越来越多地使用了 RP

1、Zookeeper 的产生来源Apache ZooKeeper 是一个高可靠的分布式协调中间件。它是 Google Chubby 的一个开源 实现，那么它主要是解决什么问题的呢？那就得先了解 Google Chubby，Google Chubby 是谷歌的一个用来解决分布式一致性问题的组件，同时，也是粗粒度的分布式锁服务。1.1 分布式一致性问题什么是分布式一致性问题呢？简单来说，就是在一个分布式系统中，有多个节点，每个节点都会提出一个请求，但是在所有节点中只能确定一个请求被通过。而这个通