京东 APP 百亿级商品与车关系数据检索实践

作者：京东零售 张强

导读

本文主要讲解了京东百亿级商品车型适配数据存储结构设计以及怎样实现适配接口的高性能查询。通过京东百亿级数据缓存架构设计实践案例，简单剖析了 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 压缩商品与车关系缓存

商品适配车型关系（百亿级数据量）

商品与车关系缓存存储过程中，采用了商品 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 脚本具体代码：

5.2 商详搜索商品与车适配关系 Lua 代码

基于以上缓存设计和 Lua 脚本的使用，整个接口 T999 小于 13ms。具体的接口性能监控如下图：

5.3 商详搜索商品与车适配关系接口性能

6.总结

整个缓存结构设计的时候，使用 BitMap(位图)来存储数据。解析 SDS 的内部存储流程，通过存储流程机制避开预分配空间节点，最大限度的利用缓存空间，避免资源浪费。采用 Lua 脚本来实现数据的适配搜索，降低网络开销，进一步提升接口的性能。希望此文对大家后续设计类似场景有一定的帮助和启发。