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

作者：李玥

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

06 小結

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

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

▲圖3-2 商品系統(tǒng)的存儲結構

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

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

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

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

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

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

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

點擊上圖了解及購買

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

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

刷刷視頻👇

干貨直達👇

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

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

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

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

更多精彩👇

在公眾號對話框輸入以下關鍵詞

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

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

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

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

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

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

👇

總結

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

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