<p>对于 version + ext 方案，还是有很多朋友质疑“线上不可能这么用”。 本篇将讲述一下 58 同城最核心的数据“帖子”的架构实现技术细节，说明不仅不是“不可能这么用”，而是大数据，可变属性，高吞吐场景下的“常用手段”。</p>    <p>一、背景描述及业务介绍</p>    <p>问：什么是数据库扩展的 version + ext 方案？</p>    <p>使用 ext 来承载不同业务需求的个性化属性，使用 version 来标识 ext 里各个字段的含义 。</p>    <p><img src="https://simg.open-open.com/show/967dd42e2c6868db6d286c3a1e469a0c.jpg"></p>    <p>例如上述 user 表：</p>    <p>verion=0 表示 ext 里是 passwd/nick</p>    <p>version=1 表示 ext 里是 passwd/nick/age/sex</p>    <p>优点？</p>    <p>（ 1 ）可以随时动态扩展属性，扩展性好</p>    <p>（ 2 ）新旧两种数据可以同时存在，兼容性好</p>    <p>不足？</p>    <p>（ 1 ） ext 里的字段无法建立索引</p>    <p>（ 2 ） ext 里的 key 值有大量冗余，建议 key 短一些</p>    <p><strong>问： </strong> 什么是 58 同城最核心的数据？</p>    <p>58 同城是一个信息平台，有很多垂直品类：招聘、房产、二手物品、二手车、黄页等等，每个品类又有很多子品类，不管哪个品类， 最核心的数据都是“帖子信息” （业务像一个大论坛？）。</p>    <p>问： 帖子信息有什么特点？</p>    <p>大家去 58 同城的首页上看看就知道了：</p>    <p>（ 1 ） 每个品类的属性千差万别 ，招聘帖子和二手帖子属性完全不同，二手手机和二手家电的属性又完全不同，目前恐怕有 近万个属性</p>    <p>（ 2 ） 帖子量很大， 100 亿级别</p>    <p>（ 3 ） 每个属性上都有查询需求 （各组合属性上都可能有组合查询需求） ，招聘要查职位 / 经验 / 薪酬范围，二手手机要查颜色 / 价格 / 型号，二手要查冰箱 / 洗衣机 / 空调</p>    <p>（ 4 ） 查询量很大，每秒几 10 万级别</p>    <p>如何解决 <strong> 100 亿数据量， 1 万属性，多属性组合查询， 10 万并发查询 </strong> 的技术难题，是今天要讨论的内容。</p>    <p>二、最容易想到的方案</p>    <p>每个公司的发展都是一个从小到大的过程，撇开并发量和数据量不谈，先看看</p>    <p>（ 1 ）如何实现属性扩展性需求</p>    <p>（ 2 ）多属性组合查询需求</p>    <p>最开始，可能只有一个 <strong>招聘品类</strong> ，那帖子表可能是这么设计的：</p>    <p>tiezi(tid,uid, c1, c2, c3)</p>    <p>那如何满足各属性之间的组合查询需求呢？</p>    <p>最容易想到的是通过组合索引：</p>    <p>index_1(c1,c2) index_2(c2, c3) index_3(c1, c3)</p>    <p>随着业务的发展，又新增了一个 <strong>房产类别</strong> ，新增了若干属性，新增了若干组合查询，于是帖子表变成了：</p>    <p>tiezi(tid,uid, c1, c2, c3, c10, c11, c12, c13)</p>    <p>其中 c1,c2,c3 是招聘类别属性， c10,c11,c12,c13 是房产类别属性，这两块属性一般没有组合查询需求</p>    <p>但为了满足房产类别的查询需求，又要建立了若干组合索引（不敢想有多少个索引能覆盖所有两属性查询，三属性查询）</p>    <p>是不是发现玩不下去了？</p>    <p>三、友商的玩法</p>    <p>新增属性是一种扩展方式，新增表也是一种方式 ，有友商是这么玩的，按照业务进行垂直拆分：</p>    <p>tiezi_zhaopin(tid,uid, c1, c2, c3)</p>    <p>tiezi_fangchan(tid,uid, c10, c11, c12, c13)</p>    <p>这些表，这些服务维护在不同的部门，不同的研发同学手里，看上去各业务线灵活性强，这恰恰是悲剧的开始 ：</p>    <p>（ 1 ） tid 如何规范？</p>    <p>（ 2 ）属性如何规范？</p>    <p>（ 3 ）按照 uid 来查询怎么办（查询自己发布的所有帖子）？</p>    <p>（ 4 ）按照时间来查询怎么办（最新发布的帖子）？</p>    <p>（ 5 ）跨品类查询怎么办（例如首页搜索框）？</p>    <p>（ 6 ）技术范围的扩散，有的用 mongo 存储，有的用 mysql 存储，有的自研存储</p>    <p>（ 7 ）重复开发了不少组件</p>    <p>（ 8 ）维护成本过高</p>    <p>（ 9 ） …</p>    <p>想想看，电商的商品表，不可能一个类目一个表的。</p>    <p>四、 58 同城的玩法</p>    <p>【统一帖子中心服务】</p>    <p>平台型创业型公司，可能有多个品类，例如 58 同城的招聘房产二手，很多异构数据的存储需求，到底是分还是合，无需纠结： <strong> 基础数据基础服务的统一 </strong> ，无疑是 58 同城技术路线发展 roadmap 上最正确的决策之一 ，把这个方针坚持下来， @ 老崔 @ 晓飞 这些高瞻远瞩的先贤功不可没，业务线会有“扩展性”“灵活性”上的微词，后文看看先贤们如何通过一些巧妙的技术方案来解决的。</p>    <p>如何将不同品类，异构的数据统一存储起来，采用的就是类似 version+ext 的方式：</p>    <p>tiezi(tid,uid, time, title, cate, subcate, xxid, ext)</p>    <p>（ 1 ） 一些通用的字段抽取出来单独存储</p>    <p>（ 2 ） 通过 cate, subcate, xxid 等来定义 ext 是何种含义 （和 version 有点像？）</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/809d731b97d19dacd55cb547ec80b2e3.png"></p>    <p>（ 3 ）通过 ext 来存储不同业务线的个性化需求</p>    <p>例如招聘的帖子：</p>    <p>ext : {“job”:”driver”,”salary”:8000,”location”:”bj”}</p>    <p>而二手的帖子：</p>    <p>ext : {”type”:”iphone”,”money”:3500}</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/be43e30edfa76777c33a801bfd66f27c.png"></p>    <p>58 同城最核心的帖子数据， 100 亿的数据量，分 256 库，异构数据 mysql 存储，上层架了一个服务，使用 memcache 做缓存，就是这样一个简单的架构，一直坚持这这么多年。上层的这个服务，就是 58 同城最核心的统一服务 IMC （ Imformation Management Center ） ，注意这个最核心，是没有之一。</p>    <p>解决了海量异构数据的存储问题，遇到的 <strong>新问题</strong> 是：</p>    <p>（ 1 ）每条记录 ext 内 key 都需要重复存储，占据了大量的空间，能否压缩存储</p>    <p>（ 2 ） cateid 已经不足以描述 ext 内的内容，品类有层级，深度不确定， ext 能否具备自描述性</p>    <p>（ 3 ）随时可以增加属性，保证扩展性</p>    <p>【统一类目属性服务】</p>    <p>每个业务有多少属性，这些属性是什么含义，值的约束等揉不到帖子服务里，怎么办呢？</p>    <p>58 同城的先贤们 抽象出一个统一的类目、属性服务，单独来管理这些信息 ，而帖子库 ext 字段里 json 的 key ，统一由数字来表示，减少存储空间 。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/6a8074b002360f35caf728ca7d90c5bd.png"></p>    <p>如上图所示， json 里的 key 不再是 ”salary” ”location” ”money”  这样的长字符串了，取而代之的是数字 1,2,3,4 ，这些 数字是什么含义，属于哪个子分类，值的校验约束，统一都存储在类目、属性服务里 。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/2f8a40c685adc01f52a6b00b939151ab.jpg"></p>    <p>这个表里对帖子中心服务里 ext 字段里的数字 key 进行了解释：</p>    <p>1 代表 job ，属于招聘品类下 100 子品类，其 value 必须是一个小于 32 的 [a-z] 字符</p>    <p>4 代表 type ，属于二手品类下 200 子品类，其 value 必须是一个 short</p>    <p>这样就对原来帖子表 ext 里的</p>    <p>ext : {“1”:”driver”,”2”:8000,”3”:”bj”}</p>    <p>ext : {”4”:”iphone”,”5”:3500}</p>    <p>key 和 value 都做了统一约束 。</p>    <p>除此之外， 如果 ext 里某个 key 的 value 不是正则校验的值，而是枚举值时，需要有一个对值进行限定的枚举表来进行校验 ：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/175d3146c5dc081681d21c4a512b319a.png"></p>    <p>这个枚举校验，说明 key=4 的属性（对应属性表里二手，手机类型字段），其值不只是要进行“ short 类型”校验，而是 value 必须是固定的枚举值。</p>    <p>ext : {”4”:”iphone”,”5”:3500} 这个 ext 就是不合法的（ key=4 的 value=iphone 不合法），合法的应该为</p>    <p>ext : {”4”:”5”,”5”:3500}</p>    <p>此外，类目属性服务还能记录类目之间的层级关系：</p>    <p>（ 1 ）一级类目是招聘、房产、二手 …</p>    <p>（ 2 ）二手下有二级类目二手家具、二手手机 …</p>    <p>（ 3 ）二手手机下有三级类目二手 iphone ，二手小米，二手三星 …</p>    <p>（ 4 ） …</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/58d8cd591df54b276e21749ba247ff03.png"></p>    <p>协助解释 58 同城最核心的帖子数据，描述品类层级关系，保证各类目属性扩展性，保证各属性值合理性校验，就是 58 同城另一个统一的核心服务 CMC （ Category Management Center ） 。</p>    <p>多提一句，类目、属性服务像不像电商系统里的 SKU 扩展服务？</p>    <p>（ 1 ）品类层级关系，对应电商里的类别层级体系</p>    <p>（ 2 ）属性扩展，对应电商里各类别商品 SKU 的属性</p>    <p>（ 3 ）枚举值校验，对应属性的枚举值，例如颜色：红，黄，蓝</p>    <p>解决了 key 压缩， key 描述， key 扩展， value 校验，品类层级的问题， <strong>还有这样的一个问题</strong> 没有解决：每个品类下帖子的属性各不相同，查询需求各不相同，如何解决 100 亿数据量， 1 万属性的查询需求，是 58 同城面临的新问题。</p>    <p>【统一检索服务】</p>    <p>数据量很大的时候，不同属性上的查询需求，不可能通过组合索引来满足所有查询需求，怎么办呢？</p>    <p>58 同城的先贤们，从一早就确定了 “外置索引，统一检索服务”的技术路线 ：</p>    <p>（ 1 ）数据库提供“帖子 id ”的正排查询需求</p>    <p>（ 2 ）所有非“帖子 id ”的个性化检索需求，统一走外置索引</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/4cebfe8d8eb9a0d2e9b579c864b2c573.png"></p>    <p>元数据与索引数据的操作遵循：</p>    <p>（1）对帖子进行 tid 正排查询，直接访问帖子服务</p>    <p>（2）对帖子进行修改，帖子服务通知检索服务，同时对索引进行修改</p>    <p>（3）对帖子进行复杂查询，通过检索服务满足需求</p>    <p>这个扛起 58 同城 80% 终端请求（不管来自 PC 还是 APP ，不管是主页、城市页、分类页、列表页、详情页，很可能这个请求最终会是一个检索请求）的服务，就是 <strong> 58 同城另一个统一的核心服务 E-search </strong> ，这个搜索引擎的每一行代码都来自 58 同城 @ 老崔 @ 老龚 等先贤们，目前系统维护者，就是“架构师之路”里屡次提到的 @ 龙神 。</p>    <p>对于这个服务的架构，简单展开说明一下：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/c78b5934ad536710fbd0d6ad84a90ef0.jpg"></p>    <p>为应对 100 亿级别数据量、几十万级别的吞吐量，业务线各种复杂的复杂检索查询， 扩展性是设计重点 ：</p>    <p>（ 1 ） <strong> 统一的 Java 代理层集群 </strong> ，其无状态性能够保证增加机器就能扩充系统性能</p>    <p>（ 2 ） <strong> 统一的合并层 C 服务集群 </strong> ，其无状态性也能够保证增加机器就能扩充系统性能</p>    <p>（ 3 ） <strong> 搜索内核检索层 C 服务集群 </strong> ， 服务和索引数据部署在同一台机器上 ，服务启动时可以加载索引数据到内存，请求访问时从内存中 load 数据，访问速度很快</p>    <p>（ 3.1 ）为了满足数据容量的扩展性， 索引数据进行了水平切分 ，增加切分份数，就能够无限扩展性能</p>    <p>（ 3.2 ）为了满足一份数据的性能扩展性， 同一份数据进行了冗余 ，理论上做到增加机器就无限扩展性能</p>    <p>系统时延， 100 亿级别帖子检索，包含请求分合，拉链求交集，从 merger 层均可以做到 10ms 返回 。</p>    <p>58 同城的帖子业务， 一致性不是主要矛盾 ， E-search 会定期全量重建索引，以保证即使数据不一致，也不会持续很长的时间。</p>    <p>五、总结</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/1ac6348538145b0e82c600fa09cf056f.png"></p>    <p>文章写了很长，最后做一个简单总结，面对 <strong> 100 亿数据量， 1 万列属性， 10 万吞吐量的业务需求 </strong> ， 58 同城的经验，是采用了 元数据服务、属性服务、搜索服务 来解决的。</p>    <p> </p>    <p>来自：http://mp.weixin.qq.com/s/3O3kPSwV-tAeYdy2ZRACpg</p>    <p> </p>