vivo-全球商城：亿级订单中心架构设计与实践.docx

? ? vivo 全球商城 亿级订单中心架构设计与实践 ? ? 一、背景 随着用户量级的快速增长，vivo 官方商城 v1.0 的单体架构逐渐暴露出弊端：模块愈发臃肿、开发效率低下、性能出现瓶颈、系统维护困难。 从2017年开始启动的 v2.0 架构升级，基于业务模块进行垂直的系统物理拆分，拆分出来业务线各司其职，提供服务化的能力，共同支撑主站业务。 订单模块是电商系统的交易核心，不断累积的数据即将达到单表存储瓶颈，系统难以支撑新品发布和大促活动期间的流量，服务化改造势在必行。 本文将介绍 vivo 商城 订单系统建设的过程中遇到的问题和解决方案，分享架构设计经验。 二、系统架构 将订单模块从商城拆分出来，独立为订单系统，使用独立的数据库，为商城相关系统提供订单、支付、物流、售后等标准化服务。 系统架构如下图所示： 三、技术挑战 3.1?数据量和高并发问题 首先面对的挑战来自存储系统： 数据量问题 随着历史订单不断累积，MySQL中订单表数据量已达千万级。 我们知道InnoDB存储引擎的存储结构是B+树，查找时间复杂度是O(log n)，因此当数据总量n变大时，检索速度必然会变慢， 不论如何加索引或者优化都无法解决，只能想办法减小单表数据量。 数据量大的解决方案有：数据归档、分表 高并发问题 商城业务处于高速发展期，下单量屡创新高，业务复杂度也在提升，应用程序对MySQL的访问量越来越高。 单机MySQL的处理能力是有限的，当压力过大时，所有请求的访问速度都会下降，甚至有可能使数据库宕机。 并发量高的解决方案有：使用缓存、读写分离、分库 下面对这些方案进行简单描述： 数据归档 订单数据具备时间属性，存在热尾效应，大部分情况下检索的都是最近的订单，而订单表里却存储了大量使用频率较低的老数据。 那么就可以将新老数据分开存储，将历史订单移入另一张表中，并对代码中的查询模块做一些相应改动，便能有效解决数据量大的问题。 使用缓存 使用Redis作为MySQL的前置缓存，可以挡住大部分的查询请求，并降低响应时延。 缓存对商品系统这类与用户关系不大的系统效果特别好，但对订单系统而言，每个用户的订单数据都不一样，缓存命中率不算高，效果不是太好。 读写分离 主库负责执行数据更新请求，然后将数据变更实时同步到所有从库，用多个从库来分担查询请求。 但订单数据的更新操作较多，下单高峰时主库的压力依然没有得到解决。且存在主从同步延迟，正常情况下延迟非常小，不超过1ms，但也会导致在某一个时刻的主从数据不一致。 那就需要对所有受影响的业务场景进行兼容处理，可能会做一些妥协，比如下单成功后先跳转到一个下单成功页，用户手动点击查看订单后才能看到这笔订单。 分库 分库又包含垂直分库和水平分库。 ① 水平分库：把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。 ② 垂直分库：按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，它的核心理念是专库专用。 分表 分表又包含垂直分表和水平分表。 ①?水平分表：在同一个数据库内，把一个表的数据按一定规则拆到多个表中。 ②?垂直分表：将一个表按照字段分成多表，每个表存储其中一部分字段。 我们综合考虑了改造成本、效果和对现有业务的影响，决定直接使用最后一招：分库分表 3.2 分库分表技术选型 分库分表的技术选型主要从这几个方向考虑： 客户端sdk开源方案 中间件proxy开源方案 公司中间件团队提供的自研框架 自己动手造轮子 参考之前项目经验，并与公司中间件团队沟通后，采用了开源的 Sharding-JDBC 方案。现已更名为Sharding-Sphere。 Github： /sharding-sphere/ 文档：官方文档比较粗糙，但是网上资料、源码解析、demo比较丰富 社区：活跃 特点：jar包方式提供，属于client端分片，支持xa事务 3.2.1 分库分表策略 结合业务特性，选取用户标识作为分片键，通过计算用户标识的哈希值再取模来得到用户订单数据的库表编号. 假设共有n个库，每个库有m张表， 则库表编号的计算方式为： - 库序号：Hash(userId) / m % n - 表序号：Hash(userId) % m 路由过程如下图所示： 3.2.2?分库分表的局限性和应对方案 分库分表解决了数据量和并发问题，但它会极大限制数据库的查询能力，有一些之前很简单的关联查询，在分库分表之后可能就没法实现了，那就需要单独对这些Sharding-JDBC不支持的SQL进行改写。 除此之外，还遇到了这些挑战： （1）全局唯一ID设计 分库分表后，数据库自增主键不再全局唯一，不能作为订单号来使用，但很多内部系统间的交互接口只有订单号，没有用户标识这个分片键，如何用订单号