订单系统是存在于各行各业的一个很基础、核心的业务系统。随着互联网的发展，订单系统的管理方案也在不断变化，订单数据规模的膨胀、用户对数据的重视，以及新的技术等都会影响订单管理方案。
数据量： 订单的特点是只增不减，随着时间推移，订单量会越来越多；
多维查询分析： 能够灵活的支持不同角色用户多种维护的查询和分析；
性能： 订单管理服务需要只能高并发、低延迟；
订单数据具有明显的时间属性，主要呈现出两个特点：
技术架构不是设计出来的，是演化出来的。订单管理方案也是随着业务和技术的发展，不断演化的，如下图所示。按照技术架构特点，大致分为三类：
说明： 订单是个性化的数据，每个用户的订单数据都不同，不适合使用缓存；
最简单的订单管理方案，适用于创业初期，便于商业模型的快速落地验证；
解决问题： 单库性能达到极限，成为系统性能瓶颈点；
核心思想：增加从库，单点写入，多点读取（提升读性能）。目前主流方案都是走代理，比如阿里云的RDS，因为对用户完全透明，主从复制、主从切换，以及读写分离等工作由DBA来维护，如下图所示：
主从同步延时问题： 正常情况下，主从同步延时都是在1ms以内。但是，当网络抖动或者数据库负载过高时，主从延时可能会变大，导致主从数据出现暂时不一致的情况。这种问题有三种解决方案：
随着业务发展，订单表字段越来越多，职责不清晰，维护麻烦。将相同功能的字段为一组进行拆分，职责清晰，容易维护和扩展。
解决问题： 单库数据量过多导致读写性能下降（RT变高）；
核心思想：利用订单“长尾效应”的特点，将历史数据迁移到其它库（冷库），为热库瘦身，从而提升性能，如下图所示：
注意点：
解决问题： 支持更高的并发量和数据量，解决单库性能和数据量的瓶颈；
核心思想： 数据分片，关键是分片key和分片算法。目前主流的方案有两种：路由表和哈希。
路由表存储key与数据存储位置的映射关系， 每次查询数据时，先查询路由表获取数据位置，然后再查询数据，如下图所示。
哈希算法本身很简单，在订单场景下需要考虑的是，分库分表的key是什么，如何同时满足用户侧和商家侧的查询需求。比如，如果按照订单id分库分表，用户的订单列表和商家的订单列表则需要全表扫描，用户id和商家id也是同理。
整体思路： 订单数据一式两份，分为用户库和商家库（只读）。对于用户库，按照订单id分库分表，用户id的某几位信息加入到订单id中（“因子分表法”，见订单号设计），同时满足用户id和订单id维度的查询；对于商家库，按照商家id对订单重哈希路由，如下图所示：
建立单独的商家库，是为了物理上隔离商户查询对用户的影响；
商家库只读是为了单点写入，方便维护数据的一致性；
如果允许商家订单数据，则商家库只维护商家与订单的映射关系（路由表）；
容量评估
分库数量 = 峰值并发量 / 单库的IOPS；
分表数量 = 数据量 / 单表容量（阿里Java开发规范的建议值：单表行数超过 500 万行或者单表容量超过 2GB）；
解决问题： 分库分表的查询能力有限，无法支持复杂灵活的查询；
核心思想： 引入ES，建立热点查询到订单ID的映射关系，用于支持复杂的查询条件。复杂查询通过ES获取对应的订单ID，再从数据库从库查询获得订单，如下图所示：
注意点
解决问题： 解决订单详情查询时间长问题（需要去订单表及其关联表多次查询）;
核心思想： 引入HBase，将订单及其关联表全量字段导入HBase，RowKey为订单id，如下图所示：
当前关系型数据库仍是主流的原因就在于其事务特性，NoSQL由于其高性能、高扩展和高存储量特性，成了目前技术方案的标配之一，以上所有的订单存储方案归纳起来就是MySQL + NoSQL的组合，未来NewSQL如果真正的能做到NewSQL = MySQL + NoSQL，订单的管理方案势必会被极大的简化，期待。
参考
