電子商取引システムの注文機能のための MySQL アーキテクチャ設計

単純な注文ビジネスの基本モデルは、ユーザー、商品 (在庫)、注文、支払いを含むように設計されています。ここでは商品と注文のみを考慮します。このプロセスは、注文 -> 在庫の削減です。同時に、在庫を減らさずに注文することはできません (売られすぎ)、注文を生成せずに在庫を減らすこともできます (売られすぎ)。過剰販売業者は在庫が不足しており、消費者は注文時に商品を購入できないため、エクスペリエンスが悪くなります。一方、販売過小業者は在庫が過剰になったり、商品情報を何度も修正する必要があり、面倒でエクスペリエンスも良くありません。

システムの初期の頃は、受信するトラフィックは少なく、多くの起業家チームは単一リポジトリ モデルを採用していました (そうです、全員が一緒でした...)。このモデルは、データベースをまたぐ必要はなく、ましてやノードをまたぐ必要もなく、データベースが提供するトランザクションを使用して注文や在庫削減などのアトミックな操作を簡単に実行でき、さまざまな結合テーブルやサブクエリも実行できます。操作 (MM のニーズがどれほど異常であっても、SQL を知らなかったらどうすればよいでしょうか?)しかし、まさにこれらの利点こそが、トラフィックが増加した後にシステムを拡張する際の障害となるでしょう。結合テーブル、サブクエリ、およびトランザクションはすべて複数のテーブルをバインドするため、データベースとテーブルを解体するのが面倒になります。

後期には、システムトラフィックが徐々に増加し、単一のデータベースの読み取りおよび書き込みパフォーマンスが十分ではなくなるため、データベースを解体してテーブルに分割することを検討します。たとえば、製品と注文は 2 つのクラスターに分割され、クラスターはそれぞれのビジネス ディメンションに従ってデータベースとテーブルに分割されます。製品は販売者のディメンションに従って分割され、注文は通常、購入者のディメンションに従って分割されます。冗長性は販売者の寸法に従って作成されます。この時点で発生する問題は依然として古典的な問題です。データが分割された後、商品と注文が同じデータベース内に存在しない場合、購入者ディメンション内の注文データ間の一貫性を確保する方法です。そして販売者ディメンションの注文データ。解決策は 2 つあります:

(1) 分散トランザクション。古典的な実装は 2PC に基づいています。利点は、十分にパッケージ化された後、それを使用する場合と単一のライブラリ (主に複雑なクエリ ステートメント) を使用する場合とでは違いはありますが、全体としてビジネスへの変化はそれほど大きくないことです。欠点は、パフォーマンスが低すぎることです。分散データベースの導入は、主にパフォーマンスを飛躍的に向上させることを目的としていましたが、分散トランザクションの導入により、多くの場合、このパフォーマンスの向上は許容できないほど大幅に低下しました。

(2) この記事の主人公であるメッセージ ミドルウェア。メッセージ ミドルウェアの機能の 1 つは、さまざまなシステム間の通信を担当することです。これは、ここでの商品と注文システムの同期問題に非常に適しています。メッセージ ミドルウェア導入後の注文プロセスは次のとおりです。ユーザー A が注文を行うと、製品システムが注文メッセージをサブスクライブし、対応する在庫を差し引きます。

ここでいくつかの注意点があります:

a. 注文前に在庫を確認してください。ただし、同時並行の状況では、実際に在庫が減少する場合があります。これは、注文が成功したことを示すために実行する必要があります。つまり、注文後、注文はマークされますが、製品システムが在庫を正常に削減した後は、ステータスはユーザーには表示されません。 、注文システムはステータスを更新するように通知されます (これは依然としてメッセージミドルウェアの使用です)。メッセージを送信するとき、正常に返された場合は、メッセージの信頼性が非常に高いことを確認する必要があります。メッセージが配信されない場合、注文ビジネスは独自にロールバックする必要があります

c. メッセージの信頼性が高いということは、製品システム自体が冪等である必要があることを意味します。メッセージ ID を使用して重複を削除します。そうしないと、販売数が減ります

d. フロントエンド ユーザーは、注文が正常に行われた場合にできるだけ早く通知されることを希望するため、注文が正常に完了した後にタイマーを設定する必要があります。メッセージが表示され、一定期間経過しても注文の在庫が正常に差し引かれなかった場合、この時点でユーザーに注文の失敗が通知され、差し引かれた超過在庫は定期的に補充される必要があります。

メッセージミドルウェアの導入により、分散データベースのデータ同期の問題を効果的に解決し、分散トランザクションを回避できます。さらに、在庫を削減する際の同時ロック競合が減少し、パフォーマンスが向上するという追加の利点もあります。