订单系统设计 —— 订单管理

疯就要疯的够特 · 发布于 2023-4-20 14:13:49

文章目录

一、方案背景

订单系统是存在于各行各业的一个很根底、核心的业务系统。随着互联网的开展，订单系统的管理方案也在不时变化，订单数据规模的膨胀、用户对数据的重视，以及新的技术等都会影响订单管理方案。
1.1 考虑因素

数据量：

多维查询分析：

性能：

1.2 数据特点

订单数据具有明显的时间属性，主要呈现出两个特点：

二、方案演进

技术架构不是设计出来的，是演化出来的。订单管理方案也是随着业务和技术的开展，不时演化的，如下图所示。依照技术架构特点，大致分为三类：

说明：订单是个性化的数据，每个用户的订单数据都不同，不适宜使用缓存；
三、MySQL架构

3.1 单库单表

最简单的订单管理方案，适用于创业初期，便于商业模型的快速落地验证；
3.2 读写分别

处置问题： 单库性能到达极限，成为系统性能瓶颈点；
核心思想：增加从库，单点写入，多点读取（提升读性能）。目前主流方案都是走代理，比如阿里云的RDS，因为对用户完全透明，主从复制、主从切换，以及读写分别等工作由DBA来维护，如下图所示：

主从同步延时问题： 正常情况下，主从同步延时都是在1ms以内。但是，当网络抖动或者数据库负载过高时，主从延时可能会变大，导致主从数据呈现暂时不一致的情况。这种问题有三种处置方案：

3.3 垂直拆分

随着业务开展，订单表字段越来越多，职责不明晰，维护费事。将相同功能的字段为一组停止拆分，职责明晰，容易维护和扩展。
3.4 数据归档/冷热分别

处置问题： 单库数据量过多导致读写性能下降（RT变高）；
核心思想：利用订单“长尾效应”的特点，将历史数据迁移到其它库（冷库），为热库瘦身，从而提升性能，如下图所示：

注意点：

3.5 分库分表

处置问题： 支持更高的并发量和数据量，处置单库性能和数据量的瓶颈；
核心思想： 数据分片，关键是分片key和分片算法。目前主流的方案有两种：路由表和哈希。
方案1：路由表

路由表存储key与数据存储位置的映射关系，每次查询数据时，先查询路由表获取数据位置，然后再查询数据，如下图所示。

方案2：哈希

哈希算法自身很简单，在订单场景下需要考虑的是，分库分表的key是什么，如何同时满足用户侧和商家侧的查询需求。比如，假设依照订单id分库分表，用户的订单列表和商家的订单列表则需要全表扫描，用户id和商家id也是同理。
整体思路： 订单数据一式两份，分为用户库和商家库（只读）。对于用户库，依照订单id分库分表，用户id的某几位信息参与到订单id中（“因子分表法”，见订单号设计），同时满足用户id和订单id维度的查询；对于商家库，依照商家id对订单重哈希路由，如下图所示：

容量评估

500 万行

2GB

四、MySQL + NoSQL架构

4.1 MySQL + ES

处置问题： 分库分表的查询才干有限，无法支持复杂灵敏的查询；
核心思想： 引入ES，建立热点查询到订单ID的映射关系，用于支持复杂的查询条件。复杂查询通过ES获取对应的订单ID，再从数据库从库查询获得订单，如下图所示：

注意点

4.2 MySQL + ES + HBase

处置问题： 处置订单详情查询时间长问题（需要去订单表及其关联表屡次查询）;
核心思想： 引入HBase，将订单及其关联表全量字段导入HBase，RowKey为订单id，如下图所示：

五、将来预期: NewSQL

当前关系型数据库仍是主流的原因就在于其事务特性，NoSQL由于其高性能、高扩展和高存储量特性，成了目前技术方案的标配之一，以上所有的订单存储方案归纳起来就是MySQL + NoSQL的组合，将来NewSQL假设真正的能做到NewSQL = MySQL + NoSQL，订单的管理方案势必会被极大的简化，期待。
参考