mysql 電子商取引プラットフォームの技術アーキテクチャは何ですか?-mysql チュートリアル-php.cn

1. E コマースプラットフォーム標準化スイート

A. モールシステム

1. 設定: サイト設定、アカウント同期、アップロード設定 ; SEO 設定; メッセージ通知; 支払い方法; 権限設定; 配送エリア;

2. 商品: カテゴリ管理; ブランド管理; 商品管理; 画像スペース;

3. ストア: ストア管理 ; ストアレベル; ストア分類; 第 2 レベルドメイン名;

4. メンバーシップ: メンバー管理; ポイント管理; 事前入金; バインディング設定の共有; 購入者のダイナミクス;

5. トランザクション: 受注管理; 返金管理; 相談管理; レポート管理; 評価管理; 投資・解体管理;

6. ウェブサイト: 記事分類; 記事管理; システム記事; ページナビゲーション; 広告管理; ホームページ管理; レコメンドポジション;

7. 操作: 基本設定; 共同購入管理; ギフト引き換え; イベント管理;

8. 統計: 会員統計; 店舗統計; 売上分析; 商品分析; マーケティング分析;

B.サークル(BBS)

サークル設定; メンバータイトル設定; サークル分類管理; サークル管理; サークルトピック管理; サークルメンバー管理; サークルレポート管理;

C.CMS (記事管理システム)

CMS管理、ホームページ管理、記事管理、記事分類、写真分類、トピック管理、タグ管理、コメント管理;

D. モバイル端末

ホームページ設定; カテゴリ画像設定; ダウンロード設定;

2. e の技術アーキテクチャ-コマースプラットフォーム

A. アプリケーションサーバー

1. 2 つの主要なカテゴリ: フロントエンドサーバー (主にユーザーの応答を完了します)、バックエンドサーバー (主にデータ処理を完了します)

2.Nginx はメモリ割り当てで優れたパフォーマンスを発揮し、マルチスレッドを使用してリクエストを処理するため、メモリリソースを複数のスレッド間で共有できるため、メモリ使用量が大幅に削減されます。さらに、セグメント化されたメモリ割り当て戦略を採用し、需要に応じて適切なタイミングでメモリの割り当てと解放を行うため、全体的なメモリ使用量が非常に少なく、多数の同時接続をサポートできます。

B. 負荷分散

1.F5 (F5 BIG-IP)、正式名はローカルトラフィックマネージャーで、レイヤー 4 ～ 7 の負荷分散を行うことができます。

2.LVS (Linux 仮想サーバー)、大規模なビジネス量を伴うネットワークアプリケーション (ニュースサービス、オンラインバンキング、電子商取引など) 用。 LVSとKeepalivedの組み合わせは、負荷耐性が強く、構成が簡単で、動作が安定しているため、幅広い用途に適用可能です。

⑴LVS の 3 つの動作モード:

①VS/NAT (NAT 経由の仮想サーバー)、ネットワークアドレス変換テクノロジは、負荷分散サーバーとバックエンド上の複数の実サーバーで構成され、サーバーを形成します集まる。利点: スケジュールサーバー上で構成する必要がある IP アドレスは 1 つだけであり、サーバーグループはプライベート IP アドレスを使用できます。短所: スケーラビリティが制限されています。

②VS/TUN (IP トンネリング経由の仮想サーバー)、接続のスケジュールと管理は VS/NAT と同じですが、メッセージ転送方法が異なります。書き直された文: このソリューションの利点は、負荷スケジューリングサーバーの数を大幅に増やせるため、高性能のスーパーサーバーを構築できることです。「IP トンネリング」または「IP カプセル化」プロトコルをサポートするサーバーが必要です。

③VS/DR (ダイレクトルーティング経由の仮想サーバー)、スケジューラは、IP パケットの変更やカプセル化を行わずに、各サーバーの負荷に基づいてサーバーを動的に選択しますが、代わりにデータフレームの MAC アドレスを変換します。、サーバーの MAC アドレスを選択し、変更したデータフレームをサーバーグループの LAN に送信します。ロードスケジューラと実際のサーバーは、同じ物理ネットワークセグメントに接続されたネットワークカードを持っている必要があります。サーバーネットワークデバイスは ARP に応答しないか、パケットをローカルソケットポートにリダイレクトできます。

⑵LVS スケジューリングアルゴリズム

ポーリングスケジューリング、加重ラウンドロビンスケジューリング、最小接続スケジューリング、ローカリティベースの最小接続、ローカリティベースのコピーされる最小接続、ターゲットアドレスハッシュスケジューリング、ソースアドレスハッシュスケジューリング;

3.Nginx: バックエンドサーバーはポーリング、IP_HASH、URL_HASH、重みなどの方法でスケジュールでき、ヘルスチェックもサポートされています。ネットワークへの依存度はほとんどなく、レイヤー 7 で動作します。

4.HAProxy: セッション保持、Cookie ガイダンスなど、Nginx のいくつかの欠点を補うことができます。URL 検出をサポートしています。効率の点では Nginx よりも優れています。MySQL 読み取りの負荷分散が可能です。操作;

C. キャッシュ

1. 2 つの部分: ファイルキャッシュ (静的コンテンツ)、データキャッシュ

2. クライアントキャッシュ: ヘッダー( “Cache-control :must-revalidate”);Header(“Expires:”.gmdate(“Did M Y H:i:s”,time() (60*60*24*30)));//30 日で期限切れになりますphp

3.CDN アクセラレーション

4. 静的ファイルキャッシュ: Varnish/Squid

5. データキャッシュ: memcache、redis

D . データストレージ

1. リレーショナルデータベース: MySQL、Oracle、SQL Server

2. メモリデータベース: Redis、MongoDB (ドキュメントタイプ)

3. 分散データベース: HBase

4. MySQL スケーラブルなソリューション: MySQL Cluster; DRBD ハードディスクネットワークミラーリング; MySQL レプリケーション (推奨); MySQL データセグメンテーション;

5. データセグメンテーション: 特定のアルゴリズムによる、同一のデータベース（テーブル）に格納されているデータを複数のデータベース（テーブル）に分散して格納することで、単一の機器の負荷を分散する効果を実現します。

6. 垂直セグメンテーション: 異なるテーブルに従って異なるデータベース (ホスト) に分割します。ビジネス間の結合が低く、相互影響が少なく、ビジネスロジックが明確なシステムに適しており、ルールがシンプルで実装が容易です。

水平テーブル分割: データテーブル内の論理関係に従って、データは特定のアルゴリズムを通じて複数のテーブルに分割されます。分割ルール自体はテーブル名に基づく分割よりも複雑で、その後のデータのメンテナンスも複雑ですが、システムの負荷を軽減するのに優れており、同時実行性の高いビッグデータでは推奨される処理方法です。

#E.ファイルストレージ

共有ストレージ: NFS

ファイルストレージ: HDFS、FastDFS

F.メッセージキュー

ActiveMQ、Gearman、MemcacheQ、RabbitMQ、HTTPSQS、Taobao MetaQ、NSQ などさらに、Memcache/Redis に基づくメッセージキューも、展開、保守、管理が容易です。拡大する。

#G. 検索設計

#lucene、sphinx、国内 xunsearch

#3. モールスイートの設計と実装

A. メンバーモジュール

1. モジュール構成: 登録後のデフォルトは購入者です。販売者になるためには、登録後に決済申請を提出し、審査に合格する必要があります。買い手と売り手のログインポートは独立して存在します。 Web サイトの基盤として、基本的に Web サイトのすべてのモジュールが含まれます。 2. デザインアイデア:

① デザイン要件:

インターフェイスはシンプルで便利です: 登録とログインはシンプルで便利です。電話番号または電子メールパスワード

さらに多くのメンバー情報を収集します: メンバーセンターが収集します
差別化された管理: メンバーの階層と管理システム
会員の定着率を高める
#会員向けガイダンス
#高い結合力と低い結合性: 購入者センターと販売者センターはデータ分析のために独立したモジュールに分割されています
②データテーブルの設計

合理的な冗長性の使用: たとえば、ユーザー名前はストアテーブルにも保存されます
明確な構造: たとえば、ユーザーテーブルは販売者テーブルから分離されます
③モジュール設計

会員の合理的な階層化、口コミマーケティングの使用、会員のライフサイクルの理解、会員のケア、会員データの合理的かつ包括的な分析、

1. いくつかの小さなモジュール: 製品分類、ブランド、タイプ、仕様と仕様値、属性と属性値、商品、

2. モジュール構成:

① 製品分類: 追加、編集、削除、インポートとエクスポート、ほとんど変更されない、キャッシュされたファイル

② ブランド: 追加 (プラットフォームによって追加、マーチャントによって追加、マーチャントの追加)要検討）、編集、削除

③仕様と仕様値：プラットフォームの追加、削除、変更については、販売店は仕様書に従った仕様値の追加のみ可能です

④型と属性：

プラットフォーム運営

⑤商品：追加・削除・修正はストア側で行います。プラットフォームは確認および削除できます。

3. 設計アイデア:

① 製品関連データテーブルの設計

製品分類テーブルとタイプテーブルは 1 対 1 で対応します。多くの関係があり、製品分類表のタイプは、属性、仕様、ブランドに関連付けられています。製品テーブルとは 1 対多です。

属性シリーズテーブルには、属性テーブルと属性値テーブルが含まれており、1 対多の関係になります。属性テーブルとタイプテーブルは多対 1 であり、属性値テーブルと製品テーブル、および属性と製品関係テーブルの関係は多対多の関係です。
仕様シリーズテーブルには、仕様テーブルと仕様値テーブルが含まれており、A 対多の関係になります。仕様テーブルとタイプテーブルは、多対多の関係を形成するためのブリッジとしてタイプと仕様の関係テーブルを使用します。仕様テーブル、仕様値テーブル、製品テーブルの関係は多対多の関係になります。
ブランドテーブルは、タイプとブランドの関係テーブルをブリッジとして使用し、タイプテーブルと多対多です。ブランドテーブルと製品テーブルは 1 対多です。
製品シリーズテーブルには、製品テーブル、製品公開テーブル、製品画像テーブルが含まれます。製品テーブルと製品パブリックテーブルは多対 1、製品画像テーブルは多対多です
プラットフォーム管理スタッフはまず商品分類、ブランド、タイプ、仕様、属性の設定を完了する必要があります
##③マーチャントが商品を公開するための設計アイデア
##仕様値の設定; 製品写真; 画像スペース; 在庫アラーム; 関連ボードタイプ;

④ ユーザーが製品を検索するためのデザインアイデア

全文検索を使用する

3. コードの実装

製品カテゴリを削除する場合、製品カテゴリとのインタラクションをクリーンアップする必要があります関連データ;

#C. プロモーションモジュール

1. モジュール構成:

①一般的なプロモーション方法:

割引プロモーション

共同購入: eコマースの販売促進ウェブサイトの登録会員数を直接的に増加させ、顧客の購入を促進し、プラットフォームに存在する問題点を発見し、電子商取引ウェブサイトのブランド露出と人気を拡大します。

優先プロモーション: 1 つ購入すると 1 つ無料、購入で 1 つプレゼント、購入でポイント獲得、購入でクーポン獲得;

マッチング販売: 顧客商品を閲覧する際に、他の商品を彼に勧めてください。この商品は他の商品と同時販売することができ、その分合計金額が安くなります。

#期間限定キャンペーン

抽選キャンペーン

# #インタラクティブなプロモーション: 丁寧な賞賛、丁寧な招待

付加価値のあるプロモーション: 送料無料、追加サービス

2 。デザインアイデア

①ビジネスデザイン原則

##開発原則: シンプルで理解しやすい、目を引く、柔軟な組み合わせ、データ統計

注: 他人と自分自身に利益をもたらします。一緒に使用すると、面倒ではなく、魅力的で、現実的で、千ドルの価値があると約束されます。

D. ショッピングカートモジュール

#1. モジュール構成: 商品の追加、削除、編集、収集機能

2. 設計思想

#①設計要件:

永続性保存: ログイン前に Cookie を保存、ログイン後にデータベースを保存、注文が成功しましたその後、購入した商品をクリアします

#複数の種類の商品の追加をサポート
#複数のストア商品の追加をサポート
##操作が簡単
データの整合性: プロモーション情報、製品小計、店舗小計など
#②データテーブルの設計
テーブルリレーションシップのコアフィールドには、メンバー、店舗、製品テーブルなどが含まれます。

必要な冗長フィールド: 製品の価格、名前、写真、店舗名など

データの精度: キーノードの処理時にデータベースにクエリを実行して、最新の有効なデータを取得します
③ショッピングカートのモデル設計
追加、削除、変更、およびクエリ操作

エントリのカプセル化: Cookie やデータベースなどの操作は、パラメータを使用して入口として外部的に表現されます。フォームの流用

データ統計
##データの整合性と正確さ
##E. 配信モジュール
2. 設計アイデア
①設計要件

組み込みの管理領域

ビルトイン配送会社

##運賃テンプレート
##受取住所
物流追跡
# ②データテーブル設計：受取住所テーブル、配送住所商品住所データベーステーブル、着払いエリアテーブル、運賃テンプレートテーブル等
①配送エリア：1つは標準行政エリア設定、もう1つは配送エリアです。代引きエリアの設定; 配達地域ページをロードする際のすべての地域データはサーバーによって完了しますページをロードするときに、JS 配列に代引きをサポートする郡 ID を入れます地域を編集するときは、上位レベルかどうか地域を選択し、数量を指定します。変更はクライアント JS によって完了します。
②販売会社: 少なくとも会社名、Web サイト、会社コードなどを含めます。
③受信アドレス: N を保存でき、デフォルトの配送先住所を設定できます

#F. 注文モジュール

①注文ステータス

注文ステータスは、注文プロセスの重要な兆候、注文がどの段階にあるか、どの役割が処理を許可されているかを示します。主な判断基準は

です。一般に、少なくとも不履行、キャンセル、支払い、発行、商品、受領書を含むデジタル ID が使用され、削除、レビュー、在庫、発送、ロック、返品、返金、仲裁などが含まれる場合もあります。

②注文金額

少なくとも商品の単価、商品の合計金額、注文総額など、注文に関わる金銭的要素の総称を指します。金額、割引額、配送料、バウチャー額面、返金額など。

③注文番号

Jianyi は、時間、乱数、販売者 ID、会員 ID、などの関連要素を十分に考慮できます。設計の目的は、高い同時実行性の下で注文番号が繰り返される確率を確実に最小限に抑えることです。

④在庫
販売可能な在庫
注文占有在庫
販売不可在庫
ロック在庫: 販売中イベント
仮想在庫

⑤一括支払い

さまざまな販売者からの注文を統合できます支払い

⑥ロール権限

購入者: 注文のキャンセル、削除 (ごみ箱に入れる)、返金、返品、商品の受け取り、評価など
販売者: 注文の確認、締め切り、発送、販売後の処理など。
プラットフォーム: 注文のキャンセル、支払いステータスの変更、削除、仲裁など。

⑦テーブル設計

注文メインテーブル: 主要で一般的に使用される注文情報を格納します。注文番号、金額、運賃、ステータスなど。
補助テーブル: 出荷情報、請求書情報、荷受人情報、プロモーション情報などの補助情報。
#注文商品テーブル: 注文内の一部の商品リスト情報
支払い注文テーブル: 一括支払い用に設計されています。支払い注文番号を保存し、N 個の注文テーブルレコードの支払い注文番号を使用します。
注文ログテーブル: オペレーターを含む注文内容が変更された場合の操作ログを記録します。操作時間、操作内容など

2. 注文を行う

注文を生成する際、システムは次のような多くの処理作業を実行します。領収書情報と請求書の処理情報、プロモーション情報、送料、伝票、支払い命令、注文、ログなど。

G. 支払いインターフェース

1. 支払い結果にアクセスするには 2 つの方法があります: 1 つはブラウザを介したジャンプ通知による同期であり、もう 1 つは非同期です。つまり、サーバーバックエンドの実行です。

2. 設計要件: セキュリティ、データの整合性 (トランザクション処理)、スケーラビリティ;

3. データベースの設計: 少なくとも支払い方法の名前と識別コード、および識別コードを含める支払インターフェース API プログラムの一部のディレクトリ名は一致している必要があります。さらに、シリアル化された支払インターフェース構成情報と支払インターフェースのステータスを保存する必要があります。

H. チャージバックモジュール

1. デザイン案

①新たな返金・返品申請があり、注文が完了していない場合（受領確認時点）、紛争を防ぐため、注文をキャンセルさせていただきます。ステータスはロックされている必要があります

②返品: 返金プロセスに基づいて、購入者の発送と販売者の受け取りのステップが追加されます。

販売者が製品の返金または返品に同意しない場合、購入者は再度申請するか、販売者についてプラットフォームに苦情を申し立て、システム管理者による仲裁のために関連証拠を提出することができます。

④テーブルを使用し、フィールドを使用して返金か返品かを識別できます。

⑤返金または返品の理由は、バックグラウンドでシステム管理者によって入力され、システム管理者によって選択されます。申請書を提出する際の購入者。

2. 開発スキル

① まずルールを設定し、アイデアを明確にし、ロジックの不明点をタイムリーにコミュニケーションして解決する必要があります。

② コードを最大限に活用し、サーバー側のデータ検証を必ず実行してください。

I. 決済モジュール

決済とは、プラットフォームと加盟店との間で行われる請求の決済であり、定期的に決済されます。販売者は請求書を確認します。それが正しい場合、販売者は確認後、システム審査プロセスに入ります。システム審査後、支払い業務のために財務部門に提出されます。支払いが完了すると、支払いはバックグラウンドで関連情報が入力され、請求決済が完了します。

1. 設計アイデア

①データテーブルの設計: 日付、合計注文金額、合計送料、合計返金金額、合計手数料金額、返金手数料金額、店舗手数料、フィールドを含む請求書テーブル支払額や決済状況など; 請求集計表は毎月全加盟店の決済情報を統計的にまとめたもの;

②決済プロセス設計: アカウント発行時にシステムが自動的に決済口座を計算今月

[実行タイミング] 自動および手動;

[決済対象] 完了した注文または先月発生した取引のチャージバック;

[計算式] 注文金額, 手数料額（手数料 = 商品の実販売価格 * 購入数量 - 割引配分額）、返品注文金額、返金手数料、ストアプロモーション手数料;

③プラットフォームが支払う金額 = 注文金額 - 手数料金額 -返品注文金額返金手数料 - 店舗販促費;

④調整: プラットフォームは情報を提供し、確認後に確認し、レビューのためにプラットフォームに送信します。審査完了後、支払い手続きを行ってください。支払いが完了したら、支払い情報を入力して送信すると、決済プロセスが完了します。

J. 統計モジュール

1. データ分析を運用に介入させます: データに基づいてインテリジェントに運用上の意思決定を行い、運用計画を効果的に実行するための目標としてデータを使用します。データをもとにビジネスプロセスを最適化;

2. モジュール構成:

①ブラウザがWebページを読み込んだ総閲覧回数(PV);

②訪問者数(UV)、完全に統一された訪問者を決定するために Cookie を使用します;

③コンバージョン率、実際に消費した顧客の割合と、Web サイトに訪問した顧客の総数を指します。トランザクションコンバージョン率 = トランザクション顧客数 / 訪問者数の合計;

④平均訪問深度とは、ユーザーが 1 回の訪問中に閲覧する Web サイトのページ数を指します。これは PV と UV の比率です。

アクセスの深さを改善するにはどうすればよいですか?

ウェブサイトの合理的な組版とレイアウト;
ウェブサイトのコンテンツ;
合理的なナビゲーションと適切な内部リンクのアンカーテキスト;

⑤ウェブサイトでの一人当たりの滞在時間、平均ウェブサイト滞在時間 = ウェブサイトの総滞在時間/セッション数 (訪問数)

⑥ページ直帰率、目標に到達した訪問者を指しますページに到着し、Web サイトの他のページにアクセスし続けずに去った後、これを Bounce!、つまりスキップと呼びます。直帰率の計算式は次のとおりです。ページから離れた訪問数をページへの総訪問数で割った値

⑦注文したアイテムの数

⑧注文したアイテムの量

平均取引金額とは、一定期間内にウェブサイトの各メンバーが購入した商品の平均金額を指し、単価とも呼ばれます。顧客単価は、顧客ごとの平均消費額で表すことができ、計算式は、総売上高を総顧客数で割ったもの、または総売上高を総取引件数で割ったものです。 ⑩リピート購入率とは、消費者が商品を購入したり、サービスをリピート購入した回数を指します。 1 つは、製品を購入したすべての顧客がその製品を独立した単位として繰り返し購入した回数です。もう 1 つのアルゴリズムは、単位時間あたりの繰り返し購入の合計数の割合です。最初のアルゴリズムが推奨されます。

3. 設計アイデア

①データ自体の設計原則

##②ビジネスレベルの設計原則

ビジネスの詳細な分析: E コマースウェブサイトのデータ分析は、業界分析→店舗分析→ブランド分析→商品と会員の分析を大規模なものから小規模なものまで分析します。理解するには: 変化する傾向を表すには折れ線グラフを使用します。単純な比較には棒グラフを使用します。プロセス変換率を表示するにはファネルチャートを使用します。割合を表すには円グラフまたはドーナツグラフを使用するのが最適です。統計マップを使用してエリア内の分布を示します。 ;

③ モジュール設計の設計原則: 移植性、拡張性、シンプルさと直観性、キャッシュの使用 ;
④ データテーブルの設計原則

⑤より多くのキャッシュデータテーブルを確立する; 簡潔なフィールドにより複雑な判断を軽減; 必要な冗長フィールドにより結合クエリ (会員名、商品名、店舗名など) を軽減;

①データ運用は次の問題に注意する必要があります:

②人材の問題: データ重視はリーダーシップから始める必要があります開始;

③実際の応用: 実際にデータを使用する;

④最良のものだけを求めるのではなく、データマイニングアルゴリズムを選択する際には、それが解決したい問題に適しているかどうかを判断する必要があります。 ;

⑤真実の追求：マイニング時に可能な限り有効な情報を抽出します。

⑥再現性：再度掘るのに時間がかかる;

⑦データの蓄積：データ分析にはある程度の蓄積が必要データマイニングで得られる結果は、大量のデータがあってこそ納得のいく結果が得られます。

⑧迅速な対応: データ生成後、効果を最大化するために迅速に結果を得ることができます;

K. 事前デポジット

1 . メンバーは、事前入金の 3 つの主な操作: リチャージ、出金、ショッピングです。

2. 設計アイデア

①設計要件: セキュリティの性別、データの整合性、②データテーブルの設計: