飼育係について
1.飼育係は何ですか
ZooKeeperのは、分散アプリケーションのための分散、オープンソースのコラボレーションサービスです。
ZooKeeperのの目標は、プリミティブの高効率で信頼性の高いセット、およびユーザーに使いやすいインターフェイスのシリーズを形成するために一緒にサービスパッケージの複雑でエラーが発生しやすい分散型の一貫性を設計することです。
2、飼育係の利用シナリオ
2.1、データはパブリッシュ/サブスクライブ、コンフィギュレーション・センター
1、出版社は、加入者データのサブスクリプションのノード飼育係のデータを公開します。
2は、飼育係がプッシュプルモード、彼らは、サービス側に集中するノードのデータが変更されると、サーバーは、適切なクライアントにウォッチャーのイベント通知をプッシュします必要なクライアント・ノードの登録の組み合わせを使用して、クライアントはこれを受けて通知後、サーバへのイニシアチブは、最新のデータを取得します。
2.2、分散ロック
1とも呼ばれる排他ロック排他ロック
①インターフェースを呼び出すことによって、すべてのクライアント、排他ロックを取得するニーズにロックを取得、中/ exclusive_lockノードの一時的な子ノード/ exclusive_lock /ロックを作成します。1つのクライアントだけが正常に成功クライアントなしで、作成することができ飼育係性を保証は/ exclusive_lockノードのリッスンを登録する必要があります。
②通常のビジネスロジックダウンまたは完全なクライアントは、一時的なノードの削除になりますと、ロックを解除し、ロックが取得され、この時間は、すべての内/ exclusive_lockノードは、クライアントが通知を受信するリスニング登録し、あなたは、分散ロックの獲得を再起動することができます。
2、読み書きロック
①それが書き込み要求である場合、次いで、例えば/ shared_lock / HOST1-R-00000001ノードを作成し、それがリード要求である場合、すべてのクライアントが/ノードの一時的な順序を作成するために、ここでshared_lockされ、共有ロックを取得する必要がロックを取得すると、次いで/例shared_lock / HOST2-W-00000002ノード用に作成。
シーケンシャルリードの分析②
1.ノードを作成した後、すべての子ノード/ shared_lockノードを取得し、ノードは、その登録したリスナーに変更します。
すべての子ノードに自ノード内のシーケンス番号を決定します。2.。
読み取り要求のために3:ノードのその数よりも若いまたは子ノードのその数よりも全て小さいが読み出し要求をしている子がない場合、書き込み要求ならば、それは、彼らが正常に共有ロックを取得し、ロジックを読み始めていることを示しています、あなたは待つ必要があります。書き込み要求の場合:彼は子ノードの最小数ではない場合、我々は待つ必要があります。
ウォッチャ4.通知を受信した後、ステップ1が繰り返されます。
③ロックを解除し、ロック解除プロセスが排他ロックと一致しています。
どのように群れの行動を避けるために、ロックの他の種類を行いますか?
1、排他ロック:
2、読み書きは、それをロック?
2.2.3、マスター、マスター、労働者からのマルチコーディネート
- 一時的なノード/マスターはマスターを表して使用してください。マスターは、マスターの機能を行使する前に、我々は最初のznodeを作成する必要があります。あなたが正常に作成することができた場合は、マスター機能を行使し始めます。
- 一時的なワーカーノード/労働者は、以下のクラスタに参加するために作成することによって、
- マスターは時計のメカニズムによって監視される/労働者の労働者は、労働者のメンバーでリアルタイムに変更を取得するには、以下のリストをノード。
2.2.4、飼育係の使用方法をkafak
図1に示すように、マスタ・ワーカーモード
、これらのシステムの複数の構成カフカブローカクラスタはborkerワーカーです。カフカはcontrolle各トピックおよびブローカに割り当てられたパーティションを担当するシステムマスターであり、コントローラから作業者を選出します。
図2に示すように、トピックの登録
トピックメッセージは、複数のパーティションに分割された分散ブローカ複数のパーティション情報、およびブローカとの対応関係も飼育係に維持されます。
図3に示すように、消費者は、記録された消費者ニュース変位に消費パーティション関係
同じコンシューマ・グループでは、各パーティションが一つだけ、消費者の消費量を有することができ、各メッセージは、一度だけ消費される消費者と消費者との間の仕切りそう関係も飼育係書かれました。
重要な概念の飼育係
データモデル
ZooKeeper 使用文件系统模型,Datatree。Datatree 的每个节点叫作 znode。每个节点都可以保存数据。每个节点都有一个版本 (version)。版本从 0 开始计数。
基于版本号的条件更新
znode节点
- 持久性的 znode (PERSISTENT): ZooKeeper 宕机,或者 client 宕机,这个 znode 一旦创建就不会丢失。
- 临时性的 znode (EPHEMERAL): ZooKeeper 宕机了,或者 client 在指定的 timeout 时间内没有连接 server ,都会被认为丢失。
znode 节点也可以是顺序性的。每一个顺序性的 znode 关联一个唯一的单调递增整数。这个单调递增整 数是 znode 名字的后缀。 - 持久顺序性的 znode(PERSISTENT_SEQUENTIAL): znode 除了具备持久性 znode 的特点之外,znode 的名字具备顺序性。
- 临时顺序性的 znode(EPHEMERAL_SEQUENTIAL): znode 除了具备临时性 znode 的特点之外,znode 的名字具备顺序性。
standalone 模式和 quorum模式
quorum模式要求至少3个节点
其中2181是默认客户端服务端口,3333是quorum之间的通信,3334是用于leader选举的端口。
服务器节点角色与区别
事务日志和快照
zookeeper数据一致性
1、CAP理论下,zookeeper是如何工作的。
2、zookeeper的数据一致性
• 可线性化(Linearizable)写入:先到达 leader 的写请求会被先处理,leader 决定写请求的执 行顺序。
• 客户端FIFO顺序:来自给定客户端的请求按照发送顺序执行。
3、ZAB协议
1、2PC,3PC,Paxos,Raft算法
2、ZAB(ZooKeeper Atomic Broadcast)协议
- リーダーの提案は、クラスタ内のすべてのノードに送信されました。
- ディスクオフノードの提案、提案を受信した後、リーダーへACKを送信します。
- リーダーACKのマジョリティノードを受信した後、クラスタ内のすべてのノードに送信されるCOMMIT。
リーダー選挙
SID(サーバーID)、zxid(トランザクションID)、エポック(リーダーサイクル):1、情報が投票投票が含まれてい
2、投票プロセス
開始するには選挙投票のすべてのノードへのZooKeeperノードを送信することにより
、新たな投票を受け付け発見された場合の投票を受け取った後のノードを、最新の世論調査の投票、投票とZooKeeperのノードのすべてに送信する彼自身の更新を行いました。そうでなければ、何もしません。
投票が新しい場合どのように伝えるには?
リーダーの3ノードクラスタ選挙タイミング図:
3、スプリットブレイン - 2人の選出されたリーダーで長いメッセージの伝送遅延結果