基于腾讯云数据库构建商品加工引擎，管理近10亿商品数据

商品加工引擎是腾讯基于云原生打造的高可用、可扩展、灵活配置的商品处理引擎，融合商品接入、商品加工、商品存储、商品分发、链路监控、商品对账等核心能力，支持近十亿的商品管理和加工，以及腾讯多个核心应用场景。

商品加工引擎提供不同类型的商品录入、商品统一加工、商品信息分发等能力。存储商品数据接近十亿，支持商品加工能力包括：淫秽、色情、迷信、暴力、涉政等内容机器或人工审核，图片转链、视频转链、统一商品理解类目品牌词生成、统一商品标签生成、商品卖点信息生成等等。

系统架构

支持商品统一接入、商品基于自建的组件市场进行商品加工、基于流程编排模块可以定制化配置加工组件、统一存储的商品数据通过商品分发模块进行统一分发。

技术挑战

1. 商品存储的挑战

单sku 300+字段，近十亿的商品，支持查询QPS 4万+，商品更新TPS 1万+，日4亿+次商品数据实时分发，有较明显的高峰低峰期。如何既满足高性能，又满足可扩展性？这里面涉及到：
a.表结构设计，需要平衡各行业的字段扩展需求以及商品数据分发组装带来的耗时及性能问题。
b.存储设计，如此高并发和大数据量的需求背景下，持久化数据库选型显得尤为重要。

所选数据库要同时满足：可扩展性、稳定性、事务性、支持频繁增加字段的运维场景、数据订阅组件支持（保证分发和存储完全解耦）、尽量低的存储成本。

2. 业务支持的挑战

不同类型、不同应用渠道的商品加工特性各异，如何做到跟上业务诉求快速迭代，且做到懂业务的人可以自己去管控整个加工流程，而不是技术人员自己写在代码黑盒里。例如：新闻资讯类行业审核需要涉及到包含淫秽、色情、迷信、暴力、政治审核等审核条目，但其他行业不需要政审等等。

3.高优加工通路支持的挑战

全数据通路，商品加工因受限于底层的图片识别等能力限制，存在扩展的边际成本。所以怎样能够确保高优通路商品得到优先处理，任务优先级管理是在架构层面临的另一挑战。

技术架构

技术架构上将整体数据处理管道抽象成数据接入层、存储&数据加工层、流水解析层、数据分发层，各层之间通过消息中间件进行解耦，并起到各层间流量反压缓冲的作用。技术选型上选择腾讯云原生数据库TDSQL-C和中间件，且保证全链路数据的顺序性和at Least Once的消息处理语义。

商品表结构设计

商品表目前拆分为：商品信息表、销售信息表、优惠券信息表，以最宽粒度拆表是因为商品中台在进行数据分发时，需要各表信息join组装分发，当表的粒度过细，会严重影响数据组装效率，直接导致分发吞吐量的降低以及数据库压力的倍增，不符合可扩展性设计。

主键及分片策略：分片策略采用商品HashId分片，HashId生成算法如下：

public static Long genHashId(Long catalogId, String... outerIds) {
        Preconditions.checkNotNull(catalogId);
        Preconditions.checkNotNull(outerIds);
        Hasher hasher = Hashing.murmur3_128().newHasher();
        hasher.putLong(catalogId);
        for (String outerId : outerIds) {
            hasher.putString(outerId, Charsets.UTF_8);
        }
        return ~(1l << 63) & hasher.hash().asLong();
    }

现最大商品库7千万+商品无Hash冲突，且最大限度保证数据均匀。现在四个分片数据分布如下：
 

主键采用业务主键catalogId+hashId，没有用系统主键主要考虑每次落库动作前均会先查询做数据对比，然后落库，采用业务主键可以避免回表查询，大大提高缓存命中率及查询效率。目前TDSQL-C缓存命中率99.91%，大部分查询耗时小于5ms。
 

商品信息表字段按照信息领域拆分，每个信息领域以blob存储protobuf压缩后的对象信息。可以达到领域内信息字段的快速变更，并节省磁盘空间。在数据读取以及网络传输过程中，最大限度节省带宽。关于protobuf优缺点这里不做赘述，大家可以查询相关资料详细了解。

持久化存储设计

持久化存储设计主要采用TDSQL（InnoDB引擎）存储热数据，Hbase存储冷数据的架构设计，冷热数据的区分是商品是否进行逻辑删除。这里冷数据单独存储原因是要减少存储成本。TDSQL为了提高数据访问效率，高性能版本默认均为SSD硬盘，比普通的机械硬盘存储要高很多。HBase存储我们默认开启了SNAPPY压缩算法，所以从磁盘空间占用量和存储成本上均有大幅降低。

那为什么不直接用Hbase存储？

1.入库数据后，经常会判断数据数量是否准确，我们对商品库级别的count查询是强需求，这点Hbase支持不了。
2.TDSQL作为腾讯云产品，产品易用性及监控配置上更完善。
3.商品变更的数据流订阅，Hbase暂未发现较优雅的方案。

商品加工编排设计

商品加工的编排，主要针对加工组件市场里面的组件进行加工编排。抽象出商品加工组件市场的概念，主要目的是避免功能的重复建设，提高代码复用性，并有效提高新系统的交付速度。商品加工事件编排架构设计如下：

• 优先级队列层：此层抽象出三个优先级不同的topic用于分发商品加工事件,提升不同渠道数据处理效率，避免资源抢占。
• 事件处理层：此层消费商品加工事件，对事件解析去重，通过不同优先级队列事件感知控制消费吞吐量，处理不同客户任务优先级。此层会基于不同应用场景和商品所属行业，去选择对应的DAG进行触发商品加工流程。由于下游编排管理层在过高请求压力下会存在服务过载情况，所以此处设置异常熔断控制，以及异常恢复策略。
• 编排管理层：编排管理层，依赖腾讯云ASW调度平台进行流程配置和管理。ASW在编排配置方面支持较全，循环、并行、选择等条目支持很友好。（目前ASW支持腾讯云API 3.0上超过99%的接口，能做到像胶水一样粘合各种服务，支持高并发场景。）
• 请求转发层：编排管理是对请求转发层的编排，此层使用Serverless云函数进行部署。各请求转发节点可以实现同步请求转发或异步请求转发。实现对不同商品处理场景的有效支撑。
• 服务提供层：服务提供层提供对请求转发层的请求处理，此层会对来自上层的请求进行多线程处理，提高数据处理速度。并负责对下游的请求流量管控，避免流量过大压垮下游的服务。
• 通用能力层：公司各个服务平台提供的通用能力，例如：文本审核、图片识别审核、商品理解统一类目、商品打标等。

总结

本篇文章主要针对现商品中台整体架构的梳理和总结，里面涉及到很多技术点，受篇幅限制没有赘述，其中包括但不限于：全链路监控、数据一致性比对、线程管理模型等等，后面会继续完善相关内容。

来源： 腾讯云数据库公众号