惊了！1 万属性、100 亿数据、10 万吞吐，这样的系统架构是怎么扛住的？-优快云博客

电商平台涵盖众多商品品类，像数码产品、服装鞋帽、家居用品、美妆护肤、食品饮料等，每个品类又包含诸多子品类。而无论哪个品类，“商品信息” 都是最核心的数据，这就类似一个大型的线上商品集市。

有一类业务场景，数据没有固定的模式（schema）存储，却有着海量的数据行数，该如何从架构层面实现这类业务的存储与检索呢？比如要处理 1 万种属性、100 亿条数据，还得支撑每秒 10 万次的吞吐，今天就和大家聊聊 “电商商品多维度信息业务” 的架构设计实践。

一、背景与业务介绍

电商平台的核心数据

各分类商品信息的特点

经常网购的人很容易发现，这类平台的商品信息有以下特点：

不同品类的属性差异极大，数码产品和服装的属性完全不同，就连手机和电脑的属性也不一样，目前属性数量已接近一万种；
数据量极为庞大，达到 100 亿级别；
每个属性都存在查询需求，各组合属性也可能有组合查询需求，比如手机要查询品牌、内存、价格范围，服装要查询尺码、颜色、材质，家居用品要查询风格、尺寸、功能等；
吞吐量很高，每秒能达到几十万次。

那该如何解决 100 亿数据量、1 万种属性、多属性组合查询以及每秒 10 万次并发查询的技术难题呢？我们一步步来分析。

二、最容易想到的初始方案

每个电商公司都是从小规模发展起来的，先不考虑并发量和数据量，看看如何先解决：

属性扩展性需求；
多属性组合查询需求。毕竟公司初期并发量和数据量都不大，得先把业务问题解决。

业务存储需求的满足方式

最开始，业务只有手机这一个品类，商品表可能是这样设计的：product(tid, uid, brand, model, memory, price)

多属性组合查询需求的满足方式

最容易想到的是通过组合索引来满足查询需求，比如：

index_1(brand, model)
index_2(model, memory)
index_3(brand, price)

业务扩展后的存储与查询问题

随着业务发展，新增了服装类别，存储问题可以通过新增若干属性来解决，此时商品表变成：

product(tid, uid, brand, model, memory, price, size, color, material)其中，brand、model、memory、price是手机类别的属性，size、color、material是服装类别的属性。

对于查询需求，由于跨业务属性一般没有组合查询需求，只能建立若干组合索引来满足服装类别的查询需求。但想想看，要覆盖所有两属性、三属性查询，得建多少索引，这显然不是长久之计，业务越来越多时，这种方式就难以维系了。

三、垂直拆分的思路与问题

新增属性是一种扩展方式，新增表也是一种方式，垂直拆分是常见的存储扩展方案。

可以这样操作：

product_phone(tid, uid, brand, model, memory, price)（手机商品表）
product_clothes(tid, uid, size, color, material, price)（服装商品表）

垂直拆分带来的问题

在业务多样、数据量和吞吐量都很大的情况下，垂直拆分存在诸多问题：这些表以及对应的服务由不同部门维护，看似各业务灵活性强、研发闭环，但这恰恰是问题的开端：

商品 ID（tid）如何规范？
属性如何规范？
按商家 ID（uid）查询（查询商家发布的所有商品）该怎么办？
按时间查询（最新上架的商品）该怎么办？
跨品类查询（比如首页搜索框）该怎么办？
技术范围扩散，有的用 MongoDB 存储，有的用 MySQL 存储，有的自研存储；
重复开发了不少组件；
维护成本过高。就像大型电商平台的商品表，不可能一个类目一个表，电商商品信息表也一样。

四、行业最佳实践：三大中心服务

第一：统一商品中心服务

对于平台型电商公司，可能有多个品类，各品类有很多异构数据的存储需求，无需纠结是分还是合，统一基础数据和基础服务是很好的实践（这里针对平台型业务）。

异构数据的统一存储方式

要将不同品类、异构的数据统一存储，可采用以下方法：

全品类通用属性统一存储；
单品类特有属性，通过品类类型与通用属性的 JSON 来存储。

更具体的设计是，商品表结构为：product(tid, uid, time, name, cate, subcate, xxid, ext)。其中：

一些通用字段被单独抽取出来存储；
通过cate、subcate、xxid来定义ext的含义；
通过ext来存储不同业务线的个性化需求。

tid	uid	time	cateid	ext
1	1	123	招聘	{"job":"driver","salary":8000,"location":"bj"}
2	1	456	二手	{"type":"iphone","money":3500}

例如，手机商品的ext可以是：{"brand":"Apple","model":"iPhone 15","memory":"256G","price":6999}；服装商品的ext可以是：{"size":"L","color":"blue","material":"cotton","price":299}。

商品数据有 100 亿条，分 256 个库，通过ext存储异构业务数据，使用 MySQL 存储，上层搭建一个商品中心服务，并用 Redis 做缓存，这样一个并不复杂的架构，就解决了业务的大问题。这就是电商平台最核心的商品中心服务 PMC（Product Management Center）。

新问题的出现

解决了海量异构数据的存储问题后，又出现了新问题：

每条记录的ext内的键（key）都需要重复存储，占用大量空间，能否压缩存储？
品类 ID（cateid）已不足以描述ext内的内容，品类有不确定的层级，ext能否具备自描述性？
能否随时增加属性，保证扩展性？

解决完海量异构数据的存储问题，接下来要解决类目的扩展性问题。

第二：统一类目属性服务

每个业务有多少属性、这些属性的含义、值的约束等，如果耦合到商品服务里显然不合理，那该怎么办呢？

可以抽象出一个统一的类目、属性服务，单独管理这些信息，并且商品库ext字段里的 JSON 键，统一用数字表示，以减少存储空间。

商品表只存储元信息，不涉及业务含义。比如，JSON 里的键不再是 “brand”“model”“size” 这样的长字符串，而是用数字 1、2、3、4 代替。这些数字的含义、所属子分类、值的校验约束，统一存储在类目、属性服务里。

tid	uid	time	cateid	ext
1	1	123	招聘	{"1":"driver","2":8000,"3":"bj"}
2	1	456	二手	{"4":"iphone","5":3500}

类目表存储业务信息以及约束信息，与商品表解耦。这个表会对商品中心服务里ext字段的数字键进行解释，比如：

数字 1 代表 “brand”，属于数码品类下的手机子品类，其值必须是品牌枚举值；
数字 4 代表 “size”，属于服装品类下的上衣子品类，其值必须是尺码枚举值（S、M、L 等）。

这样，原来商品表的ext扩展属性就变成了：{"1":"Apple","2":"iPhone 15","3":"256G","4":6999}和{"5":"L","6":"blue","7":"cotton","8":299}（服装商品），键和值都有了统一约束。

此外，如果ext里某个键的值不是通过正则校验，而是枚举值，就需要有一个枚举表来对值进行限定校验。比如，当ext为{"5":"XL","6":"blue","7":"cotton","8":299}时，因为键 5 对应的属性（服装、上衣尺码字段）的值需要是固定枚举值（S、M、L 等），而 “XL” 不符合，所以这个ext是不合法的，合法的应该是{"5":"L","6":"blue","7":"cotton","8":299}。

另外，类目属性服务还能记录类目之间的层级关系，比如：

一级类目有数码、服装、家居等；
数码下有二级类目手机、电脑等；
手机下有三级类目苹果手机、华为手机、小米手机等。

类目服务解释了商品数据，描述了品类层级关系，保证了各类目属性的扩展性，也保证了各属性值的合理性校验，这就是电商平台另一个统一的核心服务 CMC（Category Management Center）。

这就类似于电商系统里的商品属性扩展服务：

品类层级关系对应电商里的类别层级体系；
属性扩展对应电商里各类别商品的属性；
枚举值校验对应属性的枚举值，比如手机品牌有苹果、华为、小米等。

通过品类服务，解决了键的压缩、描述、扩展以及值的校验、品类层级等问题，但还有一个问题没解决：每个品类下商品的属性不同，查询需求也不同，如何解决 100 亿数据量、1 万种属性的检索与联合检索需求呢？

第三：统一检索服务

当数据量很大时，不同属性上的查询需求，不可能通过组合索引来满足所有查询需求，“外置索引，统一检索服务” 是常用的实践方法：

数据库提供 “商品 ID” 的正排查询需求；
所有非 “商品 ID” 的个性化检索需求，统一通过外置索引来满足。

元数据与索引数据的操作遵循以下规则：

对商品进行商品 ID（tid）正排查询，直接访问商品服务；
对商品进行修改时，商品服务通知检索服务，同时修改索引；
对商品进行复杂查询时，通过检索服务来满足需求。

这个检索服务承担了电商平台 80% 的请求，不管请求来自 PC 还是 APP，也不管是来自首页、分类页、搜索页、商品列表页还是详情页，最终都会转化为一个检索请求。

搜索引擎架构说明

为了应对 100 亿级别的数据量、几十万级别的吞吐量以及业务线各种复杂的检索查询，扩展性是设计的重点：

统一的代理层作为入口，由于其无状态性，增加机器就能扩充系统性能；
统一的结果聚合层，同样因为无状态性，增加机器也能扩充系统性能；
搜索内核检索层，服务和索引数据部署在同一台机器上，服务启动时可将索引数据加载到内存，请求访问时从内存中读取数据，访问速度很快。为满足数据容量的扩展性，索引数据进行了水平切分，增加切分份数就能无限扩展性能；为满足一份数据的性能扩展性，同一份数据进行了冗余，理论上增加机器就能无限扩展性能。系统时延方面，100 亿级别商品检索，包含请求分合、拉链求交集等操作，从聚合层可以做到 10 毫秒返回。

在商品业务中，一致性不是主要矛盾，检索服务会定期全量重建索引，以确保即使数据存在不一致，也不会持续很长时间