転送：コード農業スタンド（マイクロ・シグナル：coderising）
同社は近年、非常によく発達した張タイパン、ビジネスの急増は、人員も急速に拡大するには、インスタントは、張大きな脂肪は、同社の「先輩」のスタッフとなっており、より重要なのは、不断の努力の年後、彼は最後に彼は王位の建築家を得ました。
大きな脂肪はすぐに、特に他のすべての建築家、技術選択、アーキテクチャ設計は、技術的な問題が失敗したときに、これは本当に良いではないことがわかった。しかし、最終的に自分自身を運ぶために持っていました。コミュニケーション、説得、妥協、とさえ争いが一般的であり、単に開発時間をやってすることははるかに困難自身以前よりあります。
企業のITシステムは、すでにスタンドアロンから配布なっていた、分散システムは、大きな課題をもたらしました。この作品Zhouyiギャングは、張大きな脂肪のメールボックスは、緊急メッセージを詰めてきました。
1、小柱メール
小柱メールは、RPC呼び出しの問題は、会社の元の構造は、RPCフレームワークのセットは、各グループが使用することができます開発していると言いますが、各開発チームは不満が：RPCフレームワークは動的登録およびサービスディスカバリをサポートしていません。
張タイパンそれが起こるかを理解するには、このチャートを見ては、高並行性をサポートするために、OrderServiceのは4を配備し、各クライアントは、サービスプロバイダのリストを維持しますが、このリストは静的です（設定ファイル内死を書かれた）、サービスプロバイダがダウンして、例えば、いくつかのマシンを変更した場合、またはOrderServiceの例を追加したクライアントは知りませんでした、まだ、これらのインスタンスがすでにそれを壊れしようとする愚かなことかもしれません！
URLは、サービスプロバイダの最新リストを取得したい、あなたは本当に不便、手動でジョブの設定ファイルを更新する必要があります。
このような問題のために、大きな脂肪はすぐにこれが緊密に結合されたクライアントおよびサービスプロバイダーのああであることを認識しています。
カップリングを解放したい、中間層が増加することはできません！
張タイパンだけのOrderServiceの名を与え、ここでそれを登録することができ、クライアントがここに照会し、それらのOrderServiceのに続いて、レジストリ、（たとえばOrderServiceのための）これらのサービスの最初の名前、そこにあるべきだと思う、レジストリを与えることができますサービスプロバイダの動的変化のもはや恐れる使用できるURL、。
潜在意識の行動を知ってはいけない、レジストリの張大きな脂肪のデータ構造は、ツリー構造になるように設計されて：
サービスの概念を発現/ OrderServiceの、次のノードのそれぞれは、サービスのインスタンスを表しています。例えば/ OrderServiceの第二のインスタンス/ NODE2は、注文サービスを表し、クエリできるように、この例では、各ノードのURLを記録してもよいです。
サービスインスタンスがダウンしている場合はもちろん、このレジストリは、ツリー構造内のノードのためのものであることを、残念ながら、通信できるようにする必要があり、各サービスインスタンスクライアントが見つけることができないように、また、削除する必要があります。
ああ、あなたは、各サービスインスタンスは、定期的にハートビートを送信するように一定の時間がない、ハートビートの後に、それはサービスインスタンスがハングアップ考える場合、セッションの有効期限が切れて、、、レジストリおよび各種のサービス・インスタンスを直接セッションで作成した木からそれを取ることができます構造を削除します。
張タイパンは、小柱を答え、その後、エイミーの電子メールを見て自分の考えを置きます。
2、マスター王の選挙
王は、メッセージが、3つのバッチジョブは、3台のマシンに配備問題3バッチジョブを調整することであると言ったが、これら三つのバッチジョブと同じ時間だけ実行すると、1つがダウンした場合、残念ながら、残りの二つの選挙が必要になります、バッチジョブを選出は、「強い要請を継承」する必要がある作業を続けます。
実際には、これは選挙のマスター、一目自然に張大きな脂肪です。
ただ、マスターを選出し、3つのバッチジョブは、困っている仕事のための交流、相互の調整が必要！
またはデータベーステーブルを手に入れますか？データベーステーブルの主キーを使用することはありません、競合特性は、なるように3つのすべてのバッチジョブはマスターが誰で成功するはず同じテーブルに同じデータを挿入することができます！
しかし、それグラブマスターバッチジョブハングあれば、他の人がそれをつかむませんん！レコードがすでに存在しているので、他のバッチジョブにデータを挿入することはできません！
ああ、定期的に更新する仕組みを追加する必要があり、マスターが死んだと思うためにいくつかの時間のために更新されていない場合は、他のバッチジョブはそうつかむ.....しかし、トラブルを続けることができます！
换个思路，让他们也去一个注册中心去大吼一声：“我是master!”， 谁的声音大谁是Master 。
其实不是吼一声，三个Batch Job启动以后，都去注册中心争抢着去创建一个树的节点（例如/master ），谁创建成功谁就是Master （当然注册中心必须保证只能创建成功一次，其他请求就失败了），其他两个Batch Job就对这个节点虎视眈眈地监控，如果这个节点被删除，就开始新一轮争抢，去创建那个/master节点。
什么时候节点会被删除呢？ 对，就是当前Master的机器down掉了 ！ 很明显，注册中心也需要和各个机器通信，看看他们是否活着。
等等，这里还有一个复杂的情况， 如果机器1并没有死掉，只是和注册中心长时间连接不上，注册中心会发现Session超时，会把机器1创建的/master删除。 让机器2和机器3去抢，如果机器3成为了master, 开始运行Batch Job, 但是机器1并不知道自己被解除了Master的职务， 还在努力的运行Batch Job，这就冲突了！
看来机器1必须得能感知到和注册中心的连接断开了，需要停止Batch Job才行，等到和注册中心再次连接上以后，才知道自己已经不是master了，老老实实地等下一次机会吧。
无论哪种方案，实现起来都很麻烦，这该死的分布式！
先把思路给小王回复一下吧。接着看小蔡的邮件。
3、小蔡的分布式锁
小蔡的邮件里说的问题更加麻烦，有多个不同的系统（当然是分布在不同的机器上！），要对同一个资源操作。
这要是在一个机器上，使用某个语言内置的锁就可以搞定，例如Java的synchronized ， 但是现在是分布式啊，程序都跑在不同机器的不同进程中， synchcronized一点用都没有了！
这是个分布式锁的问题啊！
能不能考虑下Master选举问题中的方式，让大家去抢？ 谁能抢先在注册中心创建一个/distribute_lock的节点就表示抢到这个锁了，然后读写资源，读写完以后就把/distribute_lock节点删除，大家再来抢。
可是这样的话某个系统可能会多次抢到，不太公平。
如果让这些系统在注册中心的/distribute_lock下都创建子节点， 然后给每个系统一个编号，会是这个样子：
然后各个系统去检查自己的编号，谁的编号小就认为谁持有了锁， 例如系统1。
系统1持有了锁，就可以对共享资源进行操作了， 操作完成以后process_01这个节点删除， 再创建一个新的节点（编号变成process_04了）：
其他系统一看，编号为01的删除了，再看看谁是最小的吧，是process_02，那就认为系统2持有了锁，可以对共享资源操作了。 操作完成以后也要把process_02节点删除，创建新的节点。这时候process_03就是最小的了，可以持有锁了。
这样循环往复下去...... 分布式锁就可以实现了！
看看，我设计的这个集中式的树形结构很不错吧，能解决各种各样的问题！ 张大胖不由得意起来。
好，先把这个想法告诉小蔡，实现细节下午开个会讨论。
4、Zookeeper
正准备回复小蔡的时候，大胖突然意识到，自己漏了一个重要的点，那就是注册中心的高可用性，如果注册中心只有那么一台机器，一旦挂掉，整个系统就玩完了。
这个注册中心也得有多台机器来保证高可用性，那个自己颇为得意的树形结构也需要在多个机器之间同步啊，要是有机器挂掉怎么办？ 通信超时怎么办？ 树形结构的数据怎么在各个机器之间保证强一致性？
小王、小梁、小蔡的原始问题没有解决，单单是这个注册中心就要了命了。 以自己公司的技术实力，搞出一套这样的注册中心简直是Mission Impossible !
大胖赶紧上网搜索，看看有没有类似的解决方案，让大胖感到万分幸运的是，果然有一个，叫做Zookeeper ！
Zookeeper 所使用的树形结构和自己想象的非常类似，更重要的是，人家实现了树形结构数据在多台机器之间的可靠复制，达到了数据在多台机器之间的一致性。并且这多台机器中如果有部分挂掉了/或者由于网络原因无法连接上了， 整个系统还可以工作。
大胖赶快去看Zookeeper的关键概念和API：
-
Session ： 表示某个客户系统（例如Batch Job）和ZooKeeper之间的连接会话, Batch Job连上ZooKeeper以后会周期性地发送心跳信息， 如果Zookeepr在特定时间内收不到心跳，就会认为这个Batch Job已经死掉了, Session 就会结束。
-
znode : 树形结构中的每个节点叫做znode， 按类型可以分为永久的znode（除非主动删除，否则一直存在），临时的znode（Session结束就会删除）和 顺序znode（就是小蔡的分布式锁中的process_01,process_02…）。
-
Watch ： 某个客户系统（例如Batch Job）可以监控znode， znode节点的变化（删除，修改数据等）都可以通知Batch Job， 这样Batch Job可以采取相应的动作，例如争抢着去创建节点。
嗯，这些概念和接口应该可以满足我们的要求了， 就是它了，下午召集大家开会开始学习Zookeeper吧。
后记：本文从使用者的角度描述了Zookeeper有什么用处，至于它内部是如何工作，那是另外一个Big topic了，我们以后再讲。