唯品会架构是如何实现重构的唯品会架构是如何实现重构的
随着唯品会业务的快速发展,订单量的不断增长,原有的订单存储架构已经不能满足公司的发展了,特别是在大促高峰期,原
订单库已经成为抢购瓶颈,已经严重制约公司的发展。
唯品会旧订单库包含几十张订单相关表,旧订单库是典型的一主多从架构;主库容量已接近服务器物理空间上限,同时也已经
达到 MySQL 的处理上限,很快将无法再处理新增订单。
旧订单库面临的问题有:
1、超大容量问题
订单相关表都已经是超大表,最大表的数据量已经是几十亿,数据库处理能力已经到了极限;
单库包含多个超大表,占用的硬盘空间已经接近了服务器的硬盘极限,很快将无空间可用;
2、性能问题
单一服务器处理能力是有限的,单一订单库的 TPS 也有上限,不管如何优化,总会有达到上限,这限制了单位时间的订单处
理能力,这个问题在大促时更加明显,如果不重构,订单达到一定量以后,就无法再继续增长,严重影响到用户体验。
3、升级扩展问题
单一主库无法灵活的进行升级和扩展,无法满足公司快速发展要求;
所有的订单数据都放在同一库里面,存在单点故障的风险;
综上所述,容量、性能问题是急需解决的问题,扩展是为了将来 3~5 年内能够很好的满足唯品会快速发展的需要,而不需要
每隔几个月花费人力物力去考虑扩容等问题。
解决方法思考
1、解决容量问题
我们可以考虑到最直接的方式是增加大容量硬盘,或者对 IO 有更高要求,还可以考虑增加 SSD 硬盘来解决容量的问题。此
方法无法解决单表数据量问题。
可以对数据表历史数据进行归档,但也需要频繁进行归档操作,而且不能解决性能问题。
2、解决性能问题
提高数据库服务器的配置,这个可以提升一定数量的 QPS 和 TPS,但仍然不能解决单服务器连接数、IO 读写存在上限的问
题,此方法仍然存在单点故障的问题。
拆分方法探讨
常见的数据库拆分方式有三种:垂直拆分、水平拆分、垂直水平拆分。
1、垂直拆分
垂直拆库是根据数据库里面的数据表的相关性进行拆分,比如:一个数据库里面既存在用户数据,又存在订单数据,那么垂直
拆分可以把用户数据放到用户库、把订单数据放到订单库。如下图: