?導讀

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

名詞解釋：

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

背景

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

圖1.1京東商詳推薦商品     

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

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

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

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

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

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

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

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

名詞解釋：

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

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

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

緩存結構設計

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

名詞解釋：

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

3.1位圖(bitmap)結構

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

• 位（bit）：計算機內部數(shù)據(jù)存儲的最小單位，例如：11001100是一個八位二進制數(shù)。
• 字節(jié)（byte）：計算機中數(shù)據(jù)處理的基本單位，習慣上用大寫B(tài)來表示，1B(byte,字節(jié))=8bit。

圖3.1位圖(bitmap)內部結構

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

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

圖3.2.1

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

圖3.2.2

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

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

3.3壓縮商品與車關系緩存

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

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

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

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

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

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

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

3.3商品與車緩存結構圖

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

備注：

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

緩存架構設計

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

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

“存儲”層核心包括：1、實現(xiàn)了緩存壓縮，參見3.3壓縮商品與車關系緩存。2、單元化實現(xiàn)跨區(qū)域災備，保障大促系統(tǒng)穩(wěn)定性。

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

商品與車關系緩存架構圖

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

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

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

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

高性能搜索

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

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

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

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

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

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

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

總結

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