導讀：本文將探討如何設(shè)計一個快速、可靠的商品系統(tǒng)存儲架構(gòu)。

作者：李玥

來源：大數(shù)據(jù)DT（ID：hzdashuju）

電商的商品系統(tǒng)所包含的主要功能就是增、刪、改、查商品信息，業(yè)務(wù)邏輯比較簡單，支撐的主要頁面就是商品詳情頁。盡管如此，在設(shè)計商品系統(tǒng)的存儲架構(gòu)時，仍然需要著重考慮如下兩個方面的問題。

第一，需要考慮高并發(fā)的問題。不管是哪種電商系統(tǒng)，商品詳情頁一定是整個系統(tǒng)中DAU（Daily Active User，日均訪問人數(shù)）最高的頁面之一。

商品詳情頁DAU高的原因與用戶使用電商App的習慣息息相關(guān)，絕大部分用戶瀏覽完商品詳情頁之后不一定會購買，但購買之前一定會瀏覽很多同類商品的詳情頁，正所謂“貨比三家”。

所以商品詳情頁的瀏覽次數(shù)要遠高于系統(tǒng)的其他頁面。如果在設(shè)計商品系統(tǒng)的存儲架構(gòu)時，沒有考慮到高并發(fā)的問題，那么在電商系統(tǒng)舉辦大促活動的時候，海量的瀏覽請求會在促銷開啟的那一刻同時涌向我們的系統(tǒng)，支撐商品詳情頁的商品系統(tǒng)必然是第一個被流量沖垮的系統(tǒng)。

第二，需要考慮商品數(shù)據(jù)規(guī)模的問題。商品詳情頁的數(shù)據(jù)規(guī)模，可以總結(jié)為如下六個字：數(shù)量多，體量大。

為什么說“數(shù)量多”？在國內(nèi)一線的電商平臺中，SKU（Stock Keeping Unit，庫存單元，在電商行業(yè)也可以直接將其理解為“商品”）的數(shù)量大約在幾億到幾十億這個量級。當然，實際上并沒有這么多種。

商品數(shù)量級這么大的原因有很多，比如，同一個商品通常會有數(shù)種不同的版本型號，再比如，商家為了促銷需要，可能會反復(fù)上下架同一個商品，或者為同一個商品加上不同的“馬甲”，這些原因都導致了SKU數(shù)量巨大。

為什么說“體量大”？我們可以打開一個商品詳情頁看一下，從上一直拉到底，看看頁面有多長？一般來說都在10個屏幕高度左右，并且這其中不僅包含了大量的文字，還會包含大量的圖片和視頻，甚至還包含了AR/VR的玩法。所以說，每個商品詳情頁都是一個“大胖子”。

商品系統(tǒng)的存儲架構(gòu)，需要保存這么多的“大胖子”，還要滿足高并發(fā)的需求，任務(wù)非常艱巨。

01 商品系統(tǒng)需要保存哪些數(shù)據(jù)

本節(jié)就來討論商品詳情頁需要保存哪些信息，下面將商品詳情頁里的所有信息都總結(jié)在了圖3-1所示的思維導圖中。

▲圖3-1 商品詳情頁所含信息思維導圖

在圖3-1中，右邊灰色部分所列舉的信息，均來自電商平臺的其他系統(tǒng)，我們暫且不討論；左邊黑色部分所列舉的信息，都是商品系統(tǒng)需要存儲的內(nèi)容。

那么，應(yīng)該如何存儲這么多內(nèi)容呢？能不能像保存訂單數(shù)據(jù)那樣，設(shè)計一張商品表，把這些數(shù)據(jù)全部存放進去？或者說，一張表存不下就再加幾張子表，這樣存儲行不行？其實并不是不可以，現(xiàn)今的一線電商企業(yè)，在發(fā)展的早期階段采用的就是這種存儲結(jié)構(gòu)。而現(xiàn)今它們所采用的復(fù)雜的分布式存儲架構(gòu)，都是在發(fā)展的過程中逐步演進而來的。

用數(shù)據(jù)庫表存儲的好處就是“糙、快、猛”，簡單、可靠而且容易實現(xiàn)，但是缺點是，表能支撐的數(shù)據(jù)量有限，以及無法滿足高并發(fā)的需求。如果只是低成本且快速構(gòu)建一個小規(guī)模的電商，這可能會是相對比較合理的選擇。

當然，規(guī)模一旦變大，就不能再采用數(shù)據(jù)庫表存儲這種簡單粗暴的方案了。如果不能用數(shù)據(jù)庫，那么我們應(yīng)該選擇哪種存儲系統(tǒng)來保存這么復(fù)雜的商品數(shù)據(jù)呢？

在目前的情況下，任何一種存儲方案都無法完全滿足需求，最好的解決方案是分而治之，即把商品系統(tǒng)需要存儲的數(shù)據(jù)，按照特點分成商品基本信息、商品參數(shù)、圖片視頻和商品介紹幾個部分，分別進行存儲。

02 如何存儲商品的基本信息

首先，我們分析一下商品的基本信息，其中主要包括商品的主副標題、價格、顏色等一些最基本、最主要的屬性。這些屬性都是固定的，不太可能會因為需求改變或不同的商品而變化。而且這部分數(shù)據(jù)不會太大，所以，建議在數(shù)據(jù)庫中建一張表來保存商品的基本信息。

然后，我們還需要在數(shù)據(jù)庫前面加一個緩存，以幫助數(shù)據(jù)庫抵擋絕大部分的讀請求。可以使用Redis或Memcached實現(xiàn)緩存，這兩種存儲系統(tǒng)都是基于內(nèi)存的KV（Key-Value）存儲，都能很好地解決問題。

接下來我們簡單說一下，如何使用前置緩存來緩存商品數(shù)據(jù)。

處理商品信息的讀請求時，需要先到緩存中查找，如果找到對應(yīng)的商品信息，就直接返回緩存中的數(shù)據(jù)。如果在緩存中沒找到，就去數(shù)據(jù)庫中查找，然后把從數(shù)據(jù)庫中查到的商品信息返回給頁面，同時把數(shù)據(jù)存放在緩存中。

更新商品信息的時候，在更新數(shù)據(jù)庫的同時，緩存中的相關(guān)數(shù)據(jù)也要一并刪除。否則就有可能會出現(xiàn)如下這種情況：數(shù)據(jù)庫中的數(shù)據(jù)發(fā)生了改變，而緩存中的數(shù)據(jù)沒有變，商品詳情頁上看到的還是舊數(shù)據(jù)。

這種緩存更新的策略，稱為Cache Aside，是一種最簡單實用的緩存更新策略，適用范圍也最廣。如果想要緩存數(shù)據(jù)，若無特殊情況，則應(yīng)該首先考慮使用Cache Aside策略。除了Cache Aside以外，還有Read/Write Through、Write Behind等幾種策略，分別適用于不同的情況，后面的章節(jié)會有專門的講解。

設(shè)計商品基本信息表的時候，需要特別注意的一點是，一定要記得保留商品數(shù)據(jù)的每一個歷史版本。因為商品數(shù)據(jù)是隨時變化的，但是訂單中關(guān)聯(lián)的商品數(shù)據(jù)，必須是下單那個時刻的商品數(shù)據(jù)，這一點很重要。解決方案是，為每個歷史版本的商品數(shù)據(jù)保存一個快照，可以創(chuàng)建一個歷史表保存到MySQL中，也可以保存到一些KV存儲中。

03 使用MongoDB保存商品參數(shù)

本節(jié)就來分析如何保存商品參數(shù)，商品參數(shù)就是商品的特征，比如，電腦的內(nèi)存大小、手機的屏幕尺寸、酒的度數(shù)、口紅的色號，等等。與商品的基本屬性一樣，參數(shù)也是結(jié)構(gòu)化的數(shù)據(jù)。關(guān)于參數(shù)，需要解決的一個難題是，不同類型的商品，其參數(shù)是完全不一樣的。

如果要設(shè)計一個商品參數(shù)表，那么這個表所要包含的字段就太多了，并且每增加一個品類的商品，這個表就要加入新的字段，所以這個方案行不通。

既然一個表不能解決問題，那就每個類別分別建一張表。比如，建一個電腦參數(shù)表，其中包含的字段有CPU型號、內(nèi)存大小、顯卡型號、硬盤大小，等等；再建一個酒類參數(shù)表，其中包含的字段有酒精度數(shù)、香型、產(chǎn)地，等等。

如果品類比較少（在100個以內(nèi)），那么用幾十張表分別保存不同品類商品參數(shù)的做法也是可以的。但是這并不是一個很好的解決方法，那么還有沒有更好的方法呢？

大多數(shù)數(shù)據(jù)庫，都要求數(shù)據(jù)表要有一個固定的結(jié)構(gòu)，但有一種數(shù)據(jù)庫沒有這個要求，特別適合用于保存像“商品參數(shù)”這種屬性不固定的數(shù)據(jù)，這個數(shù)據(jù)庫就是MongoDB。

MongoDB是一個面向文檔存儲的NoSQL數(shù)據(jù)庫，在MongoDB中，表、行、列對應(yīng)的概念分別是collection、document、field，這些概念總體上可以一一對應(yīng)，但會有一些細微的差別。為了便于理解，我們不必拘泥于具體的文字表達，下文還是用“表、行、列”來說明。

MongoDB最大的特點是，它的“表結(jié)構(gòu)”是不需要事先定義的。其實，在MongoDB中根本就沒有表結(jié)構(gòu)。由于沒有表結(jié)構(gòu)，因此MongoDB可以把任意數(shù)據(jù)都放在同一張表里，甚至還可以在一張表里保存商品數(shù)據(jù)、訂單數(shù)據(jù)、物流信息這些結(jié)構(gòu)完全不同的數(shù)據(jù)。除此之外，MongoDB還支持按照數(shù)據(jù)的某個字段進行查詢。

它是怎么做到的呢？MongoDB中的每一行數(shù)據(jù)，只是簡單地把數(shù)據(jù)轉(zhuǎn)化成BSON格式后存在存儲層中，BSON就是一種更緊湊的JSON。所以，即使是在同一張表中，每一行數(shù)據(jù)的結(jié)構(gòu)也可以是不一樣的。當然，這種靈活性也是需要付出代價的，MongoDB不支持SQL、多表聯(lián)查，且對復(fù)雜事務(wù)的處理能力比較弱，不太適合用來存儲一般的數(shù)據(jù)。

不過，MongoDB可以很好地滿足商品參數(shù)信息數(shù)據(jù)量大、數(shù)據(jù)結(jié)構(gòu)不統(tǒng)一等特性，而且我們也不需要對商品參數(shù)進行事務(wù)和多表聯(lián)查，因此MongoDB簡直就像是為了保存商品參數(shù)量身定制的數(shù)據(jù)庫一樣。

04 使用對象存儲保存圖片和視頻

圖片和視頻由于所占用的存儲空間比較大，因此一般的存儲方式是，在數(shù)據(jù)庫中只保存圖片和視頻的ID或URL，實際的圖片和視頻則以文件的方式單獨存儲。

現(xiàn)今，圖片和視頻的存儲技術(shù)已經(jīng)非常成熟了，首選的方式是保存在對象存儲（Object Storage）中。各大云廠商都提供了對象存儲服務(wù)，比如，國內(nèi)的七牛云、AWS的S3，等等，除此之外，還有開源的對象存儲產(chǎn)品，比如，MinIO可以私有化部署。雖然每個產(chǎn)品的API各不相同，但功能大同小異。

對象存儲可以簡單理解為一個無限容量的大文件KV存儲，它的存儲單位是對象，其實就是文件，可以是一張圖片、一個視頻，也可以是其他任何文件。每個對象都有一個唯一的鍵（key），通過這個鍵，我們可以隨時訪問對應(yīng)的對象。對象存儲的基本功能包括寫入、訪問和刪除對象，大部分對象存儲不支持修改對象的內(nèi)容。

云服務(wù)廠商的對象存儲大多提供了客戶端API，可以在Web頁面或App中直接訪問，而不用通過后端服務(wù)來中轉(zhuǎn)。這樣，App和Web頁面在上傳圖片和視頻的時候，可以直接保存到對象存儲中，然后把對應(yīng)的鍵保存在商品系統(tǒng)中就可以了。

訪問圖片和視頻的時候，真正的圖片和視頻文件，也不需要經(jīng)過商品系統(tǒng)的后端服務(wù)進行讀取，而是在Web頁面上通過對象存儲提供的URL直接訪問，這種方式既省時省力又節(jié)約帶寬。而且?guī)缀跛械膶ο蟠鎯υ品?wù)都自帶CDN（Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)）加速服務(wù)，響應(yīng)時間比直接請求業(yè)務(wù)的服務(wù)器更短。

國內(nèi)很多云廠商提供的對象存儲，對圖片和視頻都進行了大量有針對性的優(yōu)化。其中最有用的是縮放圖片和視頻轉(zhuǎn)碼，只需要把圖片和視頻存放到對象存儲中，就可以隨時獲得任意尺寸大小的圖片，視頻也會自動轉(zhuǎn)碼成各種格式和碼率的版本，適配各種App和場景，使用體驗非常好。

05 將商品介紹靜態(tài)化

商品介紹在商品詳情頁中所占的比重是最大的，其中包含了大量的帶格式文字、圖片和視頻。圖片和視頻自然要存放在對象存儲中，而關(guān)于商品介紹的文本，則一般是隨著商品詳情頁一起靜態(tài)化，保存在HTML文件中。

什么是靜態(tài)化呢？靜態(tài)化是相對于動態(tài)頁面來說的。一般來說，部署到Tomcat中的Web系統(tǒng)，返回的都是動態(tài)頁面，即服務(wù)端程序在處理Web請求時動態(tài)生成的頁面。

比如，用戶在App或Web頁面打開一個商品詳情頁時，一個帶著相應(yīng)的SKUID參數(shù)的HTTP請求將被發(fā)送到后端的Web服務(wù)中，也就是Tomcat中的商品詳情頁模塊。然后這個Web服務(wù)將訪問各種數(shù)據(jù)庫、調(diào)用其他微服務(wù)獲取數(shù)據(jù)，將該商品詳情頁中的數(shù)據(jù)動態(tài)拼在一起，返回給瀏覽器。

不過，現(xiàn)在基本上已經(jīng)沒有系統(tǒng)再采用上述這種方式了。因為對于每個SKU的商品詳情頁，每次動態(tài)生成的頁面內(nèi)容都是完全一樣的，而且還會多次生成，上述方式不僅浪費服務(wù)器資源，而且速度還慢。更關(guān)鍵的問題是，Tomcat能支撐的并發(fā)量，與Nginx完全不是一個數(shù)量級的。

由于商品詳情頁的絕大部分內(nèi)容都是商品介紹，這部分內(nèi)容基本上是不會頻繁改變的，因此一個比較好的解決方案是事先就生成好頁面的內(nèi)容，將其保存成一個靜態(tài)的HTML文件，訪問商品詳情頁的時候，直接返回該HTML文件即可。這就是靜態(tài)化。

商品詳情頁靜態(tài)化之后，不僅可以節(jié)省服務(wù)器資源，還可以利用CDN加速，把商品詳情頁放到離用戶最近的CDN服務(wù)器上，讓商品詳情頁的訪問變得更快。

至于商品價格、促銷信息等這些需要頻繁變動的信息，由于不能將其靜態(tài)化到頁面中，因此可以在前端頁面，使用AJAX請求商品系統(tǒng)動態(tài)獲取。這樣就既兼顧了靜態(tài)化帶來的優(yōu)勢，也能解決商品價格等信息需要實時更新的問題。

06 小結(jié)

本文主要介紹了商品系統(tǒng)分而治之的存儲架構(gòu)。商品系統(tǒng)的存儲需要保存商品的基本信息、商品參數(shù)、圖片和視頻，以及商品介紹等數(shù)據(jù)。商品的基本信息和商品參數(shù)分別保存在MySQL和MongoDB中，用Redis作為前置緩存，圖片和視頻存放在對象存儲中，商品介紹則隨著商品詳情頁一起靜態(tài)化到HTML文件中。

總結(jié)下來，商品系統(tǒng)的存儲結(jié)構(gòu)可以用圖3-2來描述。

▲圖3-2 商品系統(tǒng)的存儲結(jié)構(gòu)

這樣一個商品系統(tǒng)的存儲結(jié)構(gòu)，其最終的效果是怎樣的？圖3-2中的實線表示每訪問一次商品詳情頁，需要真正傳輸?shù)臄?shù)據(jù)；虛線表示當商品詳情頁的數(shù)據(jù)發(fā)生變化時，才需要進行傳輸?shù)臄?shù)據(jù)。

用戶打開一個SKU的商品詳情頁時，首先會去CDN獲取商品詳情頁的HTML文件，然后訪問商品系統(tǒng)獲取價格等會頻繁發(fā)生變化的信息，這些信息可以從Redis緩存中獲取。圖片和視頻信息，則是從對象存儲的CDN中獲取。

下面就來分析一下效果。數(shù)據(jù)量最大的圖片、視頻和商品介紹都是從離用戶最近的CDN服務(wù)器上獲取的，速度快，且節(jié)約帶寬。真正需要觸達商品系統(tǒng)的請求，只是價格等需要動態(tài)獲取的商品信息，一般情況下做一次Redis查詢就可以了，基本上不會有請求到達MySQL中。

綜上所述，商品系統(tǒng)的存儲架構(gòu)把大部分請求都轉(zhuǎn)移到了既便宜速度又快的CDN服務(wù)器上，因此這種架構(gòu)方式可以用少量的服務(wù)器和帶寬資源支撐起大量的并發(fā)請求。

關(guān)于作者：李玥，美團基礎(chǔ)技術(shù)部高級技術(shù)專家，極客時間《后端存儲實戰(zhàn)課》《消息隊列高手課》等專欄作者。曾在浪潮集團、當當網(wǎng)、京東零售等公司任職。從事互聯(lián)網(wǎng)電商行業(yè)基礎(chǔ)架構(gòu)領(lǐng)域的架構(gòu)設(shè)計和研發(fā)工作多年，曾多次參與雙十一和618電商大促。專注于分布式存儲、云原生架構(gòu)下的服務(wù)治理、分布式消息和實時計算等技術(shù)領(lǐng)域，致力于推進基礎(chǔ)架構(gòu)技術(shù)的創(chuàng)新與開源。?

本文摘編自《電商存儲系統(tǒng)實戰(zhàn)：架構(gòu)設(shè)計與海量數(shù)據(jù)處理》，經(jīng)出版方授權(quán)發(fā)布。（ISBN：978-7-111-69741-1）

延伸閱讀《電商存儲系統(tǒng)實戰(zhàn)》

點擊上圖了解及購買

轉(zhuǎn)載請聯(lián)系微信：DoctorData

推薦語：基于實戰(zhàn)案例系統(tǒng)講解電商系統(tǒng)的存儲設(shè)計，詳細分析不同規(guī)模存儲系統(tǒng)的構(gòu)建方法。

刷刷視頻👇

干貨直達👇

• 首次公開，用了三年的 pandas 速查表！
  

• 盤點數(shù)據(jù)治理的6個價值
  

• 3.14圓周率節(jié)，這5本書帶你領(lǐng)略數(shù)學的魅力

• 終于有人把辛普森悖論講明白了

更多精彩👇

在公眾號對話框輸入以下關(guān)鍵詞

查看更多優(yōu)質(zhì)內(nèi)容！

讀書?|?書單?|?干貨?|?講明白?|?神操作?|?手把手

大數(shù)據(jù)?|?云計算?|?數(shù)據(jù)庫?|?Python?|?爬蟲?|?可視化

AI?|?人工智能?|?機器學習?|?深度學習?|?NLP

5G?|?中臺?|?用戶畫像?|?數(shù)學?|?算法?|?數(shù)字孿生

據(jù)統(tǒng)計，99%的大咖都關(guān)注了這個公眾號

👇

總結(jié)

以上是生活随笔為你收集整理的4918字，详解商品系统的存储架构设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。