高并發(fā)電商平臺設(shè)計

時間：2022-08-06 05:39:01 | 來源：網(wǎng)站運營

時間：2022-08-06 05:39:01 來源：網(wǎng)站運營

作者：Newway

最近很多客戶商家， 非常關(guān)心我們Legendshop商城系統(tǒng)并發(fā)量數(shù)據(jù)， 其實經(jīng)過 包括中煙集團， 上汽集團商城，中核集團，招商銀行等客戶項目這么多年的實戰(zhàn)落地，我們有一套相對成熟的落地方案；我們整理了一些設(shè)計思路，給大家做一個分享：

1、概述

Legendshop B2B2C電商平臺具有大用戶量、大業(yè)務(wù)量和高并發(fā)的特點。常規(guī)條件下，大數(shù)據(jù)量將使B2B2C電商平臺性能下降，系統(tǒng)響應(yīng)速度變慢。而對電子商務(wù)網(wǎng)站，用戶對響應(yīng)速度要求高。在這種情況下，我們要根據(jù)具體的性能要求來設(shè)計我們的Legendshop B2B2C電商平臺。

這里，我們建設(shè)一個能承受500萬日活躍用戶的B2B2C的平臺，需要如何建設(shè)？

2、名詞解析

DAU(Daily Active User)日活躍用戶數(shù)量。

PV（Page View）訪問量, 即頁面瀏覽量或點擊量，衡量網(wǎng)站用戶訪問的網(wǎng)頁數(shù)量；

UV（Unique Visitor）獨立訪客，統(tǒng)計1天內(nèi)訪問某站點的用戶數(shù)(以cookie為依據(jù));訪問網(wǎng)站的一臺電腦客戶端為一個訪客。

IP（Internet Protocol）獨立IP數(shù)，是指1天內(nèi)多少個獨立的IP瀏覽了頁面，即統(tǒng)計不同的IP瀏覽用戶數(shù)量。

3、常用業(yè)務(wù)場景分析

在Legendshop B2B2C電商平臺，最常見的業(yè)務(wù)場景有以下幾個，他們的并發(fā)要求是怎么樣呢？

3.1、電商平臺首頁

計算模型：

每秒處理請求的數(shù)量=((80%*總PV量)/(24小時*60分*60秒*40%)) 。

其中關(guān)鍵的參數(shù)是80%、40%。表示一天中有80%的請求發(fā)生在一天的40%的時間內(nèi)。24小時的40%是9.6小時，有80%的請求發(fā)生一天的9.6個小時當(dāng)中（很適合電商平臺的應(yīng)用，高峰時間請求多，閑時請求少，不是一天的訪問都是平均,晚高峰 18點-22點是一般電商平臺最高峰時期）。

計算結(jié)果：

500萬DAU ，估算會產(chǎn)生10倍比率的首頁PV訪問

((80%*500萬*10倍)/(24小時*60分*60秒*40%)) = 1157個請求/秒

以上請求數(shù)量是均勻的分布在白天的9.6個小時中，但實際情況并不會這么均勻的分布，會有高峰有低谷。為了應(yīng)對高峰時段，晚高峰 18點-22點是一般電商平臺最高峰時期，應(yīng)該留一些余地，最少也要x2倍，x3倍也不為過。

1157個請求/秒 *3倍=3471個請求/秒。

3.2、商品頁面

計算模型：

每秒處理請求的數(shù)量=((80%*總PV量)/(24小時*60分*60秒*40%)) 。

計算結(jié)果：

500萬DAU ，估算會產(chǎn)生10倍比率的商品頁面PV訪問

((80%*500萬*10倍)/(24小時*60分*60秒*40%)) = 1157個請求/秒

1157個請求/秒 *3倍=3471個請求/秒

3.3、訂單下單

計算模型：

習(xí)慣以3%-5%的日活躍用戶下單比例來推算用戶的訂單數(shù)，每個訂單會產(chǎn)生10個請求

每秒處理請求的數(shù)量=((80%*日活躍用戶數(shù)量*5%)/(24小時*60分*60秒*40%)) 。

計算結(jié)果：

((80%*500萬*5%*10)/(24小時*60分*60秒*40%)) = 60個請求/秒

60個請求/秒*3倍=180個請求/秒

3.4、秒殺

計算模型：

習(xí)慣以1%的日活躍用戶同一時間參與秒殺，

計算結(jié)果：

500萬*1% = 50，000個請求/秒

4、高并發(fā)常用技術(shù)

在B2C網(wǎng)站架構(gòu)設(shè)計中，將通過如下方法保持大數(shù)據(jù)量情況下網(wǎng)站系統(tǒng)的高性能：

4.1動靜分離與數(shù)據(jù)緩存

數(shù)據(jù)庫訪問的性能往往是網(wǎng)站性能的瓶頸。

根據(jù)經(jīng)驗數(shù)據(jù)，用戶在訪問互聯(lián)網(wǎng)站時，超過90%的操作只是讀取數(shù)據(jù)，提交、修改數(shù)據(jù)不到10%。因此可以將內(nèi)容相對固定、主要供用戶瀏覽的頁面（如產(chǎn)品展示頁面）生成緩存，而無須訪問數(shù)據(jù)庫。這樣，可以大幅度提高網(wǎng)站性能。




對于靜態(tài)內(nèi)容（網(wǎng)頁、圖片、音頻文件、腳本文件等）可以選擇CDN（Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)）方式發(fā)布，從而通過專業(yè)內(nèi)容發(fā)布服務(wù)提高網(wǎng)站訪問速度。

頻繁修改的數(shù)據(jù)可以采用緩存的辦法處理。Redis功能強大、簡單易用，支持分布式數(shù)據(jù)處理，是商城平臺常用的緩存方案。

4.2數(shù)據(jù)庫集群和應(yīng)用集群

可以配置數(shù)據(jù)庫集群，實現(xiàn)讀寫分離。選用MySQL數(shù)據(jù)庫，主數(shù)據(jù)庫負責(zé)處理數(shù)據(jù)寫入操作，對于單純讀操作，分發(fā)給從數(shù)據(jù)庫處理。數(shù)據(jù)發(fā)生更改時，主數(shù)據(jù)庫自動同步數(shù)據(jù)到從數(shù)據(jù)庫。從而提高數(shù)據(jù)庫整體性能?？梢愿鶕?jù)需要配置多臺從數(shù)據(jù)庫服務(wù)器。也可以根據(jù)業(yè)務(wù)發(fā)展隨時增加。

4.3負載均衡

對于應(yīng)用服務(wù)器、數(shù)據(jù)庫集群均配置負載均衡，充分利用系統(tǒng)資源。

4.4 數(shù)據(jù)庫

數(shù)據(jù)庫系統(tǒng)性能是網(wǎng)站性能的瓶頸。

通過配置數(shù)據(jù)庫集群，實現(xiàn)讀寫分離之外，還可以通過多種技術(shù)手段提高數(shù)據(jù)庫訪問性能。如下：

數(shù)據(jù)庫分表：同一個數(shù)據(jù)表中，不同字段讀寫頻率存在差異，或者存在大字段時，采用縱向分表，從而降低數(shù)據(jù)庫I/O次數(shù)，提高性能；一個數(shù)據(jù)庫表中數(shù)據(jù)條目增多，查詢性能低下時，采取橫向分表策略，減少單個表中數(shù)據(jù)條目數(shù)。




充分利用索引：分析用戶查詢行為，合理建立索引。

4.5程序

采用技術(shù)手段對程序和頁面進行優(yōu)化，充分利用緩存。

4.6秒殺的程序常用技術(shù)

1，隨機丟棄，減少進入核心邏輯的請求。

2，多層篩選，平均核心邏輯的IO。

3，緩存，消息隊列，保證業(yè)務(wù)和數(shù)據(jù)正確，開啟多個服務(wù)節(jié)點處理消息隊列，當(dāng)沒有庫存后，拋棄隊列里的剩余請求。

1. 微服務(wù)下高并發(fā)指標(biāo)

針對B2B2C多用戶商城的設(shè)計思路， 以下指標(biāo)經(jīng)過實踐得出， 詳見下一篇文章（springcloud微服務(wù)高并發(fā)設(shè)計）

說到微服務(wù)，在和大家討論時發(fā)現(xiàn)最大的問題是，是否要落地實踐微服務(wù)？因為很多企業(yè)并沒有達到所需的規(guī)模，所以，在準(zhǔn)備實踐微服務(wù)之前需要考量的幾個問題是：

·數(shù)據(jù)量和業(yè)務(wù)復(fù)雜度有沒有達到，若是一個庫或一個集群即可搞定，那么建議不要去考慮微服務(wù)的問題，大型企業(yè)有很多數(shù)據(jù)庫集群去支撐業(yè)務(wù)，此時，才應(yīng)該去考慮實踐微服務(wù)。

·團隊規(guī)模，若團隊只有十幾個人，很多傳統(tǒng)WEB三層結(jié)構(gòu)就可以滿足需求也無需去考慮微服務(wù)，除非團隊規(guī)模達到上百人，拆分成十幾二十幾個團隊，溝通比較困難時去考慮微服務(wù)是比較好的。

·應(yīng)對大規(guī)模流量并發(fā)，很多企業(yè)將原來系統(tǒng)的業(yè)務(wù)開了互聯(lián)網(wǎng)接口就送出去，此時會遇到很多高流量高并發(fā)的問題，此時需要考慮是否要轉(zhuǎn)向微服務(wù)，因為傳統(tǒng)架構(gòu)很難應(yīng)對突發(fā)性流量問題。

·是否需求足夠的容錯容災(zāi)，不要認為所有的系統(tǒng)都需求100%可靠，對于很多企業(yè)而言，一些系統(tǒng)停機一天或幾個小時并不重要，其實并非任何系統(tǒng)都要做高可用，是否需要自動恢復(fù)，運維強度等都是需要考慮的問題。

·功能重復(fù)度和維護差錯成本，系統(tǒng)規(guī)模越大，功能的重復(fù)也越高，現(xiàn)在企業(yè)里有很多系統(tǒng)，都要進行認證授權(quán)，其實可以單獨考慮，否則每個系統(tǒng)都要進行一次，而且并不相同。

若以上問題都不存在，建議還是以三層結(jié)構(gòu)的模式，不要給自己挖坑跳不出來，并非所有企業(yè)度適合微服務(wù)。




5.1、平臺首頁： 1157個請求/秒 *3倍=3471個請求/秒。（系統(tǒng)要求）

微服務(wù)性能理論可以達到指標(biāo)：6000請求/秒

5.2、商品頁面 1157個請求/秒 *3倍=3471個請求/秒。（系統(tǒng)要求）

微服務(wù)性能理論可以達到指標(biāo)：6000請求/秒

5.3、訂單下單 60個請求/秒*3倍=180個請求/秒。（系統(tǒng)要求）

微服務(wù)性能理論可以達到指標(biāo)：300請求/秒

5.4、秒殺 500萬*1% = 50，000個請求/秒。（系統(tǒng)要求）

微服務(wù)性能理論可以達到指標(biāo)：100，000請求/秒

以上是一些實踐思路， 歡迎更多同行相互交流

http://www.legendshop.cn