订单系统设计 --- SaaS订单中心存储方案

SaaS订单中心作用

  为垂直领域的商家提供订单管理能力，管理线上（各种互联网平台渠道）、线下等不同渠道的订单；

需求分析

  只是为商家端提供订单管理能力，其特点是访问频次低，查询数据量大，需要支持灵活的订单查询，能够容忍一定的延时（相对于C端）；

存储方案设计

• 读写分离：写请求到主库，读请求到备库（主备同步有ms级别延时，实时性要求特别高的可以显式指定主库）；
• 水平拆分 + 基因法：按照商户id水平拆分，订单id中融入商户id分库基因来支持基于订单id的查询；
• 垂直拆分 + 信息冗余：订单表数据过多时需要垂直拆分，订单表只保留最核心的数据，其余属性拆分成单独的表，同时可以在订单表中冗余部分经常被查询到的信息，提高查询效率；
• ES外置索引：利用ES聚合分表数据，同时建立到订单id的索引；（通过ES支持复杂的查询，获得订单id，然后从DB查询订单信息，ES只是存储索引，不存储订单数据，因为存储成本太高）
• 冷热分离/数据归档：订单中心的特点是时间越久被访问的频次越低，可以按照时间维度划分冷人数据，冷数据归档存储到OSS等云存储上（便宜、弹性且支持多种计算引擎），既可以让数据库瘦身保持性能，同时也能降低存储成本；

数据倾斜方案

  现象： 按照门店或商家分库分表时，由于个别门店/商家订单数据量大，导致分表数据不均匀，个别分表数据量特别多；

  影响： 如果不扩容，个别分表的容量会特别大，出现性能问题，影响到同个分表的其它门店或商家；如果扩容，导致空间浪费，因为大部分分表并不需要扩容；

方案1：均匀打散

  方案： 数据量大的门店或商家均匀打散到各分表中（门店id固定无法均匀打散，需使用随机因素），其它门店或商家仍按照门店id分表，通过ES聚合分表数据，查询时先查询ES到订单id及其所在分表，然后从数据库查询对应的订单；
  缺点： 数据量大的门店或商家无法直接按照门店查询数据库，需要先查询ES外置索引，查询时延增加；

方案2：独立存储

  方案： 数据量大的门店或商家存储到单独的表，其它门店或商家仍按照门店id分表，通过ES聚合分表数据，查询时先查询ES获取到订单id及其所在分表，然后从数据库查询对应的订单；
  缺点： 需要先查询ES外置索引，查询时延增加，门店或商家数据量大时仍需要考虑分表；

参考：

1. 1对多业务，数据库水平切分架构一次搞定 | 架构师之路