分散アーキテクチャ
CAPやBASE理論
キャップ定理：
2つだけを満たすことができる3つの基本的な要件の可用性（A：可用性）およびフォールトトレランスのパーティション（パーティション公差P）：分散システムは、同時に一貫（整合C）を満たすことができません。
私たちは、それ以外の場合は問題ではありません、それは分散システムであるため、分散システムのコンポーネントは必然的に異なるノードに展開する必要があります、分散システムのため、パーティション、フォールトトレランスが基本的な要件である、明確にする必要があります分散システム。だから私たちは通常、事業特性に基づいて、Cとの間のバランスを見つける方法で彼らのエネルギーを費やしています。
基本理論：
BASEは、（最終的な一貫性）（利用可能な基本的な）、3つの短いフレーズソフト状態（ソフト状態）基本的には利用可能と最終的に一貫性がある、BASEは、CAPの一貫性と可用性のトレードオフの結果である、核となるアイデアさえできなかった場合はそうすることです強い整合性が、それらの動作特性に応じて、各アプリケーションは、最終的な一貫性のシステムを有効にする適切な方法。
コヒーレンス・プロトコル
- 2 PC
- 3 PC
- Paxosアルゴリズム
知人飼育係
飼育係の紹介
飼育係は、オープンソースで配布さにする（一緒に仕事を複数のマシン）、協調サービスに分散アプリケーションを提供 Apacheプロジェクトを。
ZooKeeperの作業メカニズム
理解するための設計の観点から飼育係モード：に基づいて、観察モードである分散サービス管理フレームワークの設計、誰にでも関心のデータの格納と管理を担当した後、観察者の登録を受け付け、それは飼育係、これらのデータの状態が変化し、一度意志が飼育係に登録されている視聴者に知らせるための責任者は、それに応じて反応します。
例：
登録情報に移動します（作成される一時ノード）サーバーの起動時に、クライアント・サーバは、オンラインの現在のリストを取得し、聞くために登録する、サーバ・ノードをオフラインには、イベント通知サーバーノードをオフラインクライアントは、クライアントが再びサーバーのリストを取得するときそして、リスナーを登録します。
飼育係= +ファイルシステムの通知メカニズム
飼育係の特長
- クラスタからなるリーダー（指導者）、より多くのフォロワー（フォロワー）
- 限り、クラスタノードの半分以上生きているが、飼育係のクラスタは、通常のサービスのことができるようになります。したがって、サーバは、好ましくは、奇数段が設けられています。
- グローバルデータの一貫性：各サーバーに関係なく、サーバーに接続しているのデータを、クライアントと同一のコピーを保持して、データが一致しています。
- 更新要求を注文して、同じクライアントからの更新要求は、彼らが送信された順序で実行されます。
- データ更新アトミック、成功か失敗のどちらかのデータ更新。典型的なトランザクションの原子。
- リアルタイムで特定の時間枠、クライアントが最新のデータを読み取ることができます。
飼育係のデータ構造
全体的な構造のZKデータモデルは、ツリーとして考えることができ、各ノードが呼び出されるのznode。デフォルトのznode記憶の各可能な1MBのデータを、それぞれがのznodeのある介して固有の識別パス
飼育係のシナリオ
zk 提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。
统一命名服务
在分布式环境下，经常需要对应用/服务进行统一命名，便于识别
例如：IP 地址难记，但是域名好记。如下图，将 www.baidu.com 这个域名与旗下的三个 服务器 IP 地址对应起来，当访问 www.baidu.com 的时候自动从三个 IP 地址中选一个进行访问。
统一配置管理
- 分布式环境下，配置文件同步非常常见。
- 一般要求一个集群中，所有节点的配置信息是一致的，比如 Kafka 集群。
- 对配置文件修改后，希望能够快速同步到各个节点上。
- 配置管理可交给 ZooKeeper 实现。
- 可以将配置信息写入 Zookeeper 上的一个 ZNode。
- 各个客户端服务器监听这个 ZNode。
- 一旦 ZNode 中的数据被修改，ZooKeeper 将通知各个客户端服务器。
统一集群管理
- 分布式环境中，实时掌握每个节点的状态是必要的。
- 可根据节点实时状态做出一些调整。
- Zookeeper 可以实现实时监控节点状态变化
- 可以将节点信息写入 Zookeeper 上的一个 ZNode。
- 监听这个 ZNode 可获取它的实时状态变化。
服务上下线
客户端能够实时洞察到服务器上下线的变化。服务端启动时去注册信息（创建的都是临时节点）；客户端获取当前在线服务器列表，并注册监听；当服务器节点下线，服务器节点下线事件通知客户端，客户端重新去获取服务器列表，并注册监听。
软负载均衡
在 Zookeeper 中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求。
Zookeeper 内部原理
选举机制
- 半数机制：集群中半数以上的机器存活，集群可用。所以 Zookeeper 适合安装奇数台服务器
- ZooKeeper 在没有 Master 和 Slave，但是 ZooKeeper 工作时是分为 Leader 和 Follower 的。Leader 只有一个，是通过内部选举机制临时产生的。
例子：
假设有五台服务器组成的 ZooKeeper 集群，他们的 id 从 1-5，同时它们都是刚刚启动的。假设这些服务器依序启动：
- 服务器 1 启动，现在只有它自己一台服务器，它发出去的报文没有任何响应，因此它的选举状态一直是 LOOKING 状态。
- 服务器 2 启动，它与最开始启动的服务器 1 进行通信。这时候 1 自己有自己一票，还投了 id 大的服务器，即 2 一票，2 有自己的一票和 1 的一票，共两票。因此 id 值大的 服务器 2 胜出，但是没有达到超过半数以上的服务器都同意选举它（由于这个例子有 5 台服务器，因此需要3台同意，即拥有 3 票）。所以服务器 1、2 还是继续保持 LOOKING 状态。
- 服务器 3 启动，过程和 2 相同，因此 3 有 三票，2 有 2 票，1 有 1 票，服务器 3 三票超过一半，成功成为 Leader 。
- 服务器 4 ，由于 3 已经是 Leader 因此它只能作为 Follower。
- 服务器 5 也类似，只能作为 Follower。
节点类型
- 持久（Persistent）：客户端和服务器端断开连接后，创建的节点不删除
- 持久化目录节点：客户端与 Zookeeper 断开连接后，该节点依旧存在
- 持久化顺序编号目录节点：客户端与 Zookeeper 断开连接后，该节点依旧存在，只是 Zookeeper 给该节点名称进行顺序编号。
- 短暂（Ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除（服务器上下线）
- 临时目录节点：客户端与 ZooKeeper 断开连接后，该节点被删除。
- 客户端与 ZooKeeper 断开连接后，该节点被删除，只是 ZooKeeper 给该节点名称进行顺序编号。
说明：创建 ZNode 时设置顺序标识，ZNode 名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护。在分布式系统中，顺序号可用被用于为所有的事件进行全局排序，这样客户端可用通过顺序号来推断事件的顺序。
监听器原理
- 监听器原理
- 首先有个 main 线程
- 在 main 线程中启动 Zookeeper 客户端，这时会创建两个线程，一个负责网络连接通信（connect），一个负责监听（listenner）。
- 通过 connect 线程将注册的监听事件发送给 zookeeper。
- 在 zookeeper 的注册监听器列表中将注册的监听事件添加到列表中。
- Zookeeper 监听到由数据或者路径发生变化，就会将这个消息发送给 listenner 线程。
- listenner 线程内部调用了 process（）方法。
- 常用的监听
- 监听节点数据的变化：get path[watch]
- 监听子节点增减的变化：ls path[watch]
写数据流程
- 假设Client 向 Zookeeper 上的 Server 1 写数据，发送一个写请求。
- 如果 Server 1 不是 Leader，那么 Server 1 会把接受到的请求进一步发送给 Leader，因为每个 ZooKeeper 的服务器集群里面有一个 是 Leader，这个 Leader 会将所有写请求广播给各个 Server。各个 Server 写成功后就会通知 Leader
- 当 Leader 收到大多数 Server 数据写成功了，那么就说明数据写成功了，如果有三台服务器，只要有两台写成功了，那么就认为数据写成功了，写成功后，Leader 告诉 Server 1 数据写成功了。
- Server 1 会进一步通知 Client 数据写成功了，这时就会认为整个写操作成功。
自我小结
Zookeeper 是一个采用 ZAB 作为数据一致性协议的分布式数据一致性协调框架。ZooKeeper 可以作为分布式配置管理，集群服务，数据发布/订阅，服务注册/发现，分布式锁等的实现。其内部采用 ZNode 节点维护一系列数据，当数据改变的时候可以通过 watche 机制告诉客户端。当 ZooKeeper 作为分布式消息系统的管理，如 Kafka 的管理时，可以将所有 Kafka 服务器，即所有的 Broker 的信息写入 ZooKeeper 节点中，当加服务器时只要在节点下加入一个临时子节点，服务器宕机或下线时临时子节点将会自动删除。很容易实现服务器的集群管理。不光如此，ZooKeeper也可以用来维护 Topic 主题和 Producer 和Consumer 等的信息。当 ZooKeeper 作为分布式服务框架的注册中心时，可以将服务注册到 ZooKeeper 节点上，每个服务对应一个节点，子节点就是所有提供了该服务的机器的地址。每当有一个服务提供者启动的时候都会网对应的服务节点下创建自己的临时节点，存放自己的地址信息。消费者需要某个服务的时候只需要到对应的服务节点中随便取一个子节点然后使用该服务就行了。监控中心可以很容易的通过现有的节点监控信息。
ZooKeeper 集群中会自动选举一个 Leader 服务器负责事务的操作，其余的 Follower服务器可以处理非事务操作、参与 Leader 服务器的投票等。而 Observer 服务器只能处理非事务的操作，但是不能参与任何投票。
总之，ZooKeeper 常用来维护各种分布式应用的一个状态，使得分布式应用本身无状态，只需要向 ZooKeeper 注册自己的状态，当需要某种状态的时候直接去 ZooKeeper 上取就行了。当自己关注的消息发生变化时，ZooKeeper 会通过 Watche 进行通知，自己再进行对应的处理即可。