サービスレジストリとして、ユーレカは、飼育係よりも良かった
有名なCAP理論分散システムは、C（一貫性）、A（可用性）とP（パーティションのフォールトトレランス）を満たすことができないと述べています。分散システム内のパーティションPのフォールトトレランスが保証されなければならないので、私たちは唯一のトレードオフAとCの間にすることができます
だから、
飼育係は、そのCPを確保、
ユーレカはAPです。
4.1飼育係CPを確実
登録センターにするとき追跡リスト、我々は、レジストリを許容することができ、登録情報の前に数分を返されますが、利用できない直接ダウンサービスを受け入れることはできません。これは、一貫性よりも可用性のためのサービスの登録要件です。しかし、ZKは、ネットワークが接触不良を失ったので、残りのノードがリーダー再選されますが、このような状況では、他のノードとマスターノードです。問題は、あまりにも長い選挙のリーダー、30〜120秒、およびクラスタ全体のZKが選挙登録サービス中に麻痺につながっ選挙、中には利用できないということです。クラウド・デプロイメント環境では、ネットワークの問題によりサービスが最終的に回復しますが、原因の長期的な選挙に長い時間を登録しますが、ZKは、マスターノードクラスタが大きい確率が起こるものです失わせ、それが容認されることはありません使用できません。
4.2ユーレカはAP保証
ユーレカはこのことを理解し、その設計は、可用性を確保することを優先させて頂きます。ユーレカ各ノードは、残りのノードはまだ登録と照会サービスを提供することができ、いくつかのノードが正常なノードには影響しませんハング、同じです。ユーレカクライアントユーレカに登録したり、接続が失敗した見つけた場合、それは自動的に限り、ユーレカがまだあるとして、我々は登録サービスは、（可用性を確保するために）利用できる保証することができ、他のノードに切り替わりますときが、情報を見つけましたこれは、（強い一貫性を保証するものではありませ）現在ではないかもしれません。15分・ノードで85％以上が、通常のハートビートでない場合はまた、自己保護メカニズムユーレカがあり、その後、クライアントはユーレカとみなされ、ネットワーク障害の登録センターは、以下が表示されます。状況：
1.ユーレカは、もはや長時間ので削除しないで、リストからハートビート期限切れの登録サービスを受けるべきではない
、まだ2ユーレカ新しいサービスの登録およびクエリ要求を受け付けることができますが、（現在のノードを確保するためにある他のノードに同期されませんまだ利用可能）
ネットワークが安定している場合、新規登録情報の現在のインスタンスが他のノードに同期される3.
したがって、ユーレカは、ウェルコンタクトを失ったいくつかのノードを生じるネットワーク障害のために状況に対処することができるが、飼育係のように全体ではありません登録サービス麻痺。