mysql電商平臺的技術架構是什么

這篇文章主要講解了“mysql電商平臺的技術架構是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“mysql電商平臺的技術架構是什么”吧！

一、電商平臺標準化套件

A.商城系統

1.設置：站點設置；帳號同步；上傳設置；SEO設置；消息通知；支付方式；權限設置；配送地區；

2.商品：分類管理；品牌管理；商品管理；圖片空間；

3.店鋪：店鋪管理；店鋪等級；店鋪分類；二級域名；

4.會員：會員管理；積分管理；預存款；分享綁定設置；買家動態；

5.交易：訂單管理；退款管理；咨詢管理；舉報管理；評價管理；投拆管理；

6.網站：文章分類；文章管理；系統文章；頁面導航；廣告管理；首頁管理；推薦位；

7.運營：基本設置；團購管理；兌換禮品；活動管理；

8.統計：會員統計；店鋪統計；銷量分析；商品分析；營銷分析；

B.圈子（BBS）

圈子設置；成員頭銜設置；圈子分類管理；圈子管理；圈子話題管理；圈子成員管理；圈子舉報管理；

C.CMS（文章管理系統）

CMS管理；首頁管理；文章管理；文章分類；畫報分類；專題管理；標簽管理；評論管理；

D.移動端

首頁設置；分類圖片設置；下載設置；

二、電商平臺的技術架構

A.應用服務器

1.兩大類：前端服務器（主要完成用戶的響應）、后端服務器（主要完成數據處理）

2.Nginx在內存分配方面表現良好，使用多線程來處理請求，使得多個線程之間可以共享內存資源，從而使內存使用量大大減少。此外還使用分段內存分配策略，按需分配及時釋放，總體占用內存很小，可支持較大的并發連接。

B.負載均衡

1.F5(F5 BIG-IP)，官方名稱為本地流量管理器，可做4-7層負載均衡。

2.LVS(Linux Virtual Server)，針對大業務量的網絡應用（如新聞服務、網上銀行、電子商務等）。抗負載能力最強，配置簡單，工作穩定（LVS+Keepalived），應用范圍比較廣。

⑴LVS三種工作模式：

①VS/NAT(Virtual Server Via NAT)，網絡地址轉換技術，由一臺負載均衡服務器和后端幾臺真實服務器組成了一個服務器集群。優點：只需要一個IP地址配置在調度服務器上，服務器組可以用私有的IP地址。缺點：伸縮能力有限。

②VS/TUN(Virtual Server via IP Tunneling)，連接調度和管理與VS/NAT中的一樣，只是報文轉發方法不同。優點：可以極大地增加負載調度的服務器數量，可以用來構建高性能的超級服務器。要求所有的服務器必須支持“IP Tunneling”或“IP Encapsulation”協議。

③VS/DR(Virtual Server via Direct Routing)，調度器根據各個服務器的負載情況，動態地選擇一臺服務器，不修改也不封裝IP報文，而是將數據幀的MAC地址改為選出服務器的MAC地址，再將修改后的數據幀向服務器組的局域網上發送。要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上，服務器網絡設備不作ARP響應，或者能將報文重定向到本地的Socket端口上。

⑵LVS的調度算法

輪詢調度；加權輪詢調度；最小連接調度；基于局部性的最小連接；待復制的基于局部性的最小連接；目標地址散列調度；源地址散列調度；

3.Nginx：可以按輪詢、IP_HASH、URL_HASH、權重等多種方法對后端服務器進行調度，同時也支持健康檢查。對網絡依賴性小，工作在第7層。

4.HAProxy：能夠補充Nginx的一些缺點，如Session保持，Cookie引導等；支持URL檢測；從效率上講，優于Nginx；可以對MySQL讀操作進行負載均衡；

C.緩存

1.兩部分：文件緩存（靜態內容）、數據緩存 

2.客戶端緩存：Header(“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 Repliction（推薦）；MySQL數據切分；

5.數據切分：通過某種特定算法，將存放在同一個庫（表）中的數據分散存放到多個庫（表）中，以達到分散單臺設備負載的效果。

6.垂直切分：按照不同的表來切分到不同的數據庫（主機）之上。規則簡單，實施方便，適合各業務之間的耦合度非常低，相互影響小，業務邏輯清晰的系統。

7.水平切分：根據表中數據的邏輯關系將同一個表中的數據按照某種算法拆分到多個表中。拆分規則本身就較根據表名來拆分更為復雜，后期數據維護也更復雜，但對于減輕系統壓力來說更好，是在高并發大數據下的推薦處理方法。

E.文件存儲

共享存儲：NFS

文件存儲：HDFS、FastDFS

F.消息隊列

ActiveMQ；Gearman；MemcacheQ；RabbitMQ；HTTPSQS；淘寶MetaQ；NSQ等，另外基于Memcache/Redis的消息隊列也易部署、易維護和易擴展。

G.搜索設計

lucene、sphinx以及國產xunsearch

三、商城套件的設計與實現

A.會員模塊

1.模塊構成：注冊后默認為買家。如果想申請為賣家，則需要在注冊后提交商家入駐申請，經過審核后成為賣家。買家賣家登錄口獨立存在。作為網站的基礎，基本涉及了網站各個模塊。

2.設計思路：

①設計要求：

• 界面簡潔方便：注冊登錄簡潔方便，一個手機號或郵箱+密碼
  

• 多收集會員信息：會員中心收集
  

• 差異化管理：會員等級制度和管理制度
  

• 增加會員黏性
  

• 會員傳幫帶
  

• 高內聚低耦合：買家和賣家中心分為獨立模塊
  

• 進行數據分析
  

②數據表設計

• 主從配合：主表與從表
  

• 合理使用冗余：例如店鋪表中也保存用戶名
  

• 結構清晰：例如用戶表與商家表分開
  

③模塊設計

• 買家會員功能需求：注冊登錄；買家會員等級；資料管理；帳號安全；其他相關功能
  

• 專家帳戶功能需求：商家開店；權限管理；建立子帳戶；店鋪資料管理；店鋪裝修；店鋪分類；店鋪消費；其他相關功能
  

3.開發和使用

會員合理分層；運用口碑營銷；了解會員的生命周期；會員關懷；合理全面的會員數據分析；

B.商品模塊

1.幾個小模塊：商品分類；品牌；類型；規格與規格值；屬性與屬性值；商品；

2.模塊構成：

①商品分類：新增、編輯、刪除、導入導出，很少修改，緩存文件

②品牌：新增（平臺添加及商家添加，商家添加需要審核）、編輯、刪除

③規格與規格值：平臺進行增刪改，店鋪只能根據規格添加規格值

④類型與屬性：平臺進行操作

⑤商品：由店鋪進行增刪改。平臺可審核，可以刪除。

3.設計思路：

①商品相關數據表設計

• 商品分類表與類型表是一對多的關系，商品分類通過類型與屬性、規格、品牌產生關聯。與商品表是一對多
  

• 屬性系列表包括屬性表和屬性值表，是一對多的關系，屬性表與類型表是多對一的關系，屬性值表與商品表以及屬性與商品關系表為橋梁是多對多的關系
  

• 規格系列表包括規格表和規格值表，是一對多的關系。規格表與類型表以類型與規格關系表為橋梁是多對多。規格表、規格值表與商品表的關系是多對多的關系。
  

• 品牌表以類型與品牌關系表為橋梁，與類型表是多對多。品牌表與商品表是一對多。
  

• 商品系列表包括商品表、商品公共表和商品圖片表。商品表和商品公共表是多對一，和商品圖片表是多對多
  

②平臺管理商品的相關設計思路

平臺管理員需要先完成對商品分類、品牌、類型、規格、屬性的設置

③商家發布商品的設計思路

設置規格值；商品圖片；圖片空間；庫存報警；關聯板式；

④用戶檢索商品的設計思路

使用全文檢索

3.代碼實現

刪除商品分類時需要清理與商品分類相互關聯的數據；

C.促銷模塊

1.模塊構成：

①常用促銷方式：

• 折價促銷
  

• 團購：促進電商網站的銷量，直接帶去電商網站的注冊會員數增長，通過促進客戶的嘗試購買，發現平臺存在的問題，擴大電商網站的品牌曝光度和知名度；
  

• 惠贈式促銷：買一送一、買送禮品、買送積分、買送代金券；
  

• 搭配銷售：客戶在瀏覽一件商品時再向他推薦其他商品，這件商品可以與其他商品搭配起來一起銷售，同時總價進行相應幅度的降低。
  

• 限時限量促銷
  

• 抽獎式促銷
  

• 互動式促銷：好評有禮、邀請有禮
  

• 附加值促銷：包郵、附加服務
  

2.設計思路

①業務的設計原則

• 吸引注意力
  

• 說服功能
  

• 反饋信息
  

• 刺激銷售
  

②模塊設計實例（團購模塊）

• 套餐管理：平臺提供給店鋪
  

• 團購管理：平臺進行審核，并且可以隨時下架
  

• “即將開始”：在團購中加入
  

• 搜索設置：商品分類、價格區間等
  

• 詳細信息：圖片、價格、描述醒目，清晰可見的狀態
  

• 團購訂單：統一到訂單模塊中

3.開發和使用

開發原則：簡單易懂、吸引眼球、靈活組合、數據統計

注意：利人利已、搭配使用、不繁瑣、吸引力足夠、實事求是、一諾千金

D.購物車模塊

1.模塊構成：添加、刪除、編輯、收藏商品的功能

2.設計思路

①設計要求：

• 持久化保存：登錄前cookie保存，登錄后數據庫保存，下單成功后清除已購買的商品
  

• 支持加入多種類型的商品
  

• 支持加入多個店鋪商品
  

• 操作便捷
  

• 數據完整性：促銷信息、商品小計、店鋪小計等
  

• 數據準確性：關鍵信息（庫存、價格、狀態等）
  

②數據表設計

• 表關系核心字段不可缺少：涉及會員、店鋪、商品表等
  

• 必要的冗余字段 ：商品價格、名稱、圖片、店鋪名等
  

• 數據準確性：關鍵節點處理時去查詢數據庫得到最新有效數據
  

③購物車模型設計

• 增刪改查操作
  

• 入口封裝：對cookie或數據庫等操作對外表現為一個入口，以參數形式分流
  

• 數據統計
  

• 數據完整性與準確性
  

E.配送模塊

1.模塊構成：平臺需要初始化一些基本信息，如全國或地方性的地區行政區域、主要的快遞公司等；商家 需要設置快遞公司，；運費模板不但支持不同地區不同運費，還避免了商家對商品運費的重復設置，減輕工作量；買家下單時，要設置收貨信息，系統據此來計算運費。

2.設計思路

①設計要求

• 內置行政區域
  

• 內置配送公司
  

• 設置貨到付款地區
  

• 運費模板
  

• 收貨地址
  

• 物流跟蹤
  

②數據表設計：收貨地址表、發貨地址庫表、貨到付款區域表、運費模板表等

3.功能實現

①配送區域：一是標準的行政區域設置；另一個是貨到付款區域的設置；配送地區頁面的加載時的全部地區數據都由服務器端來完成，在加載頁面時，將已支持貨到付款縣ID放入JS數組中，在編輯地區時，上級地區是否選中以及數量的變化由客戶端JS來完成

②配送公司：至少包含公司名稱、網址、公司代碼等

③收貨地址：可以保存N個，設置一個默認收貨地址

F.訂單模塊

1.設計思路

①訂單狀態

• 訂單狀態是訂單流程的重要標志，訂單處于哪個階段，允許哪個角色來處理，主要的判斷依據
  

• 一般使用數字標識，至少包含默認、取消、支付、發貨、收貨，還可能有刪除、審核、備貨、出貨、鎖定、退貨、退款、仲裁等等
  

②訂單金額

指訂單中涉及金錢元素的統稱，至少包括商品單價、商品總價、訂單總金額、優惠金額、運費、代金券面額、退款金額等

③訂單編號

建義可以充分考慮時間、隨機數、商家ID、會員ID、自增ID這些相關元素，設計的目的就是保證在高并發下，訂單編號 的重復幾率降到最低

④庫存

• 可銷售庫存
  

• 訂單占用庫存
  

• 不可銷售庫存
  

• 鎖定庫存：在促銷活動中
  

• 虛擬庫存
  

⑤合并支付

可以把不同商家訂單進行合并統一支付

⑥角色權限 

• 買家：訂單取消、刪除（放入回收站）、退款、退貨、收貨、評價等
  

• 商家：訂單審核、關閉、發貨、售后處理等
  

• 平臺：訂單取消、更改收款狀態、刪除、仲裁等
  

⑦表設計

• 訂單主表：存放主要及常用的訂單信息，如訂單編號、金額、運費、狀態等
  

• 輔表：輔助信息，如發貨信息、發票信息、收貨人信息、促銷信息等。
  

• 訂單商品表：有些話訂單中的商品列表信息
  

• 支付單表：為合并付款設計，保存一個支付單號，N條訂單表記錄使用一個支付單號
  

• 訂單日志表：在訂單內容發生變化時記錄操作日志，包括操作人、操作時間、操作內容等
  

2.下單

系統在產生訂單時會做大量的處理工作，比如處理收貨信息、發票信息、促銷信息、運費、代金券、支付單、訂單、日志等。

G.支付接口

1.接入支付結果兩種方式：一種是同步的，通過瀏覽器進行跳轉通知；一種是異步的，即服務器后端執行。

2.設計要求：安全性；數據完事性（事務處理）；擴展性；

3.數據庫設計：至少包含支付方式的名稱和標識碼，標識碼要與支付接口API程序有些話的目錄名一致，此外還要保存序列化后的支付接口配置信息及支付接口狀態；

H.退單模塊

1.設計思路

①在有新退款或退貨申請但又沒完成訂單（確認收貨時），為防止產生糾紛，要鎖定訂單狀態

②退貨：在退款流程基礎上增加了買家發貨和商家收貨的步驟。

③當商家不同意退款或退貨時，買家可再次申請，也可以向平臺投訴商家 ，提交相關證據，由系統管理員做仲裁。

④可以使用一個表，用一個字段標識是退款還是退貨

⑤退款退貨原因是由系統管理員在后臺錄入，買家在提交申請時選擇。

2.開發技巧

①要先定好規則、理清思路，對于邏輯中有不明白的地方，及時溝通解決。

②盡量做到代碼的利用，一定要進行服務器端的數據驗證。

I.結算模塊

結算是平臺和商家之間的賬單結算，定期結算，出賬后系統會等待商家對賬單進行確認，如果無誤，商家確認后進入系統審核環節，系統審核后提交到財務部門進行付款操作；付款完成后，在后臺錄入付款相關信息，賬單結算完成。

1.設計思路

①數據表設計：賬單表，包括日期、訂單總金額、總運費、退單總金額、傭金總金額、退還傭金金額、店鋪費用、應結金額以及結算狀態等字段；賬單匯總表是對每個月所有商家結算信息的統計匯總；

②結算流程設計：出賬，系統自動計算出本月的結算賬目

【執行時機】自動與手動；

【結算對象】上個月發生的交易完成的訂單或退單；

【計算公式】訂單金額、傭金金額（傭金=商品實際售價*購買數量-優惠分攤金額）、退單金額、退還傭金、店鋪促銷費用；

③平臺應付金額=訂單金額-傭金金額-退單金額+退還傭金-店鋪促銷費用；

④對賬：平臺提供出信息，核對無誤后確認并提交平臺審核。審核后進行財務流程進行支付，付款完成后輸入相關付款信息并提交，結算流程完成。

J.統計模塊

1.讓數據分析介入運營：以數據為基礎，智能地制定運營決策；以數據為目標，有效執行運營計劃；以數據為依據，優化商務過程；

2.模塊構成：

①瀏覽量（PV），瀏覽器加載網頁次數的總和；

②訪客數（UV），用Cookie確定絕對統一訪問者；

③轉化率，指產生實際消費的客戶和來到網站的總客戶數量的比值。成交轉化率=成交客戶數/總訪客數；

④平均訪問深度，指用戶在一次瀏覽你的網站的過程中瀏覽了你網站的頁數，就是PV和UV的比值；

如何提高訪問深度？

• 網站合理的排版和布局；
  

• 網站的內容；
  

• 合理的導航和適當的內部鏈接錨文本；
  

⑤網站人均停留時間，平均網站停留時間=網站總停留時間/會話的數量（訪次）

⑥頁面跳失率，指訪客到達該目標頁面，到達后沒有繼續訪問該網站其他頁面既離開，稱之為一次Bounce!也就是跳失了。跳失率=瀏覽了該頁面就離開的訪問次數/該頁面的全部訪問次數；

⑦下單商品數

⑧商品下單量

⑨客單價，指一定時間內網站每一個會員平均購買商品的金額，即平均交易金額。客單價=銷售總額/顧客總數，或者客單價=銷售總金額/成交總筆數；

⑩重復購買率，指消費者對該產品或者服務的重復購買次數。一是，所有購買過產品的顧客，以每個人為獨立單位重復購買產品的次數；另一種算法是單位時間內，重復購買的總次數占比；推薦第一種；

3.設計思路

①數據本身的設計原則

• 要有總體的概念：銷售總體信息（下單金額、下單量、平均客單價）；商品總體信息（下單商品數、商品平均價格、新增商品數、商品總數量、7日內商品銷售TOP30）；客戶總體信息（會員總數、新增會員數、下單會員數）；店鋪總體信息（店鋪總數、新增店鋪總數、7日內店鋪銷售TOP30）
  

• 統計要細致到一點：細致到某個會員、某個時間點、某個地區等
  

• 定期數據分析：同比，今年第N月與去年第N月比（同比發展速度=本期數/去年同期數*100%；同比增長速度=(本期數-去年同期數)/去年同期數*100%）；環比，就是報告期與前一統計時間段比較（環比發展速度=（本期數/上期數）*100%；環比增長率=（本期數-上期數）/上期數*100%）
  

• 重視日常運營數據 ：客戶平均訪問頁面數、平均停留時間、跳出率、商品被收藏次數等
  

• 數據應具有實時性
  

②業務層次的設計原則

• 層層深入剖析業務：電商網站數據分析按照行業分析->店鋪分析->品牌分析->商品、會員的分析，從大到小層層深入
  

• 直觀易懂：表示變化趨勢用折線圖；簡單比較用柱狀圖；用漏斗圖展示流程轉化率；表示比例最好用餅圖或者環形圖；表示在區域中的分布情況使用統計地圖；
  

③模塊設計的設計原則：可移植性；擴展性；簡便性和直觀性；緩存的運用；

④數據表的設計原則

⑤多建立緩存數據表；字段簡潔，減少復雜判斷；必要的冗余字段，減少聯查（會員名稱、商品名稱、店鋪名稱等等）；

4.開發使用

①數據運營應注意以下幾點問題：

②人的問題：對數據的重視應該從領導做起；

③實際運用：將數據實際使用起來；

④不要最好只求合適：選擇一個數據挖掘算法時，要弄清楚它是否適合我們要解決的問題；

⑤求真實：挖掘時盡可能提取有效信息；

⑥重復性：需要一段時間重新挖掘；

⑦數據積累：數據分析需要積累一定量的數據，經過數據挖掘得出的結果才有說服力；

⑧快速反應：數據產生后快速瓜，得出結果，使效果最大化；

K.預存款

1.會員對預存款主要有三種操作：充值、提現和購物

2.設計思路

①設計要求：安全性；數據完整性；

②數據表設計：

• 充值表，記錄會員的充值信息，主要字段充值單呈、會員信息、充值金額、充值時間、充值狀態等，有管理員操作還應記錄管理員身份
  

• 提現表，記錄會員的提現信息，主要字段提現單號、會員信息、提現金額、收款銀行信息、申請狀態以及平臺的付款信息（付款時間、操作人等）
  

• 日志表，記錄所有變更預存款時的操作記錄，包括對可以金額和凍結金額的變更 都要作詳細的記錄，主要字段操作人信息、操作類型（下單、提現、充值、退款等）、可用預存款、凍結預存款、操作時間、備注等

感謝各位的閱讀，以上就是“mysql電商平臺的技術架構是什么”的內容了，經過本文的學習后，相信大家對mysql電商平臺的技術架構是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！