京東APP百億級商品與車關(guān)系數(shù)據(jù)檢索實(shí)踐

作者：京東零售 張強(qiáng)

導(dǎo)讀

本文主要講解了京東百億級商品車型適配數(shù)據(jù)存儲結(jié)構(gòu)設(shè)計(jì)以及怎樣實(shí)現(xiàn)適配接口的高性能查詢。通過京東百億級數(shù)據(jù)緩存架構(gòu)設(shè)計(jì)實(shí)踐案例，簡單剖析了jimdb的位圖(bitmap)函數(shù)和lua腳本應(yīng)用在高性能場景。希望通過本文，讀者可以對緩存的內(nèi)部結(jié)構(gòu)知識有一定了解，并且能夠以最小的內(nèi)存使用代價(jià)將位圖(bitmap)靈活應(yīng)用到各個(gè)高性能實(shí)際場景。

1.背景

整個(gè)汽車行業(yè)行特殊性，對于零配件有一個(gè)很強(qiáng)的對口特性，不同車使用的零配件（例如：輪胎、機(jī)油、三濾、雨刮、火花塞等）規(guī)格型號不一樣。在售賣汽車零配件的時(shí)候，不能像3C家電、服飾，需要結(jié)合用戶具體車輛信息，推薦適合的配件商品?；诖嗽?，京東自建人車檔案模型并且利用算法清洗出百億級的車型-零配件的適配關(guān)系數(shù)據(jù)，最終形成“人->車-〉貨”關(guān)系鏈路，解決“人不識貨”的問題。 具體使用場景如下圖：

?.

圖1.1京東商詳推薦商品 圖1.2京東加購彈窗推薦商品

2.數(shù)據(jù)模型

“人-> 車->貨”關(guān)系的核心鏈路是由人（京東用戶）、乘用車和SKU這三部分組成。

首先，用戶在京東APP的商搜頁、商詳頁多個(gè)位置都可以選擇自己的車型信息進(jìn)行綁定（例如：圖2.1，京東商詳綁車入口位置“+添加愛車”按鈕），建立“人車檔案”數(shù)據(jù)。

?.

圖2.1.京東商詳綁車入口位置 圖2.2.京東商搜綁車入口位置

其次，運(yùn)營在后臺管理系統(tǒng)中將商品與車型進(jìn)行綁定，建立“商品與車型關(guān)系”數(shù)據(jù)(商品與車型的關(guān)系數(shù)據(jù)量級在百億級別)。

最終，購買商品的時(shí)候，京東推薦系統(tǒng)可以通過用戶自己綁定的車型推薦出適合該車型的商品。具體商品適配車型數(shù)據(jù)模型，見圖2.3。

??

圖2.3京東商品適配車型數(shù)據(jù)模型

3.緩存結(jié)構(gòu)設(shè)計(jì)

基于前面兩個(gè)部分的介紹，我們可以了解到整個(gè)商品搜索適配推薦存在兩個(gè)最核心問題。第一、百億級商品適配車型數(shù)據(jù)的存儲結(jié)構(gòu)設(shè)計(jì)，盡可能的占用資源成本最小；第二、商詳通過用戶車型來搜索適配商品時(shí)，必須保證接口性能的TP99位于毫秒級。最終技術(shù)選型的時(shí)候，采用了jimdb的位圖(bitmap)函數(shù)來進(jìn)行數(shù)據(jù)存儲。

3.1位圖(bitmap)結(jié)構(gòu)

位圖(bitmap)是通過最小的單位bit來進(jìn)行0或者1的設(shè)置，表示某個(gè)元素對應(yīng)的值或者狀態(tài)。一個(gè)bit的值是0或者1；也就是說一個(gè)bit能存儲的最多信息是2。

?位（bit）：計(jì)算機(jī)內(nèi)部數(shù)據(jù)存儲的最小單位，例如：11001100是一個(gè)八位二進(jìn)制數(shù)。

?字節(jié)（byte）：計(jì)算機(jī)中數(shù)據(jù)處理的基本單位，習(xí)慣上用大寫B(tài)來表示，1B(byte,字節(jié))=8bit。

??

圖3.1位圖(bitmap)內(nèi)部結(jié)構(gòu)

3.2位圖(bitmap)數(shù)據(jù)寫流程

位圖(bitmap)是基于jimdb的SDS(簡單動態(tài)字符串)類型的一系列位操作，遵循jimdb的SDS特性，例如：位圖(bitmap)最大長度512M，最大可以存儲232位。以下是“big”字符串的SDS結(jié)構(gòu)示例：

??

圖3.2.1“big”字符串的SDS結(jié)構(gòu)

SDS(簡單動態(tài)字符串)為了保證性能采用了空間預(yù)分配的策略：空間預(yù)分配用于優(yōu)化SDS的字符串增長操作。SDS的API對一個(gè)SDS進(jìn)行修改并且需要對SDS進(jìn)行空間擴(kuò)展的時(shí)候，程序不僅會為SDS分配修改所必須要的空間，還會為SDS分配額外的未使用空。具體預(yù)分配流程圖如下：

??

圖3.2.2SDS預(yù)分配流程圖

位置1：創(chuàng)建SDS簡單字符串預(yù)分配空間為：偏移量/8+1。

位置2：剩余空間不足時(shí)，預(yù)分配空間流程。

3.3壓縮商品與車關(guān)系緩存

商品適配車型關(guān)系（百億級數(shù)據(jù)量）

商品與車關(guān)系緩存存儲過程中，采用了商品SKU作為KEY，全量車型ID的偏移量(采用偏移量是為降低內(nèi)存消耗)作為VALUE值來進(jìn)行存儲。

全量車型ID大約有幾十萬的數(shù)據(jù)量，極限情況下一個(gè)商品SKU可以適配幾十萬輛車，很容易造成緩存大KEY的問題，為此我們進(jìn)行了偏移量（全量車型ID對應(yīng)的自增ID）的分段處理。具體是按照：SKU作為緩存KEY的基礎(chǔ)上，追加一個(gè)分段標(biāo)記數(shù)字作為新KEY，每個(gè)偏移量都會按照分段范圍對應(yīng)一個(gè)分段標(biāo)記數(shù)字。例如：偏移量1～50000，對應(yīng)緩存KEY為SKU+0；偏移量50001～100000，對應(yīng)緩存KEY為SKU+1，其它偏移量以此類推，這樣就保證了一個(gè)SKU即使適配所有車輛也不會出現(xiàn)緩存大KEY的情況。

BitMap緩存結(jié)構(gòu)底層使用SDS簡單字符串，為了保證性能采用了預(yù)分配空間的策略（圖3.2.2，“緩存BitMap內(nèi)部存儲流程圖”的“位置2”中虛線框圈選），這樣在緩存商品與車關(guān)系的時(shí)候浪費(fèi)了大量的緩存空間。為此我們調(diào)整了偏移量存儲順序，首先獲取到需要緩存的車型內(nèi)最大的偏移量，保證同一個(gè)緩存KEY第1次創(chuàng)建SDS簡單字符串（圖3.2.2，“緩存BitMap內(nèi)部存儲流程圖”的“位置1”中虛線框圈選）后，不再進(jìn)行第2次空間擴(kuò)容，這樣來最大限度的提升緩存利用率，起到壓縮空間目的。緩存數(shù)據(jù)關(guān)系流程如下：

??

圖3.3.1緩存數(shù)據(jù)關(guān)系流程

位置3:設(shè)置分段最大的偏移量，保證后續(xù)新增偏移量不再擴(kuò)容空間。

位置4:設(shè)置分段較小的偏移量。

全量車型ID是定長7位的數(shù)字，如果用它作為偏移量將消耗內(nèi)存巨大，所以采用對應(yīng)自增ID作為偏移量。最終在bitmap緩存的商品SKU與車的適配關(guān)系緩存結(jié)構(gòu)如下圖：

??

3.3.2商品與車緩存結(jié)構(gòu)圖

位置5:spuId用{}括起來表示緩存路由（Lua腳本中同一次請求，數(shù)據(jù)必須在緩存同一個(gè)分片上，否則會丟失數(shù)據(jù)）。POP商品spuId是SKU的產(chǎn)品ID，自營商品spuId是SKU的MainSkuId。

備注：

1、自營商品MainSkuId可能發(fā)生變化，所以我們接入了商品變化MQ消息，實(shí)時(shí)調(diào)整SKU與車適配關(guān)系的存儲位置。

2、京東商詳頁面中每個(gè)不同的規(guī)格/型號分別對應(yīng)不同的SKU，但是它們都對應(yīng)同一個(gè)SpuId或者M(jìn)ainSkuId。

4.緩存架構(gòu)設(shè)計(jì)

商品與車的關(guān)系數(shù)據(jù)量每天都在不斷增長，要求緩存架構(gòu)設(shè)計(jì)，需要支持集群橫向/縱向擴(kuò)容和來滿足業(yè)務(wù)發(fā)展以及高可用性。整個(gè)緩存架構(gòu)體系主要有前端、京東養(yǎng)車商品與車關(guān)系層和存儲三部分組成。

“商品與車關(guān)系緩存架構(gòu)”層核心包括：1、“集群路由”層，實(shí)現(xiàn)了集群橫向擴(kuò)容，保證數(shù)據(jù)量增漲的時(shí)候，緩存容量也能跟上。2、“分片路由”層，保證搜索的底層數(shù)據(jù)的分片相同，避免數(shù)據(jù)丟失。

“存儲”層核心包括：1、實(shí)現(xiàn)了緩存壓縮，參見3.3壓縮商品與車關(guān)系緩存。2、單元化實(shí)現(xiàn)跨區(qū)域?yàn)?zāi)備，保障大促系統(tǒng)穩(wěn)定性。具體商品與車關(guān)系緩存架構(gòu)如下：

??

4.1商品與車關(guān)系緩存架構(gòu)圖

位置6:集群路由，通過商品類型或者商品編號(POP商品)路由到不同緩存集群，便于橫向擴(kuò)展，每個(gè)集群單分片限制，解決分片超過限制問題。

位置7:分片路由，保障Lua腳本搜索數(shù)據(jù)的底層數(shù)據(jù)集群分片相同，避免數(shù)據(jù)丟失。其中自營商品和POP商品的路由分別是main_sku_id和product_id。

位置8:自營商品緩存集群，單元化實(shí)現(xiàn)跨區(qū)域?yàn)?zāi)備，采用自研DRC（Data Replication Center）數(shù)據(jù)同步機(jī)制。

位置9:POP商品緩存集群，通過商家編號拆分為兩個(gè)子集群。

5.高性能搜索

基于BitMap(位圖)緩存的商品與車關(guān)系數(shù)據(jù)，商詳調(diào)用接口的內(nèi)部實(shí)現(xiàn)采用了Lua腳本來降低網(wǎng)絡(luò)開銷，保障整個(gè)接口的性能。以下是搜索接口的流程圖：

??

5.1商詳搜索商品與車適配關(guān)系流程圖

位置10:商詳調(diào)用接口的時(shí)候，要傳兩個(gè)參數(shù)。第1個(gè)參數(shù)是全量車型ID列表，大約5個(gè)全量車型ID。第2個(gè)參數(shù)是商品SKU列表，SKU的數(shù)量極限超過200個(gè)。最后全量車型ID與商品SKU組合為上千個(gè)商品與車的關(guān)系后，再到百億級適配關(guān)系去搜索看是否匹配的。如果不匹配返回適配商品，反之則返回不適配。

Lua腳本減少了應(yīng)用服務(wù)器與緩存服務(wù)器的交互，降低了網(wǎng)絡(luò)開銷的時(shí)間，達(dá)到提升搜索服務(wù)的性能。以下是Lua腳本具體代碼：

??

5.2商詳搜索商品與車適配關(guān)系Lua代碼

基于以上緩存設(shè)計(jì)和Lua腳本的使用，整個(gè)接口T999小于13ms。具體的接口性能監(jiān)控如下圖：

??

5.3商詳搜索商品與車適配關(guān)系接口性能

6.總結(jié)

整個(gè)緩存結(jié)構(gòu)設(shè)計(jì)的時(shí)候，使用BitMap(位圖)來存儲數(shù)據(jù)。解析SDS的內(nèi)部存儲流程，通過存儲流程機(jī)制避開預(yù)分配空間節(jié)點(diǎn)，最大限度的利用緩存空間，避免資源浪費(fèi)。采用Lua腳本來實(shí)現(xiàn)數(shù)據(jù)的適配搜索，降低網(wǎng)絡(luò)開銷，進(jìn)一步提升接口的性能。希望此文對大家后續(xù)設(shè)計(jì)類似場景有一定的幫助和啟發(fā)。

審核編輯 黃宇