分库分表；
多应用实例全局唯一订单号；
数据库连接；
买家查询订单；
卖家查询订单；
扩容问题；
业务拆分；
随着电商系统订单量的增长，订单管理系统开发数据库的发展主要经历以下几个步骤：
- 1主-1从架构 ；
- 双主-多从架构，读写分离 ；
- 表分区，提高并发 ；
- 分表，提高并发 ；
- Master更换SSD ；
- 分库，分表，提高并发；
电商系统订单分成16个库，每个库64个表进行存储，总共1024个表，mysql单表性能超过千万级别会导致性能严重下降，假设按千万计算，最高可以存储百亿级订单。随着存储问题的解决，但复杂度会随着增加：
首先是多库怎么保证生成的电商系统订单号全局唯一；
其次电商订单管理系统查询复杂度的增加；
买家查询电商订单时，应该去哪个库哪个表里查找，卖家应该去哪查；
再大的存储量，随着数据量的增长，终究是会遇到瓶颈，该怎么扩容。
这里采用Twitter snowflake方案，全剧唯一ID生成由：时间戳+机器ID+自增序列（+userid后两位），订单的生成过程直接在应用实例中生成，直接在内存中计算，且计算过程分散到每台应用实例中，解决性能问题，userid后两位在后面解释。
分库分表后，要连接数据库变的复杂起来，分为两种电商方案：
此种方式需要在应用代码中，自己计算订单应该进入哪个库，可取订单的后两位，先对库16进行取模，再对表64取模，从而确定。优点是直连数据库性能更好，缺点是代码复杂度增加。
中间价可以使用阿里的mycat连接，具体使用查看mycat文档。优点：代码实现简单，跟分库前差不多。
电商系统订单成交后，买家需要查询订单的时候，只有userid，并不知道订单存在哪个库哪张表中，从每个库每个表中遍历一遍不现实。所以还要对订单号进行改进，之前是：时间戳+机器ID+自增序列。现在此订单号的后面加上userid的后两位，时间戳+机器ID+自增序列+userid后两位。订单入库取模的后两位即userid后两位，即同一个买家的所有订单都会存入同一个表中，通过此设计买家即可找到订单号应该在哪个表中。
卖家查询订单不能像买家一样，卖家的订单分散在订单表的各个表中。卖家订单需要在业务拆分过程中，将电商系统订单按卖家维度存入到别的库和表中。此维度不仅卖家可以查询到对应所有订单，并且方便统计、分析。
由于此方案已经不是单纯的通过电商系统订单号查找订单，还需要通过userid查找订单，其次是电商系统订单具有时间特性，用户查询的大部分都是最近的订单，3月前的订单很少会查看，所以不适合进行扩容，特别适合迁移历史数据，将3个月前的数据迁移到历史数据库中，从而解决容量增长的问题。
下电商系统订单过程，业务极其复杂，不只是电商系统订单号的生成插入等，还要减库存、支付等一系列的操作。所以应该通过消息队列将业务进行拆分，本步骤只做电商系统订单生成的操作，通过消息队列实现数据的最终一致性。
作者：章绍龙 ，来源：CSDN ；
<数商云（www.shushangyun.hk）是全球知名的企业级电子商务系统开发商，为企业提供专业的电商系统开发解决方案，其产品服务包含：B2B电子商务系统建设、B2B2C多用户商城系统开发、B2C电商平台搭建、新零售电商、社交电子商务平台、视频直播平台、大数据电商平台、跨境进出口电商平台等等各行业大型电子商务平台搭建服务，其产品优势：系统安全性高、可扩展性强、集群式部署、支持高并发量和高访问量>
