バックグラウンド：
地理的に離れた3つのデータセンターにまたがるCassandraクラスターを作成しています。各データセンターに2つのCassandraノードを配置する予定です（2ノードx3サイト=合計6ノード）。6つのノードすべてが同じクラスターの一部になります。
アイデアは、クラスター内の任意のノードにデータを書き込み、他のノードからデータを読み取ることができるようにすることです。[更新の1秒の遅延を許容できます]。
質問：
「クラスター」に書き込むクライアントをどのように設計しますか。Cassandraには、MongoDBのようなルーターや中間層はありません。リング内の任意のノードに書き込むように設計していますか？その場合、そのノードは何がダウンしていますか（つまり、クライアントにクラスター内のすべてのノードIPを認識させる必要がありますか？）
ありがとうございました。
クラスター内の任意のノードから読み取りまたは書き込みを行うことができます。これらのノードはすべて、要求を正しいノードにルーティングできます（ルーティングを実行するノードは通常、操作の「コーディネーター」と呼ばれます）。すべてのローカルノードがダウンしている場合にのみ、リモートデータセンターのノードを使用して、ローカルデータセンターのすべてのノードでリクエストのバランスをとるようにしてください。ほとんどのCassandraクライアントは、ポイントするすべてのノードにラウンドロビン方式でリクエストを分散します。Canausaが言及しているように、他のノードを自動検出し、リクエストの送信先ノードを選択するために、より高度なアルゴリズムを使用する場合もあります。
任意のデータセンターへの書き込みは他のすべてのデータセンターに自動的に複製されるため、実際に任意のノードに書き込み、任意のノードから読み取ることができます。通常、読み取りと書き込みには整合性レベルLOCAL_QUORUMを使用する必要があります。これには、操作が成功したと見なされるために、ローカルデータセンター内のレプリカのクォーラムが応答する必要があります。また、各データセンターのレプリカのクォーラムからの応答を待機するEACH_QUORUMでの書き込みを検討することもできます。明らかに、この場合、レイテンシーははるかに高くなりますが、すべてのデータセンターで強力な一貫性を実現できます。
ただし、各データセンターにノードが2つしかない場合、レプリカのクォーラムはすべてのレプリカに相当するため、いずれかのノードがダウンすると、データのその部分の可用性が失われます。このため、クォーラム整合性レベルを使用する場合は、各データセンターで少なくとも3のレプリケーション係数を設定し、強力な（またはローカルで強力な）整合性を維持しながら1つのレプリカが失われるようにすることをお勧めします。
ほとんどの Cassandra クライアントは 1 つのノードへの接続を試行し、失敗した場合はリスト内の次のノードを試行します。接続を確立してクラスターのレイアウトを把握し、接続する適切なノードを選択する人もいます。Hector のようなクライアントは、より多くの情報を要求する必要がある場合に備えて、特定のノードへの接続を開いたままにします。これにより、高価なセットアップを回避できます。
どの Cassandra クライアントでも、クラスター内の任意のノードにリクエストを送信できます。そのノードは、それ自体と他のノードの両方からの結果をルーティングして統合します。
このシナリオでは、データ センターごとに 1 つずつ、各ノードがデータの半分を分割し、読み取りと書き込みの両方に QUORUM を使用する、3 のレプリケーション ファクターを考慮することができます。各書き込みが各データ センター (A1、A2、A3、B1、B2、B3 など) から 1 つのノードを更新するように、レプリカ配置戦略を構成します。このようにして、各データセンターはすべてのデータを自由に使用でき、読み取りまたは書き込み要求は、自身のデータセンターに加えて最初に応答したデータセンターから応答を受信するとすぐに制御を返します。
クライアントにすべてのノードを認識させる必要はありませんが、単一障害点を防ぐために、少なくとも 2 つのノードを認識する必要があります。各データセンターから少なくとも 1 つを使用します。