4
私は高可用性の非常に大量のショッピングカートアプリケーションを構築しようとしています。アプリケーションは、私がデータベースのためにmysqlの代わりにcassandraを使用することを検討しているほど高いボリュームを持ちます。お支払い情報を保存するためのカッサンドラ
現在、ショッピングカートシステムでは、ほとんどのデータベースアクションは100％整合している必要がありますが、他のものはそうである必要はありません。
100％整合動作の例： 支払い確認の保存。 購入したアイテムのリストを保存します。
お客様の住所を保存する（お支払い時に住所がデータベースに保存されていない場合は、その住所が失われたとみなして再度顧客にお尋ねください） 。 他の同様のもの。
同じ地域（Amazon EC2）でサーバークラスタを実行している場合、すべてのトランザクションを最大限の一貫性のあるトランザクションとして実行するための大きな障害が存在します。 mySQlリレーショナルデータベースと同じ信頼性を提供しますか？我々はここで金融取引を扱っていることを忘れないでください。
私のデータは一般的に「安全」ですか？これは予期せぬ停電、ランダムディスク障害などを完全に意味します。
多くの明確な情報を提供いただき、ありがとうございます。トランザクションの不足を補うには、次のようにします。私は "ロック"と呼ばれるcassandraテーブルを作成します。データベース上でトランザクションを実行したいときは、私が書き込む行を表すuuidをlocksテーブルに追加します。 QUORUMで関心のある行を書き終えたら、私はロックテーブルからuuidsを削除します。独立したクエリがその間に試された場合は、関連するuuidがロックテーブルに存在するかどうかを最初にチェックし、存在する場合は許可されません。それは取引を許可するのでしょうか？非常に遅いもののみ？ –
残念ながら、これは次のような競合状態になりがちです。1.クライアントAはロックテーブルをチェックし、何も見つけません。 2.顧客Aは買物カゴを読み取る。 3.クライアントBがロックテーブルに書き込みます。 4.顧客Bは、買い物カゴおよび総費用を更新する。 5.クライアントBがロックを解除します。 6.クライアントAは総コストを読み取り、これは以前に読み取った買い物カゴと矛盾しています。この問題は、Zookeeper（@sdolgyに記載されている）のような強力な分散プロトコルを使用しなければ解決できません。 –
手順の1つをスキップしたと思います。代わりに、最初の手順は次のようになります。1.クライアントAはロックテーブルをチェックし、何も見つけません。 2.クライアントAは、読み取りまたは書き込みを行う各アイテムにロックを挿入します。 3.顧客Aが買物カゴを読み取る。 3.クライアントBは、ロックテーブルをチェックし、それが関心のあるアイテムのロックを見つけて、それを停止します。 4.クライアントAは操作を終了する。 –