準備
なぜ、この記事を読んで
飼育係は、サービスから広く使われているマスターコピー・ステート・マシンであります
チャビー（Googleのグローバルロックサービス）に触発
Yahooは最初に適用され、以降Mesosで、HBaseのは、広く使われています
Apacheのオープンソースプロジェクト
マスターコピーからケーススタディ
APIは、ユースケースの広い範囲をサポートしています
優れたパフォーマンス
モチベーションの開発飼育係
サービスは、多くのアプリケーションが通信を調整する必要があるクラスタ
例えば、サービスは、各ブロック・ストレージ・サーバのGFSマスターリストを必要とし、マスタは1つのブロックは、プライマリ等であるかを決定します。
アプリケーションは、お互いを見つける必要があります
IPとポートのGFSマスターを知っているのMapReduceアーキテクチャの必要性
優れたパフォーマンス
ラフトアルゴリズムLAB3 3のノードでの比較のために50 MSG /秒〜約ディスクに一度、二度、ディスク書込みメッセージのラウンドトリップを行うことが必要です。SSDの場合、約200 MSG /秒
しかし、飼育係は、クライアントから、21,000程度MSG /秒を処理できる非同期呼び出しメカニズム、メッセージ処理とパイプライン化することができます。
飼育係の選択肢：各フォールトトレラントマスターアプリケーション開発サービスのための
よるDNSはIPアドレスとポートを識別します
フォールトトレラント処理
高性能
飼育係の設計：一般的なコーディネーションサービス
設計課題
APIの設計
マスターフォールトトレランスを作成する方法
良好なパフォーマンスを取得する方法
基本設計
マスタ状態マシン
主はznodesからオブジェクトのコピーであります
クライアントプロセスのZooKeeper APIによってのznodeデータオブジェクト階層によって、パス名をznodes 名前空間の UNIXファイルシステムと同様、組織
znode階層的な名前空間
分层的名称空间是组织数据对象的一种理想方式，因为用户已经习惯了这种抽象，并且可以更好地组织应用程序元数据。
znodes包含应用程序的元数据（配置信息、时间戳、版本号）
znodes的类型：Regular(客户端通过显式创建和删除常规znode来操作它们)，empheral(客户端创建了此类znode，它们要么显式删除它们，要么让系统在创建它们的会话终止时（故意或由于失败）自动将其删除)
为了引用给定的znode，我们使用标准的UNIX符号表示文件系统路径。 例如，我们使用/A/B/C表示 znode C的路径，其中C的父节点为B，B的父节点为A，除empheral节点外，所有节点都可以有子节点
znode命名规则: name + 序列号。 如果n是新的znode，p是父znode，则n的序列值永远不会小于在p下创建的任何其他znode名称中的序列值
ZooKeeper的数据模型本质上是一个具有简单API且只能读取和写入完整数据的文件系统，或者是具有层次结构键的键/值表。 分层名称空间对于为不同应用程序的名称空间分配子树以及设置对这些子树的访问权限很有用。
会话(session)
客户端连接上zookeeper时会初始化会话
会话允许在故障发生时，客户端请求转移到另一个服务（client知道最后完成操作的术语和索引）
会话有时间限制，client必须持续刷新会话（通过心跳检测）
znodes上的操作
create(path, data, flags)
delete(path, version) if znode.version = version, then delete
exists(path, watch)
getData(path, watch)
setData(path, data, version) if znode.version = version, then update
getChildren(path, watch)
sync() 除此操作的其他操作是异步的，每个client的所有操作均按FIFO顺序排序。同步会一直等到之前的所有操作都认可为止
顺序保证
所有写操作都是完全有序的
ZooKeeper会对所有client发起的写操作做全局统一排序
每一个client的操作都是FIFO顺序的。
read操作能够感知到相同客户端的其他写操作
read操作能够感知之前的写操作针对相同的znode
Zookeeper用例：ready znode与配置改变
ZooKeeper中，新的leader可以将某个path指定为ready znode。 其他节点将仅在该znode存在时使用配置。
当leader 重建配置之后，会通知其他副本重建配置，并新建ready znode.
副本为了防止出现不一致，必须在重建配置时，处理完其之前的所有事务。保证所有服务的状态一致。
任何一个副本更新失败，都不能够应用都需要进行重试。
Zookeeper用例：锁
下面的伪代码向我们锁的实现。通过create试图持有锁，如果锁已经被其他的client持有，则通过watch方式监控锁的释放。
acquire lock:
retry:
r = create("app/lock", "", empheral)
if r:
return
else:
getData("app/lock", watch=True)
watch_event:
goto retry
release lock:
delete("app/lock")
由于上面的伪代码可能会出现羊群效应，可以尝试下面的方式
znode下方的children中，序号最低的的是持有锁的
其他在等待的client只watch前一个znode的变化，避免了羊群效应
acquire lock:
n = create("app/lock/request-", "", empheral|sequential)
retry:
requests = getChildren(l, false)
if n is lowest znode in requests:
return
p = "request-%d" % n - 1
if exists(p, watch = True)
goto retry
watch_event:
goto retry
Zookeeper简化程序构建但其不是最终的解决方案
应用程序还有许多需要解决的问题
例如如果我们要在GFS中使用Zookeeper，那么我们还需要
chunks的副本方案
primary失败的协议
…
但是使用了Zookeeper，至少可以使master容错，不会发生网络分区脑裂的问题
Zookeeper实现细节
和lab3相似，具有两层
ZooKeeper 服务层 (K/V 层)
ZAB 层 (Raft 层)
Start() 在底层执行插入操作
随后，ops从每个副本服务器的底层弹出，这些操作按照弹出的顺序提交(commited),在lab3中使用apply channel，在ZAB层中，通过调用abdeliver()
チャレンジ：リピートプロセスのクライアント要求
シーン：プライマリクライアント要求は失敗が返され、受信され、クライアントの再試行
LAB3では、我々は要求を繰り返したが、各クライアントがブロックされている問題を解決するためにマップを使用し、唯一の次の前に完了するのを待つことができます
飼育係では、時間の動作期間は、最後の操作に、冪等であります
課題：効率読み出し動作
操作のほとんどは、彼らが状態を変更しない、読み取り操作しています
あなたはZAB層によって読み出し動作をする必要がありますか？
サーバーのいずれかのコピーは読み取り操作を行うことができますか？
読み取り操作はラフト/ ZAB層を渡された場合、パフォーマンスが低下します
筏/ ZAB層によって何らの読み取り操作は、古いデータを返さない可能性がある場合
飼育係ソリューション：古くなったデータを返すことが許さ
読書は、任意のコピーによって行うことができます
サーバの数が増加するにつれて、スループットの増加を読みます
読むにはそれが見て最後zxidを返します。
しかし、同期読み（）のデータを確保するためにのみとき
読み取り操作がzxidを返します、zxidクライアント部分は、クライアントは、サーバがクライアントの背後で動作するかどうかを理解できるように、書き込み要求に対応し、この読み取り要求のシーケンスが含まれています。
ハートビートとリターンを検出することzxid十分に近いクライアントは状態を比較することで、クライアントとサーバーを確保するために、サーバーに接続するときに、セッションの確立をzxid
概要
調整プロセスの問題を解決するために、分散システムにおけるクライアントへの暴露によって飼育係待ちのないオブジェクト（のznodeオブジェクト）
飼育係FIFOは、クライアントの書き込み操作の動作の均一性と直線性を確保するため
以下、マルチシーンを読み取るための第2の動作あたり何千回もの値を実現何百スループット古いデータを読み出すために動作復帰を可能にすることにより、飼育係
飼育係は、まだ読み取り一貫性を確保するために同期操作を提供します
アプリケーションのさまざまなシナリオのための強力なAPI機能を備えた飼育係、およびには、ヤフーなど、広く多くの企業で使用されるマスタースレーブ固有のフォールトトレランスを提供し、