Etcd v3のドキュメントが非常に不足している間、Etcd記事のインターネットの使用は、記事の特定のアーキテクチャの多くの分析が多くのことを説明したが、ありません。自分の強みと弱みやボトルネックのポイントを理解するためにEtcdのアーキテクチャと実装を分析することにより、一方が他方の手で、それは同時に偽避けるために、これらがなぜ知っている知っている、ビジネスにおける正しい使用Etcdを確保することができ、分散システムのアーキテクチャを研究することができますと。最後に、ツールおよび注意事項の一部を囲むEtcd。
オブジェクトの読み込み：分散システムの愛好家を、私たちは、またはプロジェクトにEtcd開発者を使用する予定。
公式の紹介によるとEtcd
Etcdは、共有設定及びサービス発見のための分散、一貫したキー値ストアです
分散、同じキーと値のストアで、主な目的は、コンフィギュレーションおよびサービスディスカバリを共有することです。Etcdが広く、多くの分散システムで使用されてきた、この記事のアーキテクチャと実装には、次の質問に対する答えを焦点：
Etcdは、一貫性を達成する方法です？
Etcdストレージが実現する方法です？
Etcd時計機構が実装されている方法は？
キーメカニズムの有効期限は？達成される方法Etcd
まず、なぜ必要Etcd？
すべての分散システムは、複数のノード間のデータ共有の問題に直面している、そしてこのチームワークが同じ理由で、メンバーは個別に動作しますが、常にWHOなどの必要な情報の一部を、共有する必要がありますすることができますそれは順序に依存協調タスクのメンバーであるどのようなリーダーです。だから、どちらか（例えばElasticsearchなど）の情報を同期させるために信頼性の高い共有ストレージを実現するための独自の分散システム、または信頼性の高い共有ストレージ・サービスに依存している、とEtcdは、そのようなサービスです。
二、Etcdは、どのような能力を提供しますか？
Etcdは、以下の機能が既にこのセクションをスキップすることができますEtcdの読者に精通している提供します。
強い一貫性プロトコルの複数のクラスタのデータEtcdノードことを確実にそこを通って、データ記憶およびアクセスインターフェースを提供します。メタ情報、および共有設定を保存するため。
センシングメカニズムを提供し、クライアントがキーを監視したり、（異なるメカニズムのV2およびV3、今後の記事で参照）キーの一部を変更することができます。監視し、変更のためにプッシュします。
更新を達成するために、クライアントは、定期的にリフレッシュ（v2とv3の実装メカニズムは同じではありません）、キーの有効期限と更新メカニズムを提供します。クラスタの監視とサービス検出のためにサインアップしてください。
提供CAS原子（比較交換）およびCAD（削除コンペアと-）サポート（V2、インタフェースパラメータによって達成がバッチトランザクションによって達成V3）。分散ロックとリーダー選挙のため。
ここで説明されていない、より詳細な使用シナリオは、エンドInfoQの記事でテキストを見ることができます興味を持っています。
三つには、一貫性を達成するためにどのようにEtcd？
契約といえばいかだの話をしなければなりません。しかし、この記事では、いかだ、限られたスペースの分析に専念されていない、興味が映画終わり、元の紙プロトコルアドレスといかだを参照することをお勧めします、詳細に分析することはできません。記事の後ろに見やすい、私は簡単な要約であることをここにいます：
異なるシーン介していかだ（複製ログ、プライマリから選択される）のメカニズムの異なる設計、（相対たPaxos）汎用性を低減しながら、それはまた、複雑さを軽減し、理解し、実現しやすいです。
内蔵ラフト主プロトコルはマスターノードを選択するために、自身の使用のために選択されているが、機構を理解するための主キーから選択されるラフトラフトクロック周期とタイムアウト機構を理解することです。
データの同期は、ログのキー同期機構いかだを理解することであることを理解Etcd。
Etcdは、言語CSPの同時実行モデルをフルに活用のいかだを達成し、ちゃん魔法を行く、詳細をお知りになりたい場合は、そのWALログの下だけの単純な分析ワンステップのソースを、行くことができます。
WALログは、解析されたデータ構造ログ・エントリの後にバイナリ、またはそれ以上です。最初のフィールドタイプ、2つだけは、一方が0正常で表される、請求項1にConfChange（ConfChangeは、新しいノードの追加、等の構成変更の同期Etcd自体を示す）を表します。第2のフィールドは用語で、各用語は、各用語が新しいマスタ変更になり、一次の項のノードを表します。3番目のフィールドはインデックスであり、この数は数変化を表す、厳密かつ秩序増加しています。第4のフィールドは、バイナリデータ、ラフトPB全体下部ストレージ要求対象の構造です。Etcdソースの下のツール/ etcdダンプ・ログ、WALログ・ダンプは、あなたが見ることができるテキストに、プロトコルはいかだを分析することができますがあります。
ラフトプロトコル自体は、マスターノードがローカルストレージを受け取る適用し、同期WALログの一貫性によって達成される、即ち、データ部、アプリケーションデータについてのみ、当該ラフトログ同期状態を、各ノードからのデータを気にしませんバグがローカルに実装格納されている場合は、適切なデータ等をローカルに適用するだけでなく、一貫性のないデータをもたらすことができます。
四、Etcd v2およびv3の
Etcd v2およびv3は、インターフェイスが同じではない、本質的に互いから分離されたデータと同じメモリラフトプロトコルコードの同じセットを共有するために2つの別個のアプリケーションではありません。これは、データ・アクセス・インタフェースを作成するために、元のデータのV3、V2をEtcdのみV2にアクセスするためのインタフェースを使用し、V3インタフェースするEtcd v2のからアップグレードした場合にのみ、V3を介してアクセスすることができることを意味しています。したがって、我々はV2およびV3に合わせて個別に分析しました。
五、有効期限のメカニズムとともにEtcd v2のウォッチ、
Etcd v2は、純粋なメモリの実装ではなく、リアルタイムのデータがディスクに書き込まれ、永続性メカニズムは、ファイルに書き込まれたJSON配列中にストアを統合することは非常に簡単です。データがメモリに簡単なツリー構造です。たとえば、以下のデータは、図Etcdに示す構造に格納されています。
/ノード/ 1 /名前のノード1 /ノード/ 1 / IP 192.168.1.1
グローバルcurrentIndexに保管して、すべての変更、インデックス1がイベントに追加され、各currentIndexにリンクされます。
インターフェース（パラメータ上昇待機パラメータ）は、currentIndex、EventHistroy waitIndexが少ない、と見インデックステーブルとキーイベントのマッチングからの問合せ未満リクエストパラメータwaitIndex、およびwaitIndex場合、データがある場合とき、クライアントは時計を呼び出すと、ダイレクトリターン。履歴テーブルを要求していないか、waitIndexをしていない場合は、WatchHubに配置され、各キーに関連付けられていることはウォッチャーリストになります。変更操作があるとき、イベントがEventHistroy生成されたテーブルに変更し、キー関連ウォッチャに通知します。
ここではいくつかの詳細は、使用に影響を与えています。
EventHistroy 1000の最大の長さの制限があります。あなたのクライアントが長時間停止した後、再度見るとき可能とwaitIndex関連のイベントが解消された場合には、変更は、この場合には失われますされています。
障害物が（チャンネルを見て、それぞれが100バッファ領域を持っている）、Etcdが直接要求の接続を待つためにつながるウォッチャーを、削除があった通知の時計が中断された場合、クライアントが再接続する必要があります。
各ノードEtcdストアは機構タイミングによってクリーンアップするために、有効期限内に格納されています。
したがって、Etcd V2の制限の一部を見ること：
あなたは一貫性のあるライフサイクルがより困難であることを保証したい場合には有効期限は各キー、複数のキーに設定することができます。
時計を1つのキーだけとその子ノード（パラメータ再帰的）、見ることができない複数のを見て。
現在の使用のほとんどは、時計を変更することで、再度取得したデータを得ることにある時計の変更イベントに完全に依存していないので、時計によって完全なデータ同期メカニズム（負け変化の危険性がある）を達成することは困難です。
六、Etcd v3のストレージ、ウォッチ、および有効期限のメカニズム
v3のEtcdと達成するために離れて時計を保存するには、まず次の店舗の実現を分析します。
Etcd V3ストアがオープンソース実装をグーグルgolang Bツリーに基づいて、二つの部分、メモリインデックス、kvindexに分割され、他の部分は、バックエンドストレージです。その設計によると、バックエンドストレージのさまざまなをドッキングすることができ、現在使用中boltdb。boltdbはEtcdトランザクションが実装トランザクションベースboltdbで、スタンドアローンのトランザクション-KVストレージです。キーが復帰あるEtcd boltdbに格納され、値がEtcdマルチバージョン機構を実現するために、次の各バージョンを保存boltdbますあるEtcd自身のキーと値の組み合わせです。
例えば2つの記録etcdctlによって書かれたバルク・インタフェース：
etcdctl TXN <<<「入れキー1 『V1 』キー2を入れて『V2』」
これら二つのレコードのバッチを更新するために、インターフェイスを介して、その後と：
TXN <<< etcdctl 'キー1をPUT "V12" PUTのKEY2 "V22"'
実際にboltdbは、4つのデータを持っています：
REV = {3 0}、キー = KEY1、値= "V1" REV = {3 1}、キー= KEY2、値= "V2" REV = {4 0}、キー= KEY1、値= "V12" REV = 1. 4} {、キー= KEY2、値=「V22」
復帰は、主に二つの部分、第一主REVの一部に加え、各トランザクションに対して1つの、第2の部分サブREV、同じ操作トランザクションを1だけインクリメントされるたびに構成されています。一例として、メインREV 3は、最初の操作であり、第二は4です。もちろん、最初の問題はEtcdコマンドを提供してあなたは、このメカニズムを考えるスペースの問題であり、コンパクトを制御するためのオプションを設定し、引数をサポートしながらすることは、正確にキーの履歴バージョンの数を制御するための操作を置きます。
クエリデータは復帰をパスしなければならない場合、それはboltdbから見ることができ、Etcdディスクストレージを理解しますが、クライアントはEtcdメモリkvindexは、マッピング関係を保存するので、キーで値を照会することがあることで、キーと復帰の前にありますクエリをスピードアップします。
その後、我々は時計のメカニズムの下で達成分析します。時計機構は、固定キーのEtcd V3をサポートするだけでなく、範囲の時計をサポート（アナログ時計のディレクトリ構造に使用されてもよい）、ウォッチャーwatchGroupは、2つを含み、一つはデータ構造が各キーに対応するキーウォッチャーである時計グループウォッチャーは、他の範囲ウォッチャーである、対応するウォッチャによって検索間隔を容易にするために、データ構造区間木（ウェンウェン不慣れなエンドリンクを参照します）。
同時に、各WatchableStoreは2 watcherGroupが含まれている、1は、一つには、現在の背後にあるデータ同期グループのウォッチャーを表す新しい変化を、待っている、データ同期グループの元とウォッチャーが完了した、同期されていないで、同期されています最新の変更は、追いつくためにはまだです。
現在のリビジョンよりも大きいが、グループに同期され、または同期されていないグループに配置されている場合、要求は、改訂要求を比較し、改訂パラメータを運び、現在のリビジョンを格納する場合Etcd時計は、クライアント要求を受信したとき。一方Etcdゴルーチンは、ウォッチャが同期されていない継続的な同期の背景を開始し、その後同期グループに移行します。すなわち、Etcdが（もちろん、これは小型の不在を意味する）、開始時計から1000の歴史的イベントテーブル制限のない問題V2を任意のバージョンをサポートしないV3、そのような機構です。
ネットワークが良くないか、クライアントがもっとゆっくり、閉塞が発生した読めば、クライアントに通知するときはまた、我々は、以前Etcd V2を述べ、それが直接、現在の接続を閉じますが、クライアントが要求を再起動する必要があります。この問題を解決するための特殊なブロックされたプッシュウォッチャーキューを維持し、他のゴルーチン年後に再試行するEtcd V3。
メカニズムを期限切れにEtcd v3はまたリースに設定された有効期限に改良を加えているし、キーリースが関連します。これは、リースID、便利な統一されたセットの有効期限に関連する複数のキーを可能にし、質量リニューアルを実現します。
比較するとEtcd v2では、大きな変化Etcd V3の数：
RPCインターフェイスはgrpc、放棄されたHTTPインターフェースV2を介してインタフェースを提供します。利点は、長い接続が大幅に効率を高めることで、欠点は、長い接続のシナリオを維持するために、以前よりも特に不便を使用して簡単です。
純粋KVに、元のディレクトリ構造を破棄、ユーザはディレクトリプレフィックスマッチングパターンによってシミュレートすることができます。
メモリは、同じメモリがより多くのメモリキーをサポートすることができ、もはや格納された値ではありません。
より安定した時計のメカニズムは、ほぼ完全にデータ監視メカニズムを同期させることによって達成することができます。
バッチ操作とトランザクション機構を提供する、ユーザーは、トランザクションリクエスト（IF条件トランザクションサポートバルク）のメカニズムEtcd V2 CASバッチによって実現されてもよいです。
七、Etcd、飼育係、領事比較
これらの3つの製品は、多くの場合、比較の選択を行うために使用されています。飼育係能力Etcdと非常に類似した一貫性を提供する、一般的なメタ情報格納されている時計の変更通知および配布するためのメカニズムを提供し、中のソフトウェアエコシステムに格納された情報を共有する分散システムとして使用されています場所は、あなたがお互いを置き換えることができ、ほぼ同じです。詳しくは、言語、コヒーレンス・プロトコル、周囲の生態系における最大の違い上の2つの間の差を達成することに加えて。飼育係は、RPC分散システムにインターフェース、Hadoopのプロジェクトからの最初のハッチ、広く使用されている（Hadoopの、Solrの、カフカ、mesos、等）を提供する、Javaで書かれたApacheの、下にあります。アクティブユーザーの数をキャプチャするためのインタフェースやコミュニティの残りの部分を使用して簡単には、新しいクラスタの一部に（例えばkubernetesなど）を使用して取得してEtcdは、比較的新しいcoreos、同社のオープンソース製品です。パフォーマンスのためのV3がバイナリRPCインターフェイスになったが、その使いやすさは依然として飼育係よりも優れています。領事の目標は、より具体的で、Etcdと飼育係が分散ストレージ容量の一貫性を提供し、特定のビジネスシナリオは、このような構成の変更などのサービスの発見、として、達成するために、ユーザが必要になります。KVストレージが付属している間領事は、メインターゲットとしてサービスの検出と構成の変更を配置します。ソフトウェアのエコシステムでは、より抽象コンポーネントの広い範囲が、確かに不十分な需要ながら、特定のビジネス・シナリオを満たすことができます。
八、Etcd周辺ツール
- Confd
Etcdを聞くことによって、分散システム、例えば、直接Etcd発見/コンフィギュレーション・インタラクション・センターとしての理想的なアプリケーションやサービス、サービスの発見や構成変更で。レガシープログラムがたくさんあるが、我々はまだ、サービスの発見と設定は、ほとんどの設定ファイルを変更することで行われています。領事、およびConfdツールがこの目標を達成するために使用されるような構成の変更を実装するためのメカニズムとツールを提供しないように、自分の位置は、一般的なKVストレージであるEtcd。
Etcd時計のメカニズムを聞くことによってConfd変更は、データがローカルストアを所有して同期されます。設定するには、テンプレートコンフィギュレーションファイルを提供しながら、ユーザーは、これらのキー変更に、独自のフォーカスを定義することができます。Confd古いものと新しい設定ファイルは、交換を変更し、ユーザーが提供する再ロード・スクリプトをトリガしている場合は、設定ファイルを生成するために、最新のデータのレンダリングテンプレートの使用上のデータが変更されると、アプリケーションは、コンフィギュレーションをリロードします。
Confd同等物は領事のエージェントと領事・テンプレート機能の一部を実現するために、著者はケルシー・ハイタワーのkubernetesですが、このプロジェクトのために多くの時間を持っている神一見忙しすぎて、長い時間がバージョンをリリースしていないため、我々は心配して使用するので、フォークあなたの更新やメンテナンスのコピー。テンプレートは、いくつかの新機能とmetadバックエンドのサポートを追加します。
- Metad
登録サービスの実装パターンは、一般的に、1つのスケジューリングシステムに代わって登録され、二つのタイプに分けられ、一つは、それ自体が登録されたアプリケーションです。登録したアプリケーションの代わりにケーススケジューリングシステムでは、アプリケーションがクラスタと、自分の設定を見つけ、その後、「私が誰」知っている、と聞かせするメカニズムが必要です開始します。Metadこのようなメカニズムを提供し、クライアントが固定されたインタフェースMetad /自己を要求し、Metadメタ情報によって、それが属するアプリケーションを伝えるには、クライアントとサービスディスカバリの論理構成の変更が簡単になります。
これを達成するためのメタ情報のIPルートへのマッピング関係を保存することでMetad、現在のバックエンドサポートEtcd v3は、シンプルで簡単なHTTP RESTインターフェイスを提供します。これは、ローカルメモリ、プロキシEtcdの同等に同期Etcdデータメカニズムを見ます。だから我々は、シーンEtcd圧力を減らしたいEtcd V3や便利な使用のRPCインターフェイスのプロキシEtcdとして使用するためにそれを置くことができます。
- キークラスタのビルドスクリプトをEtcd
Etcdキー公式ビルドスクリプトのバグそれは、私は、ネットワーク機能のドッキングウィンドウを通じて、一緒にテストや試験のEtcdやすさのローカルクラスタを構築するためのキーを、スクリプトを置きます。キービルドスクリプト
九、Etcd注意事項
- Etcdクラスタ初期化の問題
Etcdserver：できないエラービアV3インタフェースにアクセスするときに、クラスタの初期化を最初に起動したときには、ノードが存在する場合は、起動しない、それがエラーを報告します。これは、クラスタは、クラスタ内のすべてのノードがすべてのノードv3のサポートインタフェースのみV3へのクラスタバージョンを強化することを確認し、追加された場合にのみ、APIバージョン2.3を起動し、デフォルト、互換性の理由のためです。クラスタが初期化されているし、その後ノードをハングアップ、またはクラスタを再起動（クラスタがロードされている近くにリスタート永続的なデータから、APIのバージョン）をシャットダウンした場合、クラスタは最初、この出会いを初期化された場合にのみ、影響を受けません。
- メカニズムEtcdは、読み出し要求
V2定足数= trueの読み出しは、真のパラメータのデフォルト値をCLIを要求することによって、RAFTによって実行されたとき。ラフトを読み取ることにより、V3 -consistency =「L」（デフォルト）、またはローカルデータを読み取ります。制御するWithSerializableオプション：それは開いているかどうかSDKコード。
読み取りケースの一貫、各読み取りは、ネットワークパーティション内のノードの数が少ない場合には、クラスタが一貫した読み取りを提供しないようで、一貫性を確保するために、ラフトプロトコルを取る必要はなく、パフォーマンスの低下。このパラメータを設定しない場合でも、それは地元の店は、そのような一貫性の損失から直接読み込まれます。このパラメータを使用する場合は、アプリケーションシナリオ、一貫性と可用性との間のトレードオフに応じて設定されることに留意されたいです。
- コンパクトなメカニズムをEtcd
Etcdデフォルトでは自動的にコンパクトな、それ以外の場合は、スペースとメモリの浪費につながる、あなたが頻繁に推奨設定を変更した場合、起動パラメータ、またはcompcatコマンドを設定する必要はありません。
テン、脳洞の時間
最後の自動Elasticsearchの記事の後、自分自身のために仕事を配置し、すべてのアイデアは、ソースコード解析のいくつかの発散的思考を高める脳に穴を開けている必要があります。
- 追跡するために、並行コード分析ツールを呼び出し
現在のIDEコード解析コールがコードを読み取るの分析に非常に有用で、達成するために呼び出しチェーンを追跡するために、静的コード分析法により追跡されます。プログラムやCSP俳優モデルをフルに活用がメッセージを呼び出すことによって行われている場合でも、コードを読んで理解するためのメソッド呼び出しの明確なチェーンは、それが困難になりませんがあります。言語やIDEには、このようなメッセージ配送追跡分析をサポートする場合、それは非常に有用です。もちろん、これは私の脳の穴、および実装の複雑さの可能性を考慮していません。
- 一般的な複数のグループいかだライブラリを達成
現在Etcdは、ラフトは、データの複数のノード間の同期を確保実現するが、明らかな問題は、容量の問題を解決することができないノードを展開することです。容量の問題を解決するために、それが唯一の断片化することができるが、どのように断片化されたいかだ同期データ？のみいかだによるデータの同期化を達成するために、各仮想いかだグループの断片の複数のコピーからなる、複数のグループいかだを達成することができます。複数のグループラフトの現在の実装ではTiKVとCockroachdbを有するが、まだ別の共通。あなたが複数のグループいかだのセットを持っている場合は理論的には、永続的なKVの後ろにぶら下がっする分散ストレージKVで、KVは、メモリ分散キャッシュにリンクされ、Luceneの検索エンジンを配布されてハングアップします。もちろん、これは本当に複雑さは小さくはない実現するために、理論だけです。
セブンイレブン、Etcdオープンソース製品のインスピレーション
Etcd飼育係は、文字通り、車輪を再構築されたために状態の場合に敷設され、生態系内の場所を作ってきました。一方で我々はまた、安定性と機能性よりもさらに高い時にはプロジェクトに使用することの重要性とを見ることができる一方で、コミュニティ、通信メカニズムとユーザーからのフィードバックや、より重要に応答の形の変化を見ることができます。新しいアルゴリズムは、新しい言語は、ホイールの機会を再作成することになります。
十二、gitchat交換基Q＆A
- Q：etcd業務用v2が、その後どのような問題をV3に、どのようにスムーズに移行？
：接頭辞を持つ関数のほとんどはV2、V3は、例えば、によって達成することができるが、TXNシミュレーションCASと、それは一般的に問題ではありません、元のディレクトリ構造をシミュレートします。しかし、v2とv3のデータは、互いに分離されているので、移行まで少し問題。まず、ビジネスレイヤパッケージで提案されている、違いはスイッチを介して、その後V2、V3のカプセル化、およびをetcd。
- Qは：達成するためにどのように時計をmetadのですか？
：イベントが時計を返すmetad変更されていませんので時計は、達成することは比較的簡単であるmetadが、最新の研究結果。だから彼らは、グローバルバージョン番号、ダイレクトリターンの最新の結果に等しい未満を見て、クライアントのバージョンを発見した場合にのみ、グローバルバージョン番号を維持metad。
- Q：etcdとZKは、分散構成管理の構成要素です。ウォッチ機能、予備選挙を提供します。始まるユーザーとしてどのように2、のいずれかを選択するには？
両方etcd下でZKほとんどの場合はお互いを置き換えることができ、それは一般的な分散メモリ一貫性KVです。以下のようなものが言語によって選択され、より近く、より身近な二つの間のチームメンバーと、独自開発スタックを選択することをお勧めします選択し、プロジェクトの言語がetcd、ZKを使用してJavaで行く、問題は、ソースコードを見て簡単です。プロジェクトは、新しい彼らに巻き込まれ、それがドッキングウィンドウ/ libkvのように、層libに梱包することができている場合は、両方をサポートし、切り替える必要があります。
- Q：etcdユーレカ、類似点と相違点の領事、並びにそれらのアプリケーションのシナリオだけでなく、選択の原則。実際には、この問題は、これらに共通している、含まZKことができます。
A：選択etcdとZKの前には、両方の位置付けについて話しました普遍的な合意KVストレージで、ユーレカと領事の位置決めは、サービス登録と発見を行うために設計されています。欠点も非常に一般的です前者もちろん、両方の利点は、既存のサービスとの展開と簡単に共有の汎用性の高い、広く使用され、運用・保守であり、各アプリケーションが登録されたサービスメタデータ形式の独自のセットを持っています、互いに多くのトラブルと統合、例えば、共通APIゲートウェイは、メタデータフォーマットの互換性の問題が発生しますになりたいです。また、両方の利点となっています。そして、DNSなど、より具体的な後者の二つの目標、あなたが行うことができますので、いくつかのより高度な機能は、領事、領事・テンプレートツール、ユーレカイベントサブスクリプションフィルタリングメカニズムをサポートしているため。ユーレカ自体はそれが一貫性を犠牲にして言うことです、実現APシステムであり、それはサービスや流通センターで見つかったこのシナリオでは、可用性とフォールトトレラントパーティションは一貫性よりも重要であると考えます。簡単なアプリケーション間の将来的には互いに相互作用登録されたサービス水準を形成することが可能ならば個人的に、私は実際に、そのよう特化したソリューションの後にそれらを楽しみにしています。しかし、デファクトスタンダードを形成するために、クラスタスケジューリングシステムによって、このような標準規格の可能性があります。
後者の二つは、私が記事から分離することができます感情の深さを理解していません。
- Q：地上では、ZKとどのようなそれぞれのピットが踏まれている、クレーターいるetcd。私が取得する方法に落ちましたか？
A：比較ピットの概念が広すぎる、バグの詳細なリストを有効にすることができます。しかし、一般的に、いくつかを持っているピットのほとんどを使用します。
誤用ピットによって引き起こされます。最初ZK、etcdの位置決めを明確に理解し、それが情報クラスタ全体を共有することではなく、保存する際に保存する必要がある必要があります。例えば、誰かが子ノードの多数のデータノードZKで作成し、その後エラーZKその結果、得、それはエラーであろうよりも、バッファは、4メガバイトの限界を有するZK。
ピットの運用と保守の面。etcd良いビルドがコントロールを持っていない後、ZKそのようなサービスは、一般的に、より安定しているが、いくつかのノードが問題、システムを復元するためにノードを追加する場合、それが壊れたクラスタで、その結果、計画や業務経験を持っていないかもしれません。
ネットワーク分割とユーザビリティデザインピット。etcdのZKの全体の場合は、明確にするために、システムを設計するか、ハングアップ、またはネットワークパーティションが存在する場合、ノード・アプリケーションの一部のみ少数etcd / ZK（少数利用できない）に接続することができ、アプリケーションが実行されます。この場合、パフォーマンスの正しい適用は、サービスが適切に機能する必要がありますが、変更をサポートしていない、とそうetcd / ZKクラスタの後に自動的に復元復元します。適切に設計された場合には、いくつかの自動行動が大きなトラブルにもたらす可能性があります。
、小さなピットの上に私は、テキストに記載された方法をステップにしたい原則研究は、これらがなぜ同じ時間を知っている知っている、別の問題が、より実験的なもので、質問のうち予定です。
- Q：いくつかの実験の問題ハードウェア・クラスタ・プロジェクト
当社は、ARMベースの分散型ハードウェア・クラスタの相互接続を実現（参考https://edcashin.wordpress.com/2013/12/29/trying-etcd-on-android-mac-and-raspberry-pi/commentです-page-1 / etcdは、ARM開発ボード上で実行されます）、Etcdは（分散データベースとして使用しますが、Etcd自体は、ハードウェア上で実行されます）、それから行く-rpiohttpsを参照：//github.com/stianeikeland /ゴーRPIOキーと値の同期ハードウェア制御特定のGPIOに基づいてetcd情報を得ます。
質問1：知らEtcdは、他のサービスの発見にサービスを提供することができ、ハードウェア5回Etcdのノードがすでに新しいノードがEtcdハードウェアのインストールであるとき、このシナリオに存在し、Etcdが自分でサービス検出を提供できると仮定Etcdを達成するためのサービスは、自動的に検出し、参加ノード？
質問2：理由は、様々なマルチノードのいかだかどうか、および長い待機時間を同期させることによって生じたハートビートパケットからハードウェアのインストールのサイズの増加、Etcd限度どのくらい、と？
質問3：十分な大きさ、ネットワーク分割のイベント、ハードウェアの数が少ない同期を完了することができないかどうかの間でデータパーティション？
A：このケースでは、私は一つ一つに答え、非常に興味深いです。
etcdクラスタはまた再びetcdクラスタを:)それを見つけるために必要がある場合はetcdサービス・ディスカバリ、サービスを行うために使用。あなた自身etcd正式オファーをetcdクラスタまたはdiscovery.etcd.ioを構築することができます。詳細を参照してください：公式OP-ガイド/クラスタリングをetcd
一つは、スタンドアローンの容量の制約、メモリ、およびディスクである、Etcd機構は、一貫したマルチノードであるため、その限界は二つの部分を有しています。第二に、ネットワークのオーバーヘッドは、各ラフト動作は、より下位のノードのパフォーマンス関与するすべてのノードを必要とします。だから、多くのetcd拡張ノードは、通常、3,5,7,9無意味です。もっと何を感じません。あなたが一貫性を気にしない場合は、読み出し要求が直接データを読み込むコンセンサスプロトコル、ローカル・ノードですることはできませんお勧めします。詳細な説明のテキストノート。
etcdネットワークパーティションは、少数派が利用できない場合は、要求がいかだをサポートしていませんが、不均一のためのサポートは、読み出し要求。
- Q：それは展開に部屋を横切っETCDの2セットを展開することであれば、ルームサービス全体に展開した場合、どのように展開し、設定するには？
：これは、シーン全体の部屋に依存します。それは完全にパブリックネットワークに接続され、無関係の必要性2つの部屋であれば、一般的に？右、サービス間でデータを共有する必要がある2つの無関係なetcd、より適切な個人口座を展開しません。それはエンジンルームの失敗を避けるために、クラスタの2セットを構築し、ネットワークの相互運用性内の二つの部屋、利用可能エリアのAWSの概念に類似している場合しかし、あなたはいつでも切り替えることができます。これは、現在、良い解決策をetcdないアプローチをお勧め3つの部屋が利用できるエリア、3つのノード各部屋、いずれかをハングアップする余地がある場合は、この方法を利用できる領域にわたってetcdクラスタを展開し、ハートビートタイムアウト選挙を調整することですクラスタ全体に影響を与えるが、二つの部屋はもっと厄介ではありません。そこ二つのクラスタ間で同期させる方法はetcdv3ツールのミラーを提供するものであるが、それでも完璧ではないが、それは難しいことではありませんetcd同期ツールの時計機構であると感じています。このメカニズムは、使いやすさに影響を与えることなく、相互に領事のタッチ、マルチデータセンタークラスタデータの同期化を提供します。
少し注意、少し賞賛のような。
興味のある学生のJava技術、アーキテクチャ、テクノロジーは、QQグループ668041364を追加一緒に学び、お互いに議論してください。
少しの知識パートナーが良い（ソースコード、メモ、PPT、学習ビデオ）を開催します持っているグループ内では、受信するグループを追加してください。
上の