| 登録は、サービスの原則を発見しました | -cap保証一貫性の原則 | 登録サービス発見の適時 | 容量 | |
|---|---|---|---|---|
| 飼育係 | クラスタは、フォロワーのためにリーダー他のマシンに分割し、書き込みにできる唯一のリーダーで、そのサービスレジストリ、その後、フォロワーにデータを同期させる、リーダー/フォロワーを読み取ることができています | クラスタ全体が選出されたリーダーになるまで使用できなくなり、その間、クラスタのリーダー、再選挙のリーダー、でハングアップZKとき、CP、すなわち一貫性を確保 | より良い適時、登録またはハングアップし、一般的な第二のクラスは、知覚することができるようになります | ZKは、サービスをオフラインので、他のすべてのサービスインスタンス（消費者）へのインスタントプッシュ通知データの必要性サービスインスタンスの大規模な展開には適していませんので、マシンの何千もの大きすぎるサービスと、ネットワーク帯域幅を引き起こす可能性があります時間の短い期間は、最大使用されています |
| erueka | ピア・ツー・ピアは、クラスタ内の各マシンの状態が同じで、各サービスは、書かれた要求を受信した後、任意のインスタンスサービス登録及びサービス発見の任意のインスタンスにユーレカ、ユーレカクラスタとすることができる、他のすべてに自動的に同期ユーレカの例 | APを確認し、ユーレカはちょうど他の例は、まだサービス検出を提供することができ、他のインスタンスがハングアップして同期するための時間を持っていなかったサービス登録情報を受信しているではなく、最新のデータでは、唯一の最終的な整合性を保証します | デフォルトの設定、サービスの発見と認識される必要性の10秒あるいは数分の下のレベルに | 各ユーレカインスタンスはすべての要求を受け入れなければならないため、大規模なサービスインスタンスをサポートすることも困難ユーリカ |
なぜZK適時良いです
ZKクライアントは、イベントが、あなたが速やかに通知されますが発生した場合など、サブノードを追加するのznode関連のイベントを監視するためのオブジェクトを見て、変更、削除のznode上で作成することができます。
ユーレカマルチレベルキャッシュ、およびポーリングサービス店舗のタイミング更新リストそう、そう、比較的貧しい高齢化
