订单系统设计 —— 数据同步与监控

一、方案背景

  当订单数据量规模足够大或查询统计足够复杂时，通常会采用MySQL + NoSQL的架构方案，这种方案需要将MySQL中数据同步到其它介质，比如HBase、ES，或者阿里云的TableStore等。订单数据的同步面临着诸多挑战，尤其是异构介质，下面会从”数据同步面临的挑战“和以及”订单数据特点“两个维度来分析。

1.1考虑因素

1. 性能和稳定性： 订单系统为每个公司的核心业务系统，数据的同步尽量对订单系统无感，换言之，同步双写的方案会影响订单系统的性能和稳定性；
2. 幂等性： 同步RPC和异步消息，都可能产生重复数据，数据落入HBase和ES时需要考虑数据去重，保证幂等性；
3. 顺序性： 由于网络的不确定性，有可能数据库中先更新的数据后到达HBase或ES，导致最新的数据被旧数据覆盖；
4. 关联性： 通常订单数据会包含很多信息，库表设计时通常会进行垂直拆分，通过订单号进行关联，当进行数据同步时，如何处理这些关联表的数据需要考虑；

1.2 数据特点

1. 存量数据： 已完成或结束的订单归纳为”存量数据“，其特点是：数据量大、只读（没有变更，无需考虑顺序性）；
2. 增量数据： 未结束的订单归纳为”增量数据“，其特点是：并发量大、数据变更比较频繁（需要考虑顺序性）；

二、增量同步方案

  整体思路： 将数据库的Binlog解析成消息，异步同步到HBase或ES，保障对订单系统的无感。利用订单号的唯一性，在HBase或ES进行物理去重；每条数据携带版本，通过版本号保障新数据不会被旧数据覆盖；对于订单相关联的表数据，在HBase和ES中会将数据打平，以宽表的形式存储，因为HBase和ES并不擅长“关系”的处理，性能开销很大。

2.1 并发消费

  整体流程：Canal将Binlog日志转换成MQ消息，同步程序并发消费消息（最大化消费能力），然后先将数据写入HBase，然后将HBase中订单对应的宽表数据写入ES。这里有几点需要说明：

1. HBase有版本控制机制，而且是字段级别的，只有更大版本号的数据才能更新字段，利用这个特点可以防止新数据被覆盖，同时也能够用一个宽表来聚合/扁平化订单关联表；
2. ES也有版本控制机制，但是是文档/行级别的，无法进行字段级别的更新，这就导致无法用一个宽表来聚合/扁平化订单关联表，因此现在HBase中生成宽表，同时有个额外的Version字段（每次更新HBase时都更新为当前时间），将HBase的Version作为ES的外部版本；

2.2 顺序消费

  整体流程与方案1类似，区别在于：发送消息时根据订单号哈希，将相同订单关联的数据发送到相同的队列，同时同步程序需要进行顺序消费（消费能力受限，需要保持消息队列和消费实例为1:1进行水平扩容），另外为了保持顺序性，每个订单相关联的表应该在相同库中，具体流程如下所示：

2.3 1:N关联数据

  订单关联表中，经常会遇到1:N的关联关系，比如一个订单多个商品场景。数据同步时，主要利用了HBase的动态列的特性来处理这种一对多的关系，如下图所示，每列可以表示一个商品（商品粒度），也可以进一步细化到商品的每个字段（字段维度），通过id来区分。

三、存量同步方案

  整体思路： 基于DataX进行离线数据的同步。由于高性能、高扩展以及对多种数据源的支持，DataX已经成为离线数据同步工具的首选，不过由于开源的是单机版本，需要结合调度系统一起完成。

3.1 并发同步

  为订单及其关联表每个表分配一个同步任务，并发进行同步，基于HBase聚合/扁平化数据，数据版本统一为V1，然后再通过DataX或MQ消息将数据从HBase同步到ES，如下图所示：

• 优点：并发度高、速度快（数据读取都是简单SQL），数据库压力小（只需同步到HBase）；
• 缺点：暂无

3.2 基于视图同步

  ES不再依赖于HBase同步数据，而是通过视图，将订单及其关联表组成一张宽表，如下图所示：

• 优点：ES同步链路不再依赖HBase；
• 缺点：数据量大时，关联查询速度会很慢；
  

四、监控与补偿机制

4.1 延迟监控

  数据同步链路的监控分为两方面：链路中各节点的系统监控，以及延迟检测。延迟检测为业务艰监控，主要思想就是记录数据进出各节点的时间，通过时间差判断是否发生延时，正常情况下同步延迟在1s以内，如果超时则触发告警。各节点的异常分析如下：

• 数据库负载过高或异常：业务操作异常或超时，触发业务告警；
• Canal负载过高或异常：Canal系统告警；
• 同步程序负载过高或异常：消息堆积触发MQ告警，延迟过大触发业务告警；
• ES/HBase负载过高或异常：消息堆积触发MQ告警，同步异常触发业务告警，ES/HBase告警；

4.2 补偿机制

• 订单系统/数据库异常：下单失败，无新数据产生，无需补偿，需解决Bug修复；
• Canal异常：异常期间，可以通过查询DB的方式同步数据，或者订单系统降级走DB；
• 同步程序/ES/HBase异常：数据无法写入，无需补偿，需解决Bug修复，恢复期间订单系统采取降级方案，查询可以临时走DB；

参考

• Elasticsearch多表关联设计指南
• 有赞订单同步的探索与实践