云时代架构之订单系统架构这样演进

饿了么：业务井喷时，订单系统架构这样演进

　　要实现高并发订单系统架构设计，要解决如下几个方面的问题，分库分表、多应用实例全局惟一订单号、数据库链接、买家查询订单、卖家查询订单、扩容问题和业务拆分。

分库分表：随着订单量的增加，数据库的发展主要经历如下几个步骤： 1主-1从架构；双主-多从架构，读写分离；表分区，提升并发 ；分表，提升并发 ；Master更换SSD ；分库，分表，提升并发。

　　分库分表实现过程：订单分红16个库，每一个库64个表进行存储，总共1024个表，mysql单表性能超过千万级别会致使性能严重降低，假设按千万计算，最高能够存储百亿级订单。随着存储问题的解决，但复杂度会随着增长：首先是多库怎么保证生成的订单号全局惟一； 其次查询复杂度的增长； 买家查询订单时，应该去哪一个库哪一个表里查找，卖家应该去哪查； 再大的存储量，随着数据量的增加，终究是会遇到瓶颈，该怎么扩容。

　　全局惟一订单号：这里采用Twitter snowflake方案，全剧惟一ID生成由：时间戳+机器ID+自增序列（+userid后两位）； 
订单的生成过程直接在应用实例中生成，直接在内存中计算，且计算过程分散到每台应用实例中，解决性能问题，userid后两位在后面解释。

　　数据库链接问题：分库分表后，要链接数据库变的复杂起来，分为两种方案：jdbc直连：此种方式须要在应用代码中，本身计算订单应该进入哪一个库，可取订单的后两位，先对库16进行取模，再对表64取模，从而肯定。优势是直连数据库性能更好，缺点是代码复杂度增长。经过中间价链接：中间价可使用阿里的mycat链接，具体使用查看mycat文档。优势：代码实现简单，跟分库前差很少。

　　买家查询订单：订单成交后，买家须要查询订单的时候，只有userid，并不知道订单存在哪一个库哪张表中，从每一个库每一个表中遍历一遍不现实。因此还要对订单号进行改进，以前是：时间戳+机器ID+自增序列。如今此订单号的后面加上userid的后两位，时间戳+机器ID+自增序列+userid后两位。订单入库取模的后两位即userid后两位，即同一个买家的全部订单都会存入同一个表中，经过此设计买家便可找到订单号应该在哪一个表中。

　　卖家查询订单：卖家查询订单不能像买家同样，卖家的订单分散在订单表的各个表中。卖家订单须要在业务拆分过程当中，将订单按卖家维度存入到别的库和表中。此维度不只卖家能够查询到对应全部订单，而且方便统计、分析。

　　扩容问题：因为此方案已经不是单纯的经过订单号查找订单，还须要经过userid查找订单，其次是订单具备时间特性，用户查询的大部分都是最近的订单，3月前的订单不多会查看，因此不适合进行扩容，特别适合迁移历史数据，将3个月前的数据迁移到历史数据库中，从而解决容量增加的问题。

　　业务拆分：下订单过程，业务极其复杂，不仅是订单号的生成插入等，还要减库存、支付等一系列的操做。因此应该经过消息队列将业务进行拆分，本步骤只作订单生成的操做，经过消息队列实现数据的最终一致性。

　　在我看来，相似订单的这类系统，主要考虑清楚业务流程和数据库表的设计便可，这样既能保证整个流程不会出错，还能提升系统的响应速度。

文章来源：

https://blog.csdn.net/zhaoliang831214/article/details/83342644