千年殇,将夜猫腻小说,大主宰天蚕土豆

作者：京東零售張強

導讀

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

1.背景

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

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

2.數據模型

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

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

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

其次，運營在后臺管理系統中將商品與車型進行綁定，建立“商品與車型關系”數據(商品與車型的關系數據量級在百億級別)。

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

圖2.3京東商品適配車型數據模型

3.緩存結構設計

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

3.1位圖(bitmap)結構

位圖(bitmap)是通過最小的單位bit來進行0或者1的設置，表示某個元素對應的值或者狀態。一個bit的值是0或者1；也就是說一個bit能存儲的最多信息是2。

?位（bit）：計算機內部數據存儲的最小單位，例如：11001100是一個八位二進制數。

?字節（byte）：計算機中數據處理的基本單位，習慣上用大寫B來表示，1B(byte,字節)=8bit。

圖3.1位圖(bitmap)內部結構

3.2位圖(bitmap)數據寫流程

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

圖3.2.1“big”字符串的SDS結構

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

圖3.2.2SDS預分配流程圖

位置1：創建SDS簡單字符串預分配空間為：偏移量/8+1。

位置2：剩余空間不足時，預分配空間流程。

3.3壓縮商品與車關系緩存

偏移量（自增ID）	全量車型	商品SKU
1	1165788	101362
2	1165793	101362

商品適配車型關系（百億級數據量）

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

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

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

圖3.3.1緩存數據關系流程

位置3:設置分段最大的偏移量，保證后續新增偏移量不再擴容空間。

位置4:設置分段較小的偏移量。

全量車型ID是定長7位的數字，如果用它作為偏移量將消耗內存巨大，所以采用對應自增ID作為偏移量。最終在bitmap緩存的商品SKU與車的適配關系緩存結構如下圖：

3.3.2商品與車緩存結構圖

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

備注：

1、自營商品MainSkuId可能發生變化，所以我們接入了商品變化MQ消息，實時調整SKU與車適配關系的存儲位置。

2、京東商詳頁面中每個不同的規格/型號分別對應不同的SKU，但是它們都對應同一個SpuId或者MainSkuId。

4.緩存架構設計

商品與車的關系數據量每天都在不斷增長，要求緩存架構設計，需要支持集群橫向/縱向擴容和來滿足業務發展以及高可用性。整個緩存架構體系主要有前端、京東養車商品與車關系層和存儲三部分組成。

“商品與車關系緩存架構”層核心包括：1、“集群路由”層，實現了集群橫向擴容，保證數據量增漲的時候，緩存容量也能跟上。2、“分片路由”層，保證搜索的底層數據的分片相同，避免數據丟失。

“存儲”層核心包括：1、實現了緩存壓縮，參見3.3壓縮商品與車關系緩存。2、單元化實現跨區域災備，保障大促系統穩定性。具體商品與車關系緩存架構如下：

4.1商品與車關系緩存架構圖

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

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

位置8:自營商品緩存集群，單元化實現跨區域災備，采用自研DRC（Data Replication Center）數據同步機制。

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

5.高性能搜索

基于BitMap(位圖)緩存的商品與車關系數據，商詳調用接口的內部實現采用了Lua腳本來降低網絡開銷，保障整個接口的性能。以下是搜索接口的流程圖：

5.1商詳搜索商品與車適配關系流程圖

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

Lua腳本減少了應用服務器與緩存服務器的交互，降低了網絡開銷的時間，達到提升搜索服務的性能。以下是Lua腳本具體代碼：