图片由通义万相生成
交易订单业务
大白话: 交易订单业务是在线交易的核心业务单元 。交易其实就是用户从各个平台买东西,搜索到自己需要的商品,领优惠券,然后点击下单购买,再进行支付,卖家发货,买家确认收货这样的一个流程。
从上图可知,交易链路涉及系统繁多,业务逻辑也非常复杂,最简化的说,从表存储往上看, 不管业务逻辑如何,只是涉及到读写纬度的访问逻辑:
写入:
读取
任何产品和业务都是从 0 到1 ,然后逐步发展到1到100,到1w 甚至更高的业务量。随着数据量增加,业务对数据的存取使用更加复杂,首先要解决的是面对海量业务数据,如何解决 订单表的设计和数据存储。
本文介绍订单表的设计相关事项,其实还有其他问题,比如 热点大卖家,海量数据存储成本问题,如何解决数据查询和归档,等等。
电商业务刚刚开始发展时,订单表是以单表存储的。因为数据量相对较少,几百万w ,甚至几千万的量级。单个表就能满足 买卖家纬度的各种查询,随着业务的不断发展,单表的问题逐步凸显出来。
问题
为了应对海量的数据增长,我们需要对业务数据进行分库或者分库分表操作。此时业务面临的问题在于: 如何合理设置合理的分表规则,拆分规则 才能满足业务对数据的访问需求。
我们通常使用的分表规则是选取业务表的某一列作为分表键进行哈希打散到各个数据库中。基于前面的业务访问情况,我们可以选择的分表键键有买家id,卖家id,订单号。
比如 交易数据库计划分128个库, 分2048张分表。
对于买家id buy_id 取模 比如 buy_id
%2048%128 ,先分表,然后再落到不同的分库里面。
注意 这里
buy_id
%2048%128 是直接取模2048,再分配到 128个分库里面 ,其实关于取模可以加上业务逻辑,比如如果提前规划业务多活的话,就要取更大范围比如 10000, 将分表键范围锁定 0-9999,比取模 2048 多4倍的,将数据更均匀的打散到不同的数据库中。
优点:
缺点:
对于卖家id进行 取模分表 , seller_id
%2046%128
缺点:
基于 进行订单号取模,order_no
%2046%128
优点:
缺点:
虽然说本文是说的订单数据设计,但是也适用于其他业务场景,从小业务量到海量数据的数据库演进。
另外良好的IT,业务架构是演进出来的,并非是一步到位,就能达到完美的架构。