參考當(dāng)當(dāng)網(wǎng)，京東，海爾等電商峰值策略，不考慮hadoop等高級(jí)框架，整理資料如下提供參考。

首先，設(shè)計(jì)和部署大流量、高并發(fā)系統(tǒng)的技術(shù)方案通常要面對(duì)以下幾大難點(diǎn)。
1. 應(yīng)用架構(gòu)復(fù)雜，業(yè)務(wù)發(fā)展快，迭代速度快，各系統(tǒng)之間盤根錯(cuò)節(jié)，歷史包袱重。不僅有牽一發(fā)而動(dòng)全身的風(fēng)險(xiǎn)，更有邊緣case出錯(cuò)影響主流程處理、耗盡過(guò)多資源的隱患。
2. 從前臺(tái)到后臺(tái)的業(yè)務(wù)流程長(zhǎng)，用例多。在能承受的最大峰值上，存在短板效應(yīng)。設(shè)計(jì)實(shí)現(xiàn)時(shí)要面面俱到。
3. 通常促銷活動(dòng)的持續(xù)時(shí)間短而集中，前期推廣活動(dòng)已經(jīng)啟動(dòng)，在活動(dòng)期間，短暫的系統(tǒng)不可用，也會(huì)帶來(lái)慘重的銷售損失與負(fù)面影響，沒(méi)有亡羊補(bǔ)牢的機(jī)會(huì)。要確保系統(tǒng)的穩(wěn)定性，平時(shí)的工作就要做足。
針對(duì)這些難點(diǎn)，有以下應(yīng)對(duì)策略。
1. 基于SOA架構(gòu)理念，降低系統(tǒng)耦合性，接口定義清晰明確，保證獨(dú)立子系統(tǒng)的健壯性高，降低故障跨系統(tǒng)擴(kuò)散風(fēng)險(xiǎn)，從而將伸縮性的困難逐步分解到各個(gè)系統(tǒng)。
2. 對(duì)系統(tǒng)進(jìn)行分級(jí)，集中力量，突出重點(diǎn)系統(tǒng)。從賣場(chǎng)到交易流程均屬于一級(jí)系統(tǒng)，這部分系統(tǒng)直接關(guān)乎用戶體驗(yàn)和訂單量。在系統(tǒng)穩(wěn)定性和可靠性等指標(biāo)上，設(shè)計(jì)標(biāo)準(zhǔn)高于后臺(tái)系統(tǒng)。
3. 優(yōu)先考慮用異步處理代替同步處理，做好系統(tǒng)異常的降級(jí)方案，保證有限的合格服務(wù)。

前端頁(yè)面系統(tǒng)是電商業(yè)務(wù)的流量入口，需解決的核心問(wèn)題是保證大流量高并發(fā)情況下的快速展示可用，這方面業(yè)界已有較為成熟的解決方案，如CDN、緩存、靜態(tài)化、異步加載、與依賴的數(shù)據(jù)源解耦、同機(jī)部署、數(shù)據(jù)庫(kù)讀寫分離等。通過(guò)這樣的設(shè)計(jì)使前端無(wú)狀態(tài)頁(yè)面應(yīng)用可以水平擴(kuò)展，增加Web服務(wù)器即可提升系統(tǒng)能力。

商品的關(guān)鍵數(shù)據(jù)包括商品基本信息、庫(kù)存和價(jià)格，庫(kù)存和價(jià)格都依賴于商品基本信息，對(duì)于不同類型的數(shù)據(jù)，根據(jù)應(yīng)用場(chǎng)景區(qū)別對(duì)待。平臺(tái)化之后，每個(gè)商品都?xì)w屬于一個(gè)商家，以商家ID為維度進(jìn)行散列，將商品基本信息保存在數(shù)據(jù)庫(kù)中，支持水平擴(kuò)展，可以滿足商品數(shù)據(jù)不斷增長(zhǎng)的需要。對(duì)于歷史版本的商品信息，則遷移至歷史版本庫(kù)，作為訂單交易快照供用戶查詢。庫(kù)存數(shù)據(jù)在前端展示只關(guān)注是否有貨，并不需要將每一次庫(kù)存變化同步，在庫(kù)存變?yōu)?或從0變?yōu)檎麛?shù)時(shí)觸發(fā)狀態(tài)同步，交易下單時(shí)實(shí)時(shí)查詢當(dāng)前庫(kù)存即可，此種變數(shù)量為狀態(tài)的方式極大地減少了同步數(shù)據(jù)量，提高了數(shù)據(jù)一致性。

即便已經(jīng)對(duì)不同類型的商品信息數(shù)據(jù)流進(jìn)行了差異化處理，仍然不能排除短時(shí)間內(nèi)會(huì)發(fā)生大量數(shù)據(jù)造成系統(tǒng)同步阻塞，影響正常業(yè)務(wù)運(yùn)營(yíng)操作的及時(shí)發(fā)布。極端情況下，超出系統(tǒng)處理能力還可能導(dǎo)致系統(tǒng)崩潰。為解決此類問(wèn)題，采用批量、異步、分流、限流等手段進(jìn)行處理。
批量、批次操作：
限制API調(diào)用頻次的同時(shí)，提供批量API供商家對(duì)商品信息進(jìn)行更新，批量更新方式減少了各環(huán)節(jié)交互次數(shù)，提高了系統(tǒng)吞吐量，更好地貼合營(yíng)銷活動(dòng)中批量處理的需求。在系統(tǒng)內(nèi)部，批量方式能夠有效降低系統(tǒng)資源開(kāi)銷，并能對(duì)頻繁更新的商品數(shù)據(jù)進(jìn)行合并處理，提高處理速度，使數(shù)據(jù)更新及時(shí)準(zhǔn)確。
增加異步處理，減少同步處理：
信息流同步經(jīng)過(guò)多個(gè)系統(tǒng)，每個(gè)系統(tǒng)處理邏輯和吞吐能力不同，采用同步機(jī)制可能導(dǎo)致上游系統(tǒng)將下游系統(tǒng)拖垮，因此采用異步機(jī)制最為穩(wěn)妥。異步方式有兩點(diǎn)好處：一方面起到緩沖的作用，下游系統(tǒng)依據(jù)自身能力控制處理數(shù)據(jù)量，避免遭受超負(fù)荷的沖擊，保證系統(tǒng)穩(wěn)定運(yùn)行；另一方面實(shí)現(xiàn)系統(tǒng)隔離解耦，一旦下游系統(tǒng)出現(xiàn)異常，上游系統(tǒng)仍然能正常處理數(shù)據(jù)，不至于引發(fā)連鎖反應(yīng)。
分流：
不同的信息對(duì)處理時(shí)效的要求也不同，庫(kù)存、價(jià)格、商品上下架狀態(tài)同步及時(shí)性要求很高，而商品基本信息，如名稱、副標(biāo)題、詳情則相對(duì)較低。拆分不同的同步路徑，對(duì)及時(shí)性要求高的數(shù)據(jù)配置更多的系統(tǒng)資源，既保障了敏感數(shù)據(jù)的及時(shí)性，又避免了數(shù)據(jù)積壓相互干擾。同理，針對(duì)三種不同的數(shù)據(jù)來(lái)源渠道（ERP、數(shù)字業(yè)務(wù)系統(tǒng)、開(kāi)放平臺(tái)），也可通過(guò)分流方式保證自營(yíng)實(shí)物、電子書和商家商品信息的及時(shí)同步。
限流：
多數(shù)的商品數(shù)據(jù)來(lái)源于商家，商家會(huì)通過(guò)一些第三方系統(tǒng)與開(kāi)放平臺(tái)對(duì)接，調(diào)用API進(jìn)行數(shù)據(jù)同步。一些不合理的同步機(jī)制設(shè)置會(huì)頻繁發(fā)起大量的數(shù)據(jù)同步請(qǐng)求，而多數(shù)請(qǐng)求屬于無(wú)效數(shù)據(jù)，這類數(shù)據(jù)難以識(shí)別，會(huì)浪費(fèi)大量的系統(tǒng)資源，干擾有效數(shù)據(jù)的處理。在開(kāi)放平臺(tái)對(duì)每個(gè)商家調(diào)用API的頻次進(jìn)行限制，根據(jù)商家商品數(shù)量合理分配，有效地抑制了無(wú)效數(shù)據(jù)的泛濫。

分布式：
分布式的交易系統(tǒng)是電商的未來(lái)。分布式系統(tǒng)解決兩大難題：提高用戶體驗(yàn)和增強(qiáng)容錯(cuò)能力。由于分布式系統(tǒng)設(shè)計(jì)時(shí)就會(huì)留有相當(dāng)?shù)牧髁吭鲩L(zhǎng)空間，所以當(dāng)一處數(shù)據(jù)中心飽和時(shí)，可以將其余的流量切入其他相對(duì)寬松的數(shù)據(jù)中心去，從而達(dá)到互為備份、互相支持的目的。與此同時(shí)，由于為提供用戶就近服務(wù)，所以減少了網(wǎng)絡(luò)延時(shí)，頁(yè)面反應(yīng)速度加快了。

邏輯優(yōu)化、算法優(yōu)化和代碼優(yōu)化：

1.優(yōu)化算法，選擇合適高效的算法，降低不必要的遞歸、循環(huán)、多層循環(huán)嵌套等計(jì)算。用簡(jiǎn)單的算法完成大部分情況，不要為少數(shù)特例而將算法復(fù)雜化。特例由特殊的分支處理。
2.避免申請(qǐng)過(guò)多不必要的內(nèi)存開(kāi)銷。
3.及時(shí)釋放資源，降低資源占用時(shí)間，包括內(nèi)存、I/O、網(wǎng)絡(luò)和數(shù)據(jù)庫(kù)等。
4.善用緩存：緩存常用的、不易變化的；偶有變化，可以考慮緩存依賴機(jī)制。
5.慎用數(shù)據(jù)庫(kù)鎖。
6.恰當(dāng)?shù)厥褂檬聞?wù)，事務(wù)要細(xì)粒度。
7.選擇適當(dāng)?shù)耐ㄐ欧绞剑篠ocket、Remoting、Web Services（REST和SOAP）、WCF、 Named Pipes等，要特別注意長(zhǎng)連接和短連接的恰當(dāng)使用。
8.計(jì)算并行化。
9.降低系統(tǒng)或模塊之間的通信次數(shù)，例如工作流服務(wù)和數(shù)據(jù)庫(kù)服務(wù)。
10.降低系統(tǒng)或模塊之間的傳輸數(shù)據(jù)量，不必要傳輸?shù)牟粋骰蛏賯鳌?br>11.異步計(jì)算，降低等待時(shí)間。
12.考慮延遲加載和提前加載兩種方式。
13.分離原則：分離業(yè)務(wù)模塊，如分離大I/O模塊、分離高耗內(nèi)存模塊和分離高耗寬帶模塊。
14.統(tǒng)籌使用計(jì)算資源，如尋求內(nèi)存計(jì)算、數(shù)據(jù)庫(kù)計(jì)算和網(wǎng)絡(luò)開(kāi)銷三者之間的最佳平衡。

最后，為了保障系統(tǒng)性能和伸縮性，不少時(shí)候需要犧牲或者完全拒絕某些功能，或者降低系統(tǒng)的靈活性和擴(kuò)展性等。

在數(shù)據(jù)庫(kù)層允許復(fù)雜的產(chǎn)品存儲(chǔ)結(jié)構(gòu)設(shè)計(jì)，以細(xì)粒度、深度優(yōu)化的關(guān)系模型充分實(shí)現(xiàn)產(chǎn)品數(shù)據(jù)模型的通用性、可擴(kuò)展性。在數(shù)據(jù)模型設(shè)計(jì)時(shí)完全不用關(guān)心客戶端檢索查找的復(fù)雜性和性能問(wèn)題。

產(chǎn)品查詢引擎將復(fù)雜的數(shù)據(jù)存儲(chǔ)模型封裝成一個(gè)簡(jiǎn)單的邏輯模型。這個(gè)邏輯模型實(shí)現(xiàn)的效果，完全等同于產(chǎn)品的所有屬性都存儲(chǔ)在同一張數(shù)據(jù)庫(kù)表中，邏輯模型的每 個(gè)屬性對(duì)應(yīng)數(shù)據(jù)庫(kù)表中的一個(gè)字段。在這個(gè)邏輯模型的基礎(chǔ)上實(shí)現(xiàn)了一個(gè)簡(jiǎn)潔的DSL，供客戶端進(jìn)行檢索查詢?？蛻舳斯ぷ髟谶壿嬆Ｐ秃虳SL之上，檢索查詢簡(jiǎn)單、靈活，同樣完全不用關(guān)心產(chǎn)品數(shù)據(jù)存儲(chǔ)模型的復(fù)雜性和性能問(wèn)題。

產(chǎn)品服務(wù)分不同集群進(jìn)行部署，面向Web應(yīng)用和其他服務(wù)的集群在運(yùn)行期間幾乎不會(huì)產(chǎn)生數(shù)據(jù)庫(kù)請(qǐng)求，因此不管網(wǎng)站訪問(wèn)量和交易量多高，數(shù)據(jù)庫(kù)都不會(huì)產(chǎn)生壓力瓶頸。只需為Web和服務(wù)添加服務(wù)器，實(shí)現(xiàn)了高伸縮目標(biāo)。