Reprint address : http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659597584&idx=1&sn=67f5327423d7c66c3d3a6d32a040198d&scene=0#rd
With the rapid development of Vipshop's business and the continuous increase in the number of orders, the original order storage structure can no longer meet the company's development. Especially during the peak period of the big promotion, the original order library has become the bottleneck of panic buying, which has seriously restricted the company. development of.
The old order library of Vipshop contains dozens of order-related tables. The old order library is a typical one-master and multiple-slave architecture; the capacity of the master library is close to the upper limit of the physical space of the server, and it has also reached the processing limit of MySQL, which will soon be no longer possible. Process new orders.
The problems faced by the old order library are:
1. Large capacity problem
-
The order-related tables are already super large tables, the data volume of the largest table is already several billions, and the database processing capacity has reached its limit;
-
A single database contains multiple large tables, and the hard disk space occupied is close to the hard disk limit of the server, and there will be no space available soon;
2. Performance issues
The processing capacity of a single server is limited, and the TPS of a single order library also has an upper limit. No matter how it is optimized, the upper limit will always be reached, which limits the order processing capacity per unit time. This problem is more obvious during the big promotion. After the order reaches a certain amount, it can no longer continue to grow, which seriously affects the user experience.
3. Upgrade expansion problem
-
A single main library cannot be flexibly upgraded and expanded, and cannot meet the company's rapid development requirements;
-
All order data is placed in the same library, there is a risk of a single point of failure;
To sum up, capacity and performance issues are urgent problems to be solved. The expansion is to meet the needs of the rapid development of Vipshop in the next 3 to 5 years, without the need to spend manpower and material resources every few months to consider capacity expansion. And other issues.
solution thinking
1. Solve the capacity problem
We can consider that the most direct way is to add large-capacity hard disks, or have higher requirements for IO, and also consider adding SSD hard disks to solve the problem of capacity. This method cannot solve the single-table data volume problem.
It is possible to archive the historical data of the data table, but it also requires frequent archiving operations and does not solve the performance problem.
2. Solve performance problems
提高数据库服务器的配置，这个可以提升一定数量的QPS和TPS，但仍然不能解决单服务器连接数、IO读写存在上限的问题，此方法仍然存在单点故障的问题。
拆分方法探讨
常见的数据库拆分方式有三种：垂直拆分、水平拆分、垂直水平拆分。
1、垂直拆分
垂直拆库是根据数据库里面的数据表的相关性进行拆分，比如：一个数据库里面既存在用户数据，又存在订单数据，那么垂直拆分可以把用户数据放到用户库、把订单数据放到订单库。如下图：
垂直拆表是对数据表进行垂直拆分的一种方式，常见的是把一个多字段的大表按常用字段和非常用字段进行拆分，每个表里面的数据记录数一般情况下是相同的，只是字段不一样，使用主键关联，如下图：
2、水平拆分
水平拆分是把单表按某个规则把数据分散到多个表的拆分方式，比如：把单表1亿数据按某个规则拆分，分别存储到10个相同结果的表，每个表的数据是1千万，拆分出来的表，可以分别放至到不同数据库中，即同时进行水平拆库操作，如下图：
水平拆分可以降低单表数据量，让每个单表的数据量保持在一定范围内，从而提升单表读写性能。但水平拆分后，同一业务数据分布在不同的表或库中，可能需要把单表事务改成跨表事务，需要转变数据统计方式等。
3、垂直水平拆分
垂直水平拆分，是综合了垂直和水平拆分方式的一种混合方式，垂直拆分把不同类型的数据存储到不同库中，再结合水平拆分，使单表数据量保持在合理范围内，提升总TPS，提升性能，如下图：
垂直拆分策略
原订单库把所有订单相关的数据（订单销售、订单售后、订单任务处理等数据）都放在同一数据库中，不符合电商系统分层设计，对于订单销售数据，性能第一，需要能够在大促高峰承受每分钟几万到几十万订单的压力；而售后数据，是在订单生成以后，用于订单物流、订单客服等，性能压力不明显，只要保证数据的及时性即可；所以根据这种情况，把原订单库进行垂直拆分，拆分成订单售后数据、订单销售数据、其他数据等，如下图：
水平拆分策略
垂直拆分从业务上把订单下单数据与下单后处理数据分开，但对于订单销售数据，由于数据量仍然巨大，最大的订单销售相关表达到几十亿的数据量，如果遇到大型促销（如：店庆128、419、618、双十一等等），数据库TPS达到上限，单销售库单订单表仍然无法满足需求，还需要进一步进行拆分，在这里使用水平拆分策略。
订单分表是首先考虑的，分表的目标是保证每个数据表的数量保持在1000~5000万左右，在这个量级下，数据表的大小与性能是最理想的。
如果几十个分表都放到一个订单库里面，运行于单组服务器上，则受限于单组服务器的处理能力，数据库的TPS有限，所以需要考虑分库，把分表放到分库里面，减轻单库的压力，增加总的订单TPS。
1、用户编号HASH切分
使用用户编号哈希取模，根据数据量评估，把单库拆分成n个库，n个库分别存放到m组服务器中，如下图：
每组服务器容纳4个库，如果将来单服务器达到性能、容量等瓶颈，可以直接把数据库水平扩展为2倍服务器集群，还可以继续扩展为4倍服务器集群。水平扩展可以支撑公司在未来3~5年的快速订单增长。
使用用户编号进行 sharding，可以使得创建订单的处理更简单，不需要进行跨库的事务处理，提高下单的性能与成功率。
2、订单号索引表
根据用户编号进行哈希分库分表，可以满足创建订单和通过用户编号维度进行查询操作的需求，但是根据统计，按订单号进行查询的占比达到80%以上，所以需要解决通过订单号进行订单的CURD等操作，所以需要建立订单号索引表。
订单号索引表是用于用户编号与订单号的对应关系表，根据订单号进行哈希取模，放到分库里面。根据订单号进行查询时，先查出订单号对应的用户编号，再根据用户编号取模查询去对应的库查询订单数据。
订单号与用户编号的关系在创建订单后是不会更改的，为了进一步提高性能，引入缓存，把订单号与用户编号的关系存放到缓存里面，减少查表操作，提升性能，索引不命中时再去查表，并把查询结果更新到缓存中。
3、分布式数据库集群
订单水平分库分表以后，通过用户编号，订单号的查询可以通过上面的方法快速定位到订单数据，但对于其他条件的查询、统计操作，无法简单做到，所以引入分布式数据库中间件。
下图是基本构架：
总结与思考
技术架构与业务场景息息相关，不能脱离实际的业务场景、历史架构、团队能力、数据体量等等去做架构重构，对于一家快速发展的电子商务公司，订单系统是核心，订单库是核心的核心，订单库的重构就像汽车在高速公路上跑着的过程中更换轮胎。
本文是对唯品会订单库重构——采用分库分表策略对原订单库表进行拆分的粗略总结，在订单库重构过程中遇到的问题远远超过这些，比如：历史数据的迁移、各外围系统的对接等，但这些在公司强大的技术团队面前，最终都顺利的解决，新旧订单库顺利的切换，给公司快速的业务发展提供坚实的保障。