問題タブ [cap-theorem]

チャット アプリケーションがあるとします。

クライアントはチャットにメッセージを送信し、その結果、一部のアクターに何らかのコマンドが送信されました。今、私は彼が書いたものをすぐに処理して、このチャットで他のユーザーが利用できるようにしたいので、このコマンドを処理します。同時に、このメッセージをチャット履歴データベースに保存する必要があることを自分自身 (俳優) に伝えたいのですが、今はそうではありません。データベースへの保存は 2 分ごとに行われます。クラッシュが発生した場合でも、とにかくデータベースに永続化できるはずです。

ワークフローは次のようになると思います：

1. ユーザーがメッセージを送信
2. チャット ルーム アクターは、このメッセージでコマンドを受け取りました
3. このメッセージを全員にブロードキャストし、このメッセージをある種のキューに追加して、チャット履歴データベースに保持します
4. 一部の持続コマンドは、2 分間のタイムアウトが経過したときに実行されます。まだ永続化されていないすべての受信チャット メッセージを到着順に収集します。
5. すべてのメッセージでトランザクションを実行し、キューから削除します。
6. 3 以降のどこかでクラッシュが発生し、メッセージが永続化されなかった場合は、再度永続化を試みる必要があります。それらが永続化された場合、二度とそれらを永続化しようとするべきではありません。

Akka でこのようなものを構築するにはどうすればよいですか? どの機能/パターンを使用する必要がありますか?

CAP 定理について私がこれまでに読んだすべてのことによると、可用性、一貫性、分断耐性の 3 つすべてを提供できる分散システムはありません。

現在、Hadoop 2.x では、Hadoop クラスターにあった単一障害点 (単一の名前ノード) を取り除くために構成できる新しい機能が導入されました。これにより、クラスターは可用性が高く、一貫性があり、分断耐性が高くなります。私は正しいですか？または、何か不足していますか？CAP によると、システムが 3 つの機能すべてを提供しようとする場合、レイテンシの代償を払う必要がありますが、新しい機能はこのレイテンシをクラスタに追加しますか? それとも、Hadoop は CAP 定理を破ったのでしょうか?

CAP 定理を正しく理解していれば、可用性とは、ノードがダウンしてもクラスターが動作し続けることを意味します。

多くの人 ( http://blog.nahurst.com/tag/guide ) が RDBMS を CA としてリストしているのを見てきましたが、RBDMS がどのように利用できるのか理解できません。一貫性を維持します。

これに対する私の唯一の答えは、ほとんどの RDBMS は単一ノードであるため、「障害のない」ノードは存在しないということです。しかし、これは専門的なことであり、真の「可用性」ではなく、高可用性ではありません。

ありがとうございました。

CAP 頭字語についての私の理解は次のとおりです。

• 一貫性: すべての読み取りで最新の書き込みが取得されます
• 利用可能: すべてのノードが利用可能です
• 分断耐性: ノード間のネットワーク接続がダウンしても、システムは A と C の約束を守り続けることができます。

私の理解が多かれ少なかれ軌道に乗っていると仮定すると、何かが気になります。

私の知る限り、可用性は次のいずれかの手法で実現されます。

• 負荷分散
• ディザスタ リカバリ システムへのレプリケーション

では、すでにCP であることがわかっているシステムがある場合、これらの手法のいずれかを適用して「完全な CAP にする」ことができないのはなぜでしょうか? ここで重要な何かが欠けていると確信していますが、何がわからないのですか。

CAP 定理の定義によると、分散システムが満たすことができる条件は 2 つだけです。論理的に考えると、DropboxのようなクラウドサービスならC,Pを一度に満たしてくれる気がします。C を使用すると、一方のノードでデータを更新しても、データはすぐに他方のノードに複製されます。

正解は P,A (Partition Tolerance and availability) です。クラウド サービスを同時に P&A にすることはできますか?

これに関する洞察はありますか？ありがとう ：）

図によると: 1. Mongodb の理由は...(CP) 2. CouchDB の理由は..(AP) 3. Rdbms の理由 (CA)

注: RDBMS でパーティション トレランスが問題にならないのはなぜですか?

CAP 定理は、分散システムが 3 つのオプションのうちの 2 つのオプションしか提供できないことを示唆しています:一貫性、可用性、分断 耐性、残りのオプションは他のオプションを提供します。実際、なぜこの3つを一緒に持てないのでしょうか? 例を挙げて説明してください。