?導讀

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

名詞解釋：

• jimdb-基于redis改造升級，京東中間件團隊自研的一個高性能key-value數據庫，多數功能與redis一致。

背景

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

圖1.1京東商詳推薦商品     

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

數據模型

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

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

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

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

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

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

名詞解釋：

• SKU-Stock Keeping Unit（庫存量單位），KU是指一款商品，每款都有出現一個SKU，便于電商品牌識別商品。例如：商品詳情頁的每個型號/規格都會對應一個SKU。

乘用車-涵蓋了轎車、微型客車以及不超過9座的輕型客車。乘用車下細分為轎車、MPV和SUV等。

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

緩存結構設計

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

名詞解釋：

• TP999-單位時間內，99.9%請求接口響應時間小于等于該值。例如：1秒鐘內1000個請求，對這1000個請求按照響應時間由低到高排名，第999位的響應時間是20ms。最終TP999就是20ms。

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

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

圖3.2.2

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

2）剩余空間不足時，預分配空間流程。

3.3壓縮商品與車關系緩存

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

商品與車關系緩存存儲過程中，采用了商品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）設置分段最大的偏移量，保證后續新增偏移量不再擴容空間。

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

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

3.3商品與車緩存結構圖

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

備注：

• 自營商品MainSkuId可能發生變化，所以我們接入了商品變化MQ消息，實時調整SKU與車適配關系的存儲位置。
• 京東商詳頁面中每個不同的規格/型號分別對應不同的SKU，但是它們都對應同一個SpuId或者MainSkuId。

緩存架構設計

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

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

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

具體商品與車關系緩存架構如下：

商品與車關系緩存架構圖

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

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

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

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

高性能搜索

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

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

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

5.2商詳搜索商品與車適配關系Lua代碼

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

5.3商詳搜索商品與車適配關系接口性能

基于以上緩存設計和Lua腳本的使用，整個接口T999小于13ms。具體的接口性能監控如下圖：

總結

整個緩存結構設計的時候，使用BitMap(位圖)來存儲數據。解析SDS的內部存儲流程，通過存儲流程機制避開預分配空間節點，最大限度的利用緩存空間，避免資源浪費。采用Lua腳本來實現數據的適配搜索，降低網絡開銷，進一步提升接口的性能。希望此文對大家后續設計類似場景有一定的幫助和啟發。