有一類業(yè)務(wù)場(chǎng)景，數(shù)據(jù)沒有固定的模式（schema）存儲(chǔ)，卻有著海量的數(shù)據(jù)行數(shù)，該如何從架構(gòu)層面實(shí)現(xiàn)這類業(yè)務(wù)的存儲(chǔ)與檢索呢？比如要處理 1 萬種屬性、100 億條數(shù)據(jù)，還得支撐每秒 10 萬次的吞吐，今天就和大家聊聊 “電商商品多維度信息業(yè)務(wù)” 的架構(gòu)設(shè)計(jì)實(shí)踐。

一、背景與業(yè)務(wù)介紹

電商平臺(tái)的核心數(shù)據(jù)

電商平臺(tái)涵蓋眾多商品品類，像數(shù)碼產(chǎn)品、服裝鞋帽、家居用品、美妝護(hù)膚、食品飲料等，每個(gè)品類又包含諸多子品類。而無論哪個(gè)品類，“商品信息” 都是最核心的數(shù)據(jù)，這就類似一個(gè)大型的線上商品集市。

各分類商品信息的特點(diǎn)

經(jīng)常網(wǎng)購(gòu)的人很容易發(fā)現(xiàn)，這類平臺(tái)的商品信息有以下特點(diǎn)：

• 不同品類的屬性差異極大，數(shù)碼產(chǎn)品和服裝的屬性完全不同，就連手機(jī)和電腦的屬性也不一樣，目前屬性數(shù)量已接近一萬種；
• 數(shù)據(jù)量極為龐大，達(dá)到 100 億級(jí)別；
• 每個(gè)屬性都存在查詢需求，各組合屬性也可能有組合查詢需求，比如手機(jī)要查詢品牌、內(nèi)存、價(jià)格范圍，服裝要查詢尺碼、顏色、材質(zhì)，家居用品要查詢風(fēng)格、尺寸、功能等；
• 吞吐量很高，每秒能達(dá)到幾十萬次。

那該如何解決 100 億數(shù)據(jù)量、1 萬種屬性、多屬性組合查詢以及每秒 10 萬次并發(fā)查詢的技術(shù)難題呢？我們一步步來分析。

二、最容易想到的初始方案

每個(gè)電商公司都是從小規(guī)模發(fā)展起來的，先不考慮并發(fā)量和數(shù)據(jù)量，看看如何先解決：

• 屬性擴(kuò)展性需求；
• 多屬性組合查詢需求。畢竟公司初期并發(fā)量和數(shù)據(jù)量都不大，得先把業(yè)務(wù)問題解決。

業(yè)務(wù)存儲(chǔ)需求的滿足方式

最開始，業(yè)務(wù)只有手機(jī)這一個(gè)品類，商品表可能是這樣設(shè)計(jì)的：product(tid, uid, brand, model, memory, price)

多屬性組合查詢需求的滿足方式

最容易想到的是通過組合索引來滿足查詢需求，比如：

• index_1(brand, model)
• index_2(model, memory)
• index_3(brand, price)

業(yè)務(wù)擴(kuò)展后的存儲(chǔ)與查詢問題

隨著業(yè)務(wù)發(fā)展，新增了服裝類別，存儲(chǔ)問題可以通過新增若干屬性來解決，此時(shí)商品表變成：

product(tid, uid, brand, model, memory, price, size, color, material)其中，brand、model、memory、price是手機(jī)類別的屬性，size、color、material是服裝類別的屬性。

對(duì)于查詢需求，由于跨業(yè)務(wù)屬性一般沒有組合查詢需求，只能建立若干組合索引來滿足服裝類別的查詢需求。但想想看，要覆蓋所有兩屬性、三屬性查詢，得建多少索引，這顯然不是長(zhǎng)久之計(jì)，業(yè)務(wù)越來越多時(shí)，這種方式就難以維系了。

三、垂直拆分的思路與問題

新增屬性是一種擴(kuò)展方式，新增表也是一種方式，垂直拆分是常見的存儲(chǔ)擴(kuò)展方案。

可以這樣操作：

• product_phone(tid, uid, brand, model, memory, price)（手機(jī)商品表）
• product_clothes(tid, uid, size, color, material, price)（服裝商品表）

垂直拆分帶來的問題

在業(yè)務(wù)多樣、數(shù)據(jù)量和吞吐量都很大的情況下，垂直拆分存在諸多問題：這些表以及對(duì)應(yīng)的服務(wù)由不同部門維護(hù)，看似各業(yè)務(wù)靈活性強(qiáng)、研發(fā)閉環(huán)，但這恰恰是問題的開端：

• 商品 ID（tid）如何規(guī)范？
• 屬性如何規(guī)范？
• 按商家 ID（uid）查詢（查詢商家發(fā)布的所有商品）該怎么辦？
• 按時(shí)間查詢（最新上架的商品）該怎么辦？
• 跨品類查詢（比如首頁搜索框）該怎么辦？
• 技術(shù)范圍擴(kuò)散，有的用 MongoDB 存儲(chǔ)，有的用 MySQL 存儲(chǔ)，有的自研存儲(chǔ)；
• 重復(fù)開發(fā)了不少組件；
• 維護(hù)成本過高。就像大型電商平臺(tái)的商品表，不可能一個(gè)類目一個(gè)表，電商商品信息表也一樣。

四、行業(yè)最佳實(shí)踐：三大中心服務(wù)

第一：統(tǒng)一商品中心服務(wù)

對(duì)于平臺(tái)型電商公司，可能有多個(gè)品類，各品類有很多異構(gòu)數(shù)據(jù)的存儲(chǔ)需求，無需糾結(jié)是分還是合，統(tǒng)一基礎(chǔ)數(shù)據(jù)和基礎(chǔ)服務(wù)是很好的實(shí)踐（這里針對(duì)平臺(tái)型業(yè)務(wù)）。

異構(gòu)數(shù)據(jù)的統(tǒng)一存儲(chǔ)方式

要將不同品類、異構(gòu)的數(shù)據(jù)統(tǒng)一存儲(chǔ)，可采用以下方法：

• 全品類通用屬性統(tǒng)一存儲(chǔ)；
• 單品類特有屬性，通過品類類型與通用屬性的 JSON 來存儲(chǔ)。

更具體的設(shè)計(jì)是，商品表結(jié)構(gòu)為：product(tid, uid, time, name, cate, subcate, xxid, ext)。其中：

• 一些通用字段被單獨(dú)抽取出來存儲(chǔ)；
• 通過cate、subcate、xxid來定義ext的含義；
• 通過ext來存儲(chǔ)不同業(yè)務(wù)線的個(gè)性化需求。

例如，手機(jī)商品的ext可以是：{"brand":"Apple","model":"iPhone 15","memory":"256G","price":6999}；服裝商品的ext可以是：{"size":"L","color":"blue","material":"cotton","price":299}。

商品數(shù)據(jù)有 100 億條，分 256 個(gè)庫(kù)，通過ext存儲(chǔ)異構(gòu)業(yè)務(wù)數(shù)據(jù)，使用 MySQL 存儲(chǔ)，上層搭建一個(gè)商品中心服務(wù)，并用 Redis 做緩存，這樣一個(gè)并不復(fù)雜的架構(gòu)，就解決了業(yè)務(wù)的大問題。這就是電商平臺(tái)最核心的商品中心服務(wù) PMC（Product Management Center）。

新問題的出現(xiàn)

解決了海量異構(gòu)數(shù)據(jù)的存儲(chǔ)問題后，又出現(xiàn)了新問題：

• 每條記錄的ext內(nèi)的鍵（key）都需要重復(fù)存儲(chǔ)，占用大量空間，能否壓縮存儲(chǔ)？
• 品類 ID（cateid）已不足以描述ext內(nèi)的內(nèi)容，品類有不確定的層級(jí)，ext能否具備自描述性？
• 能否隨時(shí)增加屬性，保證擴(kuò)展性？

解決完海量異構(gòu)數(shù)據(jù)的存儲(chǔ)問題，接下來要解決類目的擴(kuò)展性問題。

第二：統(tǒng)一類目屬性服務(wù)

每個(gè)業(yè)務(wù)有多少屬性、這些屬性的含義、值的約束等，如果耦合到商品服務(wù)里顯然不合理，那該怎么辦呢？

可以抽象出一個(gè)統(tǒng)一的類目、屬性服務(wù)，單獨(dú)管理這些信息，并且商品庫(kù)ext字段里的 JSON 鍵，統(tǒng)一用數(shù)字表示，以減少存儲(chǔ)空間。

商品表只存儲(chǔ)元信息，不涉及業(yè)務(wù)含義。比如，JSON 里的鍵不再是 “brand”“model”“size” 這樣的長(zhǎng)字符串，而是用數(shù)字 1、2、3、4 代替。這些數(shù)字的含義、所屬子分類、值的校驗(yàn)約束，統(tǒng)一存儲(chǔ)在類目、屬性服務(wù)里。

類目表存儲(chǔ)業(yè)務(wù)信息以及約束信息，與商品表解耦。這個(gè)表會(huì)對(duì)商品中心服務(wù)里ext字段的數(shù)字鍵進(jìn)行解釋，比如：

圖片

• 數(shù)字 1 代表 “brand”，屬于數(shù)碼品類下的手機(jī)子品類，其值必須是品牌枚舉值；
• 數(shù)字 4 代表 “size”，屬于服裝品類下的上衣子品類，其值必須是尺碼枚舉值（S、M、L 等）。

這樣，原來商品表的ext擴(kuò)展屬性就變成了：{"1":"Apple","2":"iPhone 15","3":"256G","4":6999}和{"5":"L","6":"blue","7":"cotton","8":299}（服裝商品），鍵和值都有了統(tǒng)一約束。

此外，如果ext里某個(gè)鍵的值不是通過正則校驗(yàn)，而是枚舉值，就需要有一個(gè)枚舉表來對(duì)值進(jìn)行限定校驗(yàn)。比如，當(dāng)ext為{"5":"XL","6":"blue","7":"cotton","8":299}時(shí)，因?yàn)殒I 5 對(duì)應(yīng)的屬性（服裝、上衣尺碼字段）的值需要是固定枚舉值（S、M、L 等），而 “XL” 不符合，所以這個(gè)ext是不合法的，合法的應(yīng)該是{"5":"L","6":"blue","7":"cotton","8":299}。

另外，類目屬性服務(wù)還能記錄類目之間的層級(jí)關(guān)系，比如：

• 一級(jí)類目有數(shù)碼、服裝、家居等；
• 數(shù)碼下有二級(jí)類目手機(jī)、電腦等；
• 手機(jī)下有三級(jí)類目蘋果手機(jī)、華為手機(jī)、小米手機(jī)等。

類目服務(wù)解釋了商品數(shù)據(jù)，描述了品類層級(jí)關(guān)系，保證了各類目屬性的擴(kuò)展性，也保證了各屬性值的合理性校驗(yàn)，這就是電商平臺(tái)另一個(gè)統(tǒng)一的核心服務(wù) CMC（Category Management Center）。

這就類似于電商系統(tǒng)里的商品屬性擴(kuò)展服務(wù)：

• 品類層級(jí)關(guān)系對(duì)應(yīng)電商里的類別層級(jí)體系；
• 屬性擴(kuò)展對(duì)應(yīng)電商里各類別商品的屬性；
• 枚舉值校驗(yàn)對(duì)應(yīng)屬性的枚舉值，比如手機(jī)品牌有蘋果、華為、小米等。

通過品類服務(wù)，解決了鍵的壓縮、描述、擴(kuò)展以及值的校驗(yàn)、品類層級(jí)等問題，但還有一個(gè)問題沒解決：每個(gè)品類下商品的屬性不同，查詢需求也不同，如何解決 100 億數(shù)據(jù)量、1 萬種屬性的檢索與聯(lián)合檢索需求呢？

第三：統(tǒng)一檢索服務(wù)

當(dāng)數(shù)據(jù)量很大時(shí)，不同屬性上的查詢需求，不可能通過組合索引來滿足所有查詢需求，“外置索引，統(tǒng)一檢索服務(wù)” 是常用的實(shí)踐方法：

• 數(shù)據(jù)庫(kù)提供 “商品 ID” 的正排查詢需求；
• 所有非 “商品 ID” 的個(gè)性化檢索需求，統(tǒng)一通過外置索引來滿足。

圖片

元數(shù)據(jù)與索引數(shù)據(jù)的操作遵循以下規(guī)則：

• 對(duì)商品進(jìn)行商品 ID（tid）正排查詢，直接訪問商品服務(wù)；
• 對(duì)商品進(jìn)行修改時(shí)，商品服務(wù)通知檢索服務(wù)，同時(shí)修改索引；
• 對(duì)商品進(jìn)行復(fù)雜查詢時(shí)，通過檢索服務(wù)來滿足需求。

這個(gè)檢索服務(wù)承擔(dān)了電商平臺(tái) 80% 的請(qǐng)求，不管請(qǐng)求來自 PC 還是 APP，也不管是來自首頁、分類頁、搜索頁、商品列表頁還是詳情頁，最終都會(huì)轉(zhuǎn)化為一個(gè)檢索請(qǐng)求。

搜索引擎架構(gòu)說明

為了應(yīng)對(duì) 100 億級(jí)別的數(shù)據(jù)量、幾十萬級(jí)別的吞吐量以及業(yè)務(wù)線各種復(fù)雜的檢索查詢，擴(kuò)展性是設(shè)計(jì)的重點(diǎn)：

圖片

• 統(tǒng)一的代理層作為入口，由于其無狀態(tài)性，增加機(jī)器就能擴(kuò)充系統(tǒng)性能；
• 統(tǒng)一的結(jié)果聚合層，同樣因?yàn)闊o狀態(tài)性，增加機(jī)器也能擴(kuò)充系統(tǒng)性能；
• 搜索內(nèi)核檢索層，服務(wù)和索引數(shù)據(jù)部署在同一臺(tái)機(jī)器上，服務(wù)啟動(dòng)時(shí)可將索引數(shù)據(jù)加載到內(nèi)存，請(qǐng)求訪問時(shí)從內(nèi)存中讀取數(shù)據(jù)，訪問速度很快。為滿足數(shù)據(jù)容量的擴(kuò)展性，索引數(shù)據(jù)進(jìn)行了水平切分，增加切分份數(shù)就能無限擴(kuò)展性能；為滿足一份數(shù)據(jù)的性能擴(kuò)展性，同一份數(shù)據(jù)進(jìn)行了冗余，理論上增加機(jī)器就能無限擴(kuò)展性能。系統(tǒng)時(shí)延方面，100 億級(jí)別商品檢索，包含請(qǐng)求分合、拉鏈求交集等操作，從聚合層可以做到 10 毫秒返回。

在商品業(yè)務(wù)中，一致性不是主要矛盾，檢索服務(wù)會(huì)定期全量重建索引，以確保即使數(shù)據(jù)存在不一致，也不會(huì)持續(xù)很長(zhǎng)時(shí)間