1萬屬性，100億資料，每秒10萬吞吐，架構如何設計？

有一類業務場景，沒有固定的schema儲存，卻有著海量的資料行數，架構上如何來實現這類業務的儲存與檢索呢？58最核心的資料“帖子”的架構實現技術細節，今天和大家聊一聊。

一、背景描述及業務介紹

什麼是58最核心的資料？

58是一個資訊平臺，有很多垂直品類：招聘、房產、二手物品、二手車、黃頁等等，每個品類又有很多子品類，不管哪個品類，最核心的資料都是“帖子資訊”。

畫外音：像不像一個大論壇？

各分類帖子的資訊有什麼特點？

逛過58的朋友很容易瞭解到，這裡的帖子資訊：

（1）各品類的屬性千差萬別，招聘帖子和二手帖子屬性完全不同，二手手機和二手家電的屬性又完全不同，目前恐怕有近萬個屬性；

（2）資料量巨大，100億級別；

（3）每個屬性上都有查詢需求，各組合屬性上都可能有組合查詢需求，招聘要查職位/經驗/薪酬範圍，二手手機要查顏色/價格/型號，二手要查冰箱/洗衣機/空調；

（4）吞吐量很大，每秒幾10萬吞吐；

如何解決100億資料量，1萬屬性，多屬性組合查詢，10萬併發查詢的技術難題呢？一步步來。

二、最容易想到的方案

每個公司的發展都是一個從小到大的過程，撇開併發量和資料量不談，先看看

（1）如何實現屬性擴充套件性需求；

（2）多屬性組合查詢需求；

畫外音：公司初期併發量和資料量都不大，必須先解決業務問題。

如何滿足業務的儲存需求呢？

最開始，業務只有一個招聘品類，那帖子表可能是這麼設計的：

tiezi(tid, uid, c1, c2, c3);

那如何滿足各屬性之間的組合查詢需求呢？

最容易想到的是透過組合索引滿足查詢需求：

index_1(c1, c2)

index_2(c2, c3)

index_3(c1, c3)

隨著業務的發展，又新增了一個房產類別，儲存問題又該如何解決呢？

可以新增若干屬性滿足儲存需求，於是帖子表變成了：

tiezi(tid, uid, c1, c2, c3, c10, c11, c12, c13); 

其中：

• c1,c2,c3是招聘類別屬性

• c10,c11,c12,c13是房產類別屬性

透過擴充套件屬性，可以解決儲存的問題。

查詢需求，又該如何滿足呢？

首先，跨業務屬性一般沒有組合查詢需求。只能建立了若干組合索引，滿足房產類別的查詢需求。

畫外音：不敢想有多少個索引能覆蓋所有兩屬性查詢，三屬性查詢。

當業務越來越多時，是不是發現玩不下去了？

三、垂直拆分是一個思路

新增屬性是一種擴充套件方式，新增表也是一種方式，垂直拆分也是常見的儲存擴充套件方案。

如何按照業務進行垂直拆分？

可以這麼玩：

tiezi_zhaopin(tid, uid, c1, c2, c3);

tiezi_fangchan(tid, uid, c10, c11, c12, c13);

在業務各異，資料量和吞吐量都巨大的情況下，垂直拆分會遇到什麼問題呢？

這些表，以及對應的服務維護在不同的部門，看上去各業務靈活性強，研發閉環，這恰恰是悲劇的開始：

（1）tid如何規範？

（2）屬性如何規範？

（3）按照uid來查詢怎麼辦（查詢自己釋出的所有帖子）？

（4）按照時間來查詢怎麼辦（最新發布的帖子）？

（5）跨品類查詢怎麼辦（例如首頁搜尋框）？

（6）技術範圍的擴散，有的用mongo儲存，有的用mysql儲存，有的自研儲存；

（7）重複開發了不少元件；

（8）維護成本過高；

（9）…

畫外音：想想看，電商的商品表，不可能一個類目一個表的。

四、58的玩法：三大中心服務

第一：統一帖子中心服務

平臺型創業型公司，可能有多個品類，各品類有很多異構資料的儲存需求，到底是分還是合，無需糾結：基礎資料基礎服務的統一，是一個很好的實踐。

畫外音：這裡說的是平臺型業務。

如何將不同品類，異構的資料統一儲存起來呢？

（1）全品類通用屬性統一儲存；

（2）單品類特有屬性，品類型別與通用屬性json來進行儲存；

更具體的：

tiezi(tid, uid, time, title, cate, subcate, xxid, ext);

（1）一些通用的欄位抽取出來單獨儲存；

（2）透過cate, subcate, xxid等來定義ext是何種含義；

（3）透過ext來儲存不同業務線的個性化需求

例如：

招聘的帖子，ext為：

{“job”:”driver”,”salary”:8000,”location”:”bj”}

而二手的帖子，ext為：

{”type”:”iphone”,”money”:3500}

 

帖子資料，100億的資料量，分256庫，透過ext儲存異構業務資料，使用mysql儲存，上層架了一個帖子中心服務，使用memcache做快取，就是這樣一個並不複雜的架構，解決了業務的大問題。這是58最核心的帖子中心服務IMC（Info Management Center）。

畫外音：該服務的底層儲存在16年全面切換為了自研儲存引擎，替換了mysql，但架構理念仍未變。

解決了海量異構資料的儲存問題，遇到的新問題是：

（1）每條記錄ext內key都需要重複儲存，佔據了大量的空間，能否壓縮儲存；

（2）cateid已經不足以描述ext內的內容，品類有層級，深度不確定，ext能否具備自描述性；

（3）隨時可以增加屬性，保證擴充套件性；

解決完海量異構資料的儲存問題，接下來，要解決的是類目的擴充套件性問題。

第二：統一類目屬性服務

每個業務有多少屬性，這些屬性是什麼含義，值的約束等，耦合到帖子服務裡顯然是不合理的，那怎麼辦呢？

抽象出一個統一的類目、屬性服務，單獨來管理這些資訊，而帖子庫ext欄位裡json的key，統一由數字來表示，減少儲存空間。

畫外音：帖子表只存元資訊，不管業務含義。

如上圖所示，json裡的key不再是”salary” ”location” ”money” 這樣的長字串了，取而代之的是數字1,2,3,4，這些數字是什麼含義，屬於哪個子分類，值的校驗約束，統一都儲存在類目、屬性服務裡。

畫外音：類目表存業務資訊，以及約束資訊，與帖子表解耦。

這個表裡對帖子中心服務裡ext欄位裡的數字key進行了解釋：

（1）1代表job，屬於招聘品類下100子品類，其value必須是一個小於32的[a-z]字元；

（2）4代表type，屬於二手品類下200子品類，其value必須是一個short；

這樣就對原來帖子表ext擴充套件屬性：

{“1”:”driver”,”2”:8000,”3”:”bj”}

{”4”:”iphone”,”5”:3500}

key和value都做了統一約束。

除此之外，如果ext裡某個key的value不是正則校驗的值，而是列舉值時，需要有一個對值進行限定的列舉表來進行校驗：

這個列舉校驗，說明key=4的屬性（對應屬性表裡二手，手機型別欄位），其值不只是要進行“short型別”校驗，而是value必須是固定的列舉值。

{”4”:”iphone”,”5”:3500}

這個ext就是不合法的，key=4的value=iphone不合法，而應該是列舉屬性，合法的應該為：

{”4”:”5”,”5”:3500}

此外，類目屬性服務還能記錄類目之間的層級關係：

（1）一級類目是招聘、房產、二手…

（2）二手下有二級類目二手傢俱、二手手機…

（3）二手手機下有三級類目二手iphone，二手小米，二手三星…

（4）…

類目服務解釋了帖子資料，描述品類層級關係，保證各類目屬性擴充套件性，保證各屬性值合理性校驗，就是58另一個統一的核心服務CMC（Category Management Center）。

畫外音：類目、屬性服務像不像電商系統裡的SKU擴充套件服務？

（1）品類層級關係，對應電商裡的類別層級體系；

（2）屬性擴充套件，對應電商裡各類別商品SKU的屬性；

（3）列舉值校驗，對應屬性的列舉值，例如顏色：紅，黃，藍；

透過品類服務，解決了key壓縮，key描述，key擴充套件，value校驗，品類層級的問題，還有這樣的一個問題沒有解決：每個品類下帖子的屬性各不相同，查詢需求各不相同，如何解決100億資料量，1萬屬性的檢索與聯合檢索需求呢？

第三：統一檢索服務

資料量很大的時候，不同屬性上的查詢需求，不可能透過組合索引來滿足所有查詢需求，“外接索引，統一檢索服務”是一個很常用的實踐：

（1）資料庫提供“帖子id”的正排查詢需求；

（2）所有非“帖子id”的個性化檢索需求，統一走外接索引；

後設資料與索引資料的操作遵循：

（1）對帖子進行tid正排查詢，直接訪問帖子服務；

（2）對帖子進行修改，帖子服務通知檢索服務，同時對索引進行修改；

（3）對帖子進行復雜查詢，透過檢索服務滿足需求；

畫外音：這個檢索服務，扛起了58同城80%的請求（不管來自PC還是APP，不管是主頁、城市頁、分類頁、列表頁、詳情頁，最終都會轉化為一個檢索請求），它就是58另一個統一的核心服務E-search，這個搜尋引擎，是完全自研的。

對於這個核心自研服務的搜尋引擎架構，簡單說明一下：

為應對100億級別資料量、幾十萬級別的吞吐量，業務線各種複雜的複雜檢索查詢，擴充套件性是設計重點：

（1）統一的代理層，作為入口，其無狀態效能夠保證增加機器就能擴充系統效能；

（2）統一的結果聚合層，其無狀態性也能夠保證增加機器就能擴充系統效能；

（3）搜尋核心檢索層，服務和索引資料部署在同一臺機器上，服務啟動時可以載入索引資料到記憶體，請求訪問時從記憶體中load資料，訪問速度很快：

• 為了滿足資料容量的擴充套件性，索引資料進行了水平切分，增加切分份數，就能夠無限擴充套件效能

• 為了滿足一份資料的效能擴充套件性，同一份資料進行了冗餘，理論上做到增加機器就無限擴充套件效能

系統時延，100億級別帖子檢索，包含請求分合，拉鍊求交集，從聚合層均可以做到10ms返回。

畫外音：入口層是Java研發的，聚合層與檢索層都是C語言研發的。

帖子業務，一致性不是主要矛盾，E-search會定期全量重建索引，以保證即使資料不一致，也不會持續很長的時間。

五、總結

文章寫了很長，最後做一個簡單總結，面對100億資料量，1萬列屬性，10萬吞吐量的業務需求，可以採用了後設資料服務、屬性服務、搜尋服務來解決：

• 一個解決儲存問題

• 一個解決品類解耦問題

• 一個解決檢索問題

任何複雜問題的解決，都是循序漸進的。

思路比結論重要，希望大家有收穫。