1万属性，100亿数据，每秒10万吞吐，架构如何设计？

前言

有一类业务场景，没有固定的schema存储，却有着海量的数据行数，架构上如何来实现这类业务的存储与检索呢？58最核心的数据“帖子”的架构实现技术细节，今天和你们聊一聊。

1、背景描述及业务介绍

什么是58最核心的数据？

58是一个信息平台，有不少垂直品类：招聘、房产、二手物品、二手车、黄页等等，每一个品类又有不少子品类，无论哪一个品类，最核心的数据都是“帖子信息”。

各分类帖子的信息有什么特色？

逛过58的朋友很容易了解到，这里的帖子信息：

（1）各品类的属性千差万别，招聘帖子和二手帖子属性彻底不一样，二手手机和二手家电的属性又彻底不一样，目前恐怕有近万个属性；

（2）数据量巨大，100亿级别；

（3）每一个属性上都有查询需求，各组合属性上均可能有组合查询需求，招聘要查职位/经验/薪酬范围，二手手机要查颜色/价格/型号，二手要查冰箱/洗衣机/空调；

（4）吞吐量很大，每秒几10万吞吐；

如何解决100亿数据量，1万属性，多属性组合查询，10万并发查询的技术难题呢？一步步来。

2、最容易想到的方案

每一个公司的发展都是一个从小到大的过程，撇开并发量和数据量不谈，先看看

（1）如何实现属性扩展性需求；

（2）多属性组合查询需求；

如何知足业务的存储需求呢？

最开始，业务只有一个招聘品类，那帖子表多是这么设计的：

tiezi(tid, uid, c1, c2, c3);

那如何知足各属性之间的组合查询需求呢？

最容易想到的是经过组合索引知足查询需求：

index_1(c1, c2)

index_2(c2, c3)

index_3(c1, c3)

随着业务的发展，又新增了一个房产类别，存储问题又该如何解决呢？

能够新增若干属性知足存储需求，因而帖子表变成了：

tiezi(tid, uid, c1, c2, c3, c10, c11, c12, c13);

其中：

• c1,c2,c3是招聘类别属性

• c10,c11,c12,c13是房产类别属性

经过扩展属性，能够解决存储的问题。

查询需求，又该如何知足呢？

首先，跨业务属性通常没有组合查询需求。只能创建了若干组合索引，知足房产类别的查询需求。

当业务愈来愈多时，是否是发现玩不下去了？

3、垂直拆分是一个思路

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

如何按照业务进行垂直拆分？

能够这么玩：

tiezi_zhaopin(tid, uid, c1, c2, c3);

tiezi_fangchan(tid, uid, c10, c11, c12, c13);

在业务各异，数据量和吞吐量都巨大的状况下，垂直拆分会遇到什么问题呢？

这些表，以及对应的服务维护在不一样的部门，看上去各业务灵活性强，研发闭环，这偏偏是悲剧的开始：

（1）tid如何规范？

（2）属性如何规范？

（3）按照uid来查询怎么办（查询本身发布的全部帖子）？

（4）按照时间来查询怎么办（最新发布的帖子）？

（5）跨品类查询怎么办（例如首页搜索框）？

（6）技术范围的扩散，有的用mongo存储，有的用mysql存储，有的自研存储；

（7）重复开发了很多组件；

（8）维护成本太高；

ps：想一想看，电商的商品表，不可能一个类目一个表的。

4、58的玩法：三大中心服务

第一：统一帖子中心服务

平台型创业型公司，可能有多个品类，各品类有不少异构数据的存储需求，究竟是分仍是合，无需纠结：基础数据基础服务的统一，是一个很好的实践。

ps：这里说的是平台型业务。

如何将不一样品类，异构的数据统一存储起来呢？

（1）全品类通用属性统一存储；

（2）单品类特有属性，品类类型与通用属性json来进行存储；

更具体的：

tiezi(tid, uid, time, title, cate, subcate, xxid, ext);

（1）一些通用的字段抽取出来单独存储；

（2）经过cate, subcate, xxid等来定义ext是何种含义；

（3）经过ext来存储不一样业务线的个性化需求

例如：

招聘的帖子，ext为：

{“job”:”driver”,”salary”:8000,”location”:”bj”}

而二手的帖子，ext为：

{”type”:”iphone”,”money”:3500}

帖子数据，100亿的数据量，分256库，经过ext存储异构业务数据，使用mysql存储，上层架了一个帖子中心服务，使用memcache作缓存，就是这样一个并不复杂的架构，解决了业务的大问题。这是58最核心的帖子中心服务IMC（Info Management Center）。

ps：该服务的底层存储在16年全面切换为了自研存储引擎，替换了mysql，但架构理念仍未变。

解决了海量异构数据的存储问题，遇到的新问题是：

（1）每条记录ext内key都须要重复存储，占据了大量的空间，可否压缩存储；

（2）cateid已经不足以描述ext内的内容，品类有层级，深度不肯定，ext可否具有自描述性；

（3）随时能够增长属性，保证扩展性；

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

第二：统一类目属性服务

每一个业务有多少属性，这些属性是什么含义，值的约束等，耦合到帖子服务里显然是不合理的，那怎么办呢？

抽象出一个统一的类目、属性服务，单独来管理这些信息，而帖子库ext字段里json的key，统一由数字来表示，减小存储空间。

ps：帖子表只存元信息，无论业务含义。

如上图所示，json里的key再也不是”salary” ”location” ”money” 这样的长字符串了，取而代之的是数字1,2,3,4，这些数字是什么含义，属于哪一个子分类，值的校验约束，统一都存储在类目、属性服务里。

ps：类目表存业务信息，以及约束信息，与帖子表解耦。

这个表里对帖子中心服务里ext字段里的数字key进行了解释：

（1）1表明job，属于招聘品类下100子品类，其value必须是一个小于32的[a-z]字符；

（2）4表明type，属于二手品类下200子品类，其value必须是一个short；

这样就对原来帖子表ext扩展属性：

{“1”:”driver”,”2”:8000,”3”:”bj”}

{”4”:”iphone”,”5”:3500}

key和value都作了统一约束。

除此以外，若是ext里某个key的value不是正则校验的值，而是枚举值时，须要有一个对值进行限定的枚举表来进行校验：

这个枚举校验，说明key=4的属性（对应属性表里二手，手机类型字段），其值不仅是要进行“short类型”校验，而是value必须是固定的枚举值。

{”4”:”iphone”,”5”:3500}

这个ext就是不合法的，key=4的value=iphone不合法，而应该是枚举属性，合法的应该为：

{”4”:”5”,”5”:3500}

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

（1）一级类目是招聘、房产、二手…

（2）二手下有二级类目二手家具、二手手机…

（3）二手手机下有三级类目二手iphone，二手小米，二手三星…

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

ps：类目、属性服务像不像电商系统里的SKU扩展服务？* （1）品类层级关系，对应电商里的类别层级体系； （2）属性扩展，对应电商里各种别商品SKU的属性； （3）枚举值校验，对应属性的枚举值，例如颜色：红，黄，蓝；

经过品类服务，解决了key压缩，key描述，key扩展，value校验，品类层级的问题，还有这样的一个问题没有解决：每一个品类下帖子的属性各不相同，查询需求各不相同，如何解决100亿数据量，1万属性的检索与联合检索需求呢？

第三：统一检索服务

数据量很大的时候，不一样属性上的查询需求，不可能经过组合索引来知足全部查询需求，“外置索引，统一检索服务”是一个很经常使用的实践：

（1）数据库提供“帖子id”的正排查询需求；

（2）全部非“帖子id”的个性化检索需求，统一走外置索引；

元数据与索引数据的操做遵循：

（1）对帖子进行tid正排查询，直接访问帖子服务；

（2）对帖子进行修改，帖子服务通知检索服务，同时对索引进行修改；

（3）对帖子进行复杂查询，经过检索服务知足需求；

ps：这个检索服务，扛起了58同城80%的请求（无论来自PC仍是APP，不论是主页、城市页、分类页、列表页、详情页，最终都会转化为一个检索请求），它就是58另外一个统一的核心服务E-search，这个搜索引擎，是彻底自研的。*

对于这个内核自研服务的搜索引擎架构，简单说明一下：

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

（1）统一的代理层，做为入口，其无状态性可以保证增长机器就能扩充系统性能；

（2）统一的结果聚合层，其无状态性也可以保证增长机器就能扩充系统性能；

（3）搜索内核检索层，服务和索引数据部署在同一台机器上，服务启动时能够加载索引数据到内存，请求访问时从内存中load数据，访问速度很快：

• 为了知足数据容量的扩展性，索引数据进行了水平切分，增长切分份数，就可以无限扩展性能

• 为了知足一份数据的性能扩展性，同一份数据进行了冗余，理论上作到增长机器就无限扩展性能

系统时延，100亿级别帖子检索，包含请求分合，拉链求交集，从聚合层都可以作到10ms返回。

ps：入口层是Java研发的，聚合层与检索层都是C语言研发的。 帖子业务，一致性不是主要矛盾，E-search会按期全量重建索引，以保证即便数据不一致，也不会持续很长的时间。

5、总结

文章写了很长，最后作一个简单总结，面对100亿数据量，1万列属性，10万吞吐量的业务需求，能够采用了元数据服务、属性服务、搜索服务来解决：

• 一个解决存储问题

• 一个解决品类解耦问题

• 一个解决检索问题

任何复杂问题的解决，都是按部就班的。