コンテンツを追加するために働く:(）のZooKeeperクラスタ
飼育係は、クラスタデータの一貫性を確保することであるか、分散を調整するための重要なサービスを提供していますか？
概要の①ZAB契約
データの一貫性プロトコルZAB（原子放送を飼育係）---飼育係原子のニュース放送プロトコルは、具体的に飼育係のために設計され、本契約の主な焦点は、データの一貫性にあることに注意し、正確さに関連するデータがない、権威、リアルタイム。
ZAB契約プロセス
（我々は、トランザクション要求を受信フォロワ）リーダーに転送1.すべてのトランザクション 2.Leaderグローバル分布は単調にトランザクションID（番号N Paxosアルゴリズムに類似しているzxidを）増加、放送プロトコルが提案されている 作ら3.Follower処理案をフィードバック（それが唯一の現在の数Nより大きく受け入れを約束され 、放送コミット受け取ったフィードバックの4.leaderの大半は、完全なデータの永続性（と2PC差がある、2PC）は、すべての若いフィードバックの同意を待つことである 5。オリジナルの前方取引のリーダーは、フォロワー偶然にも対応し、クライアントに対応followe
私たちは、あなたが、なぜ我々は効率的にそれを言うか、私たちはすべてのトランザクション要求は今、グローバルに一意のサーバによって調整されなければならないことを知ることができるシーンのあまりを書き、続きを読む飼育係がより適して言った覚えていますリーダー、提案にトランザクションを書き込むためのクライアントの要求にリーダー・サーバは、我々は、原子ブロードキャストプロトコルによってサーバーまでに他のノードにブロードキャスト提案は、その後、zxidで合意、数は確かに最大です。
私たちのzxidがリーダーによって管理されているので、それはまた、前のセクションでの話され、リーダーは常に、そのzxid要求を超えるトランザクションのこの時以来に基づいて、再び最大のzxid自体のリーダーで最大となって、リーダーとなっています刻み、zxid総務以上の新しいは確かに最大になるようにします。その後、事務のシリーズと方法は、処理のリーダーであり、キュー内のリーダーを建設される、キューは、トランザクションにそう戻って、（zxid整然としたキューとFIFOの原則を）発注の役割はジャンプすることはできませんことを保証するために使用されますトランザクションを楽しみに来ていました。だから、これはZABが発注---合意の重要な特徴であるJAVAの高度なアーキテクチャの円を
②リーダーの崩壊での取り組み
リーダーサーバがクラッシュした、または、ネットワークの理由のためにリーダーは、より多くのフォロワーの半分以上、崩壊が回復モードに入りますとの接触を失いました
我々が設定されたクラスタノードの設定に戻す場合は、各ノードの構成時に参照しました
このとき、第2のポートは、クラッシュリカバリモードをするために使用されます
したがって、この時、私たちZAB選挙アルゴリズム契約は満足しなければならない：トランザクションは、トランザクション提案を破棄することはスキップされていながら提案は、指導者に提出されたコミットされていることを確認します
あなたが新たに選出されたリーダーは、すべてのマシンのクラスタ最高zxid取引の提案を持っていることを保証するために、リーダー選挙アルゴリズムを聞かせて場合は、その新たに選出されたリーダーは、すでに提出されたすべての提案を持っている必要があります保証することができ、およびLET場合の数が最も多い業務を持っていますリーダーになるための提案機械、リーダーは、取引提案の提出から省略し、取引案の操作を破棄することができます。
③ZABデータ同期プロトコル
leader选举完成后，需要进行follower和leader的数据同步，当半数的follower完成同步，则可以开始提供服务。
数据同步过程
④ ZAB协议中丢弃事务proposal
zxid=高32位+低32位=leader周期编号+事务proposal编号 复制代码
事务编号zxid是一个64位的数字，低32位是一个简单的单调递增的计数器，针对客户端的每一个事务请求，leader产生新的事务proposal的时候都会对该计数器进行+1的操作，高32位代表了leader周期纪元的编号。
每当选举产生一个新的leader，都会从这个leader服务器上取出其本地日志中最大事务proposal的zxid，并从zxid解析出对应的纪元值，然后对其进行+1操作，之后以此编号作为新的纪元，并将低32位重置为0开始生产新的zxid。
基于此策略，当一个包含了上一个leader周期中尚未提交过的事务proposal的服务器启动加入到集群中，发现此时集群中已经存在leader，将自身以follower角色连接上leader服务器后，leader服务器会根据自身最后被提交的proposal和这个follower的proposal进行比对，发现这个follower中有上一个leader周期的事务proposal后，leader会要求follower进行一个回退操作，回到一个确实被集群过半机器提交的最新的事务proposalJAVA高级架构圈子
⑤ zookeeper的可配置参数
可以从官网上了解zookeeper的可配置参数
zookeeper.apache.org/doc/current…
虽然是全英，但是当大家有需要使用到它们的时候，那英文就自然不成问题了是吧
内容二：zookeeper的典型应用场景
数据发布订阅 命名服务 master选举 集群管理 分布式队列 分布式锁 复制代码
1.分布式队列的应用场景
① 业务解耦
实现应用之间的解耦，这时所有的下游系统都订阅队列，从而获得一份实时完整的数据
解耦的应用非常广泛，比如我们常见的发货系统和订单系统，以前业务串行的时候，发货系统一定要等订单系统生成完对应的订单才会进行发货。这样如果订单系统崩溃，那发货系统也无法正常运作，引入消息队列后，发货系统是正常处理掉发货的请求，再把已发货的消息存入消息队列，等待订单系统去更新并生成订单，但是此时，订单系统就算崩溃掉，我们也不会一直不发货。
② 异步处理
可以看到在此场景中队列被用于实现服务的异步处理，这样做的好处在于我们可以更快地返回结果和减少等待，实现步骤之间的并发，提升了系统的总体性能等
② 流量削峰
2.zk的分布式队列
① 逻辑分析
顺序节点的应用，类似于我们在用zookeeper实现分布式锁的时候如何去处理惊群效应的做法。 且根据队列的特点：FIFO（先进先出），入队时我们创建顺序节点（ps：为什么上面我们是用了顺序节点而不是说是临时顺序节点，是因为我们根本不考虑客户端挂掉的情况）并把元素传入队列，出队时我们取出最小的节点。使用watch机制来监听队列的状态，在队列满时进行阻塞，在队列空时进行写入即可。
入队操作
如上图，我们生产者需要对资源进行访问时，会申请获取一个分布式锁，如果未成功抢占锁，就会进行阻塞，抢到锁的生产者会尝试把任务提交到消息队列，此时又会进行判断，如果队列满了，就监听队列中的消费事件，当有消费队列存在空位时进行入队，未消费时阻塞。入队时它会进行释放锁的操作，唤醒之前抢占锁的请求，并让之后的生产者来获取。
出队操作
出队和入队的机制是十分相似的。
② JDK阻塞队列操作
阻塞队列：BlockingQueue---线程安全的阻塞队列
它以4种形式出现，对于不能立即满足但是在将来某一时刻可能满足的操作，4种形式的处理方式皆不同
1.抛出一个异常 2.返回一个特殊值，true or false 3.在操作可以成功前，无限阻塞当前线程 4.放弃前只在给定的最大时间限制内阻塞 复制代码
我们将会实现这个阻塞队列接口来实现我们的分布式队列
内容三：分布式队列的代码实现
public class ZkDistributeQueue extends AbstractQueue<String> implements BlockingQueue<String> , java.io.Serializable
继承了AbstractQueue，可以省略部分基础实现
① 基本的配置信息及使用到的参数
首先我们需要一个zkClient的客户端，然后queueRootNode是分布式队列的存放元素的位置，指定了一个默认的根目录default_queueRootNode，把队列中的元素存放于/distributeQueue下，写锁节点代表往队列中存放元素，读锁节点代表从队列中去取元素，这个设计简单点来说就是，queueRootNode作为最大的目录，其下有3个子目录，分别是queueWriteLockNode，queueReadLockNode和queueElementNode，其他的就是一些需要使用到的配置信息JAVA高级架构圈子
② 构造器
提供两个构造方法，一个为使用默认参数实现，另外一个是自定义实现
此时在我们分布式锁的构造器中，createPersistent()的参数true是指如果我父目录queueRootNode并没有事先创建完成，这个方法会自动创建出父目录，这样就不怕我们在跑程序之前遗漏掉一些创建文件结构的工作
③キュー初期化情報のinit（）メソッド
優れた読み取りロックを再定義してロックのタスクストレージ・パスを書き、その後zkClientは接続し、タスク要素ディレクトリパラメータ真の役割は、すでに述べたようqueueElementNodeを作成
④PUT（）メソッドのエンキュー操作キュー・エレメントを使用して
checkElement（）メソッドは、我々はのznodeの命名規則についてのいくつかのチェックを定義することができ、簡単なパラメータのチェックですが、通常の状況下では限り、String型のパラメータとして問題ありません
サイズ（）メソッドは、非常に単純である親ディレクトリになることですし、その後zkClientが結果にcountChildren（）メソッドの戻りが来る呼び出します
主subscribeChildChangesによって（）データの変更リスナーの子ノード、サイズ（）<条件が成立したときの容量、それは待ち行列をウェイクアップし、サイズは（）> =容量が、それによってブロッキング実行、キューが充填された決定され
waitForRemove（）の実行の方法は、私たちの待機中のスレッドがウェイクアップした後、再度実行して、置く（e）を再キューをしよう
エンキュー（E）によって行わエンキュー操作は、ステップノードのシーケンスを作成することです
⑤消費者の操作が取ります
レポート：シミュレーションの生産者と消費者
①プロデューサー
シミュレートされた2台のサーバが、2つの同時は、3秒ごとにスリープメッセージキューが乗って置きます
②消費者
結果
①最初の実行プロデューサー
キューが突然いっぱいませんでしたので、この時点では、消費者は、消費しないために、我々は唯一のキューをブロックしていない、注意を払う必要があり、分散ロックもブロックされています。
消費者を起動②
基本的に状態を消費する消費者へのプロデューサー。したがって、分散キューが正常に働いていることを証明します
ファン福祉
技術の上に追加することができますJAVAの高度なアーキテクチャの円 レビューは、アリ、Baiduの内部を、建築家は、Javaプログラマの1--5のために自分の仕事を強化するために、指導を生きるだけでなく、アーキテクチャの学習教材、JVM、手書きspringmvc、分散は、高可用性取得し、高性能、データ構造、springcloud、springboot。