Vivo全球商城：订单中心架构设计与实践

大数据

2022-12-16 发布浏览：1127 次

随着用户数量的快速增长，官方Vivo商城v1.0的单体架构逐渐暴露出其弊端：模块变得更加臃肿，开发效率低下，性能瓶颈，系统维护困难。

v2.0架构升级始于2017年，基于业务模块的垂直系统物理拆分。业务线被拆分，以履行各自的职责，提供服务能力，并共同支持主站业务。

订单模块是电子商务系统的交易核心，正在积累的数据将很快达到单表存储瓶颈。该系统很难在新产品发布和促销活动期间支持流量，因此面向服务的转型势在必行。

本文将介绍Vivo商城订单系统建设中遇到的问题和解决方案，并分享架构设计经验。

订单模块与商场分开，商场独立于订单系统，并使用独立的数据库为商场的相关系统提供订单、支付、物流和售后等标准化服务。

系统架构如下图所示：

第一个挑战来自存储系统：

数据量问题

随着历史订单的不断积累，MySQL中的订单表数据量已达数千万。

我们知道InnoDB存储引擎的存储结构是一个B+树，搜索时间复杂度为O（logn）。因此，当数据总量n增加时，检索速度必然会减慢。无论您如何添加索引或优化索引，都只能找到减少单个表中数据量的方法。

针对大量数据的解决方案包括数据归档和表拆分

高并发性

商场业务正处于快速发展时期。下订单的数量达到了新的高度。业务复杂性也在增加。访问MySQL的app越来越多。

单个MySQL的处理能力是有限的。当压力过高时，所有请求的访问速度都会降低，甚至数据库可能会关闭。

高并发性解决方案包括：缓存、读/写分离和子数据库

这些方案简述如下：

数据归档

订单数据具有时间属性和热尾效应。在大多数情况下，检索最新的订单，而订单表中存储了大量使用频率较低的旧数据。

然后新的和旧的数据可以分开存储，历史顺序可以移动到另一个表，代码中的查询模块可以相应地修改，以有效地解决大数据的问题。

使用缓存

使用Redis作为MySQL的预缓存可以阻止大多数查询请求并减少响应延迟。

缓存对于与用户关系不大的系统特别有效，例如商品系统，但对于订单系统，每个用户的订单数据不同，缓存命中率也不高，所以效果不是很好。

形象

读写分离

主数据库负责执行数据更新请求，然后将数据更改实时同步到所有从属数据库。多个从属数据库用于共享查询请求。

然而，由于大量的订单数据更新操作，在下单高峰期间主数据库的压力尚未得到解决。此外，还有主从同步延迟。通常情况下，延迟很小，不超过1ms，但也会导致在某个时间主从数据不一致。

然后，所有受影响的业务场景都需要以兼容的方式处理，并且可能会做出一些妥协。例如，下单成功后，用户将跳转到一个成功的订单页面，用户只有在手动单击“查看订单”后才能查看订单。

形象

次级国库

子数据库还包括垂直子数据库和水平子数据库。

① 水平子数据库：同一个表的数据按照一定的规则被分解成不同的数据库，每个数据库可以放在不同的服务器上。

② 垂直子数据库：表根据业务分类并分布到不同的数据库。每个数据库可以放置在不同的服务器上。其核心思想是将特殊数据库用于特殊目的。