ローカルの Groupon クローンを想像してみてください。ここで、通常の 10 倍の訪問者を引き付けた取引を想像してみてください。訪問者が同時に取引を購入しようとしていたため、MySQL データベースがダウンし、取引の最大購入制限を超えました。
限られた量の製品の支払いを並行して処理する、負荷の高い Web サイトの支払い処理のベスト プラクティスを探しています。
今のところ、最も簡単なオプションは、顧客がサードパーティの支払い処理業者のページで購入しようとしている間に取引をロック/ロック解除するようです.
何かご意見は？
読み取り/書き込み接続でマスター スレーブ mysql 構成を使用します。
可能な限りキャッシュを使用してください ( redisをお勧めします)。
いくつかのロジックを redis に入れてみてください。これにより、mysql への余分な接続が作成されず、高速になります。
トランザクションの場合、ある種のメッセージ キューイング システム ( rabbitMQ ) を使用するのが賢明かもしれません。一部のタスクをバックグラウンドに転送できます。
データベースまたはキャッシュ エンジンまたは mq が失敗した場合、大きな問題が発生します。しかし、これらすべてのサービスにマスタースレーブを使用すると、一種の安全側になります. つまり、他のマシンに障害が発生した場合でも動作し続けることができる複数のマシンを使用します。
そして、それが次のアイデアにつながります。自動スケーリングを備えたクラウド サービス ( awsなど)。
あなたがサードパーティの支払い処理業者のページについて話し始めるまで、私はあなたと一緒にいました. ユーザーをサードパーティのサイトに誘導する際にユーザー エクスペリエンスを制御するのは困難です。取引、取引を終了した場合など
支払いをローカルで処理できない場合でも、それは必ずしも問題ではありません。トランザクションの処理について実際にどのように考えなければならないかという問題が生じるだけです。
ですから、今はサードパーティのことを考えていないのであれば、それはしばらく脇に置いておきます。明らかに、トランザクションの調整に大きな問題が発生するため、MySQL データベースがダウンしないように回復力があることを #1 確認します。しかし、何かが起こるので、バックアップが必要です。
私の提案は、製品と現在利用可能な製品数を追跡するキャッシュシステムを利用することです. Memcache はこれに適している可能性があります。これは、非常に簡単に取得できる単一のレコードであるためです。製品に関する情報 (可用性) を取得するためにデータベースにアクセスする必要はまったくありません。データベースがダウンした場合、アイテムに関する情報を Memcache から直接取得できるため、ユーザー/アプリケーションは賢明ではありません ( mysql は必要ありません)。
これにより、(データベースがダウンした場合) 支払い記録の保存に問題が生じます。お金を集めるとき、データベースにその取引情報が必要であることは明らかです。データベースがダウンしている場合、それは問題です。Memcache は、値のサイズに制限されており、関心のあるすべてのキーについて知る必要があるため、これに対する優れたソリューションではありません。その上、Memcache にはセットやセット操作がないため、一部のデータを破壊することを恐れずに値を追加することはできません。
では、Redis という別のテクノロジを追加しましょう。
トランザクションの問題の解決策は、MySQL サーバーが使用できない場合にそれらを redis に書き込むことです (または、本当に必要な場合は両方に書き込みますが、実際にはそうする必要はありません)。次に、redis からトランザクションの詳細を取得し、オンラインに戻ったときにそれらを MySQL テーブルに書き込む方法を知っているバックグラウンド プロセスを用意します。Redis はクラッシュに対して非常に回復力があり、大量の操作が可能です。また、セット操作も備えているため、読み取り/変更/書き込み操作中に競合状態を心配することなく、データをセットに簡単に追加できます。
したがって、すべてのトランザクションを単一のセットとして redis キーに保存できます (必要に応じて、json 文字列として保存します。これは非常に簡単です)。その後、DB がクラッシュしたときに、Redis からそのデータを取得して書き込むことができます。オンラインに戻ると、MySQL に送信されます。
物事をシンプルに保つために、redis を使用してトランザクションを保存する場合は、memcache の代わりに製品キャッシュを保存するために使用することもできます - スタックをシンプルに保ちます。
これにより、MySQL がクラッシュした場合に、製品の詳細のためにデータベースにアクセスせず、(潜在的に) 失われたトランザクションを追跡することができます。しかし、MySQL がダウンしている間に新しいトランザクションが発生している間に製品の在庫を追跡し、製品を過剰に販売しないようにするという問題は処理されません。
このケースを処理するには、トランザクションが保存されたときに、利用可能な製品の数を減らすことができます (ページの読み込み時に常に再計算しないように、一定の数のままにしておきます)。これにより、製品が売られすぎているかどうかがすぐにわかります。ただし、これでは「商品がカートに入っている」時間を保護することはできません。ユーザーが商品をカートに入れると (在庫があると言ったので許可しました)、チェックアウトする前に売り切れないようにするという問題があります。
この問題の解決策は、サード パーティのトランザクションの問題に対する解決策にもなります。つまり、製品にはキャッシング メカニズムを使用し、トランザクションにはフォールバック メカニズムを使用しています。ここで行うべきことは、ユーザーが製品を購入しようとしたとき (カートに入れるか、サードパーティのプロセッサに転送されたとき) に、「製品予約」を作成することです。これらのそれぞれに対して redis エントリを作成するのがおそらく最も簡単です。商品の予約に有効期限を設定します。たとえば、5 分または 10 分、場合によっては 15 分です。サイトでユーザーを見かけるたびに、タイムアウトを更新して、時間切れにならないようにします (必要に応じて、これにさらにロジックを追加することもできます)。トランザクションが完了し、保留中から支払い済みに変更されたら、トランザクション レコード (mysql または redis、
次に、有効期限が切れていない予約情報に加えて、利用可能な数量情報を使用して、販売可能な数量を決定します。この数がゼロになった場合は、事実上売り切れです。しかし、一定数のユーザーがコンバージョンに至らない場合は、購入しなかった在庫を解放し、実際に売り切れるまでそのプロセスを洗い流して繰り返すことができます。
これはかなり堅牢なシステムのかなり長い説明であり、MySQL サーバーがクラッシュし、さらに redis がクラッシュする状況に遭遇した場合は、ちょっと困ったことになります。したがって、ここでこれらの両方のシステムのフェイルオーバーを行うことは理にかなっています (これは完全に実現可能であり、可能です)。これにより、非常に堅実なチェックアウト/在庫管理プロセスが実現するはずです。
それが役に立てば幸い。
補償サービス取引を検討していますか？