有赞亿级订单同步的探索与实践

1、有赞亿级订单同步的探索与实践1.1 同步现状当前有赞订单同步流程及业务现状所示，采纳了 es+hbase（tip1）架构体系去解决搜寻和细节的需求，利用 canal（tip2）将数据库变更写入到 mq 中，然后利用同步系统来解决相关数据同步问题，而后续下文中将讲述有赞订单同步濒临的问题及应对计划。二、同步2.1 实现同步基础 - 单表同步2.1.1 乱序问题单表同步业务场景中，在这任何一个序号链路中，假如并发浮现同一主键的两条消息，同时在 nosql 中没有做版本控制，都有可能造成消息乱序问题，而相反，假如通过挨次解析 binlog 的同时，为每条 statement sql 执行的结果分配一

2、个挨次 seqno，该 seqno 保证有序（tip3），再通过 nosql 中控制积极锁就可以解决挨次性问题。2.1.2 hbase 同步hbase 同步相对来说比较容易，hbase 内部拥有 timestamp 帮助控制每个 qualify 的版本，只要让 timestamp 传入上文所说的挨次 seqno，那么就可以保证每个字段读取出来的数据是终于全都性的。2.1.3 es 同步es 同步针对单表场景可以通过 index 的操作来举行写入，index 可以采纳 exteneral 版本也称作外部版本号来举行控制，同样适用上述的 seqno 来做积极锁去解决该问题。2.1.4 同步过程图2

3、.2 实现同步进阶 - 多表同步2.2.1 乱序问题多表同步基于单表同步的基础上做相关的同步，当数据库的两张表（不关怀是否在一个实例上，假如不在，还更惨，seqno 还不一定能够保证有序）触发了更新操作，假设 t1 生成 binlog 的 seqno 小于 t2 生成 binlog 的 seqno，若 t1 这条消息因序号链路中的网络颤动或其它缘由造成消费晚于 t2，也就是 t2 的 binlogseq 先写入 nosql 中，那么就会造成一个 t1 的数据无法写入到 nosql 中。2.2.2 hbase 同步其实上述多表同步乱序的问题并不是肯定的，针对 hbase 这种自带列版本号的将会自

4、动处理或丢弃低版本数据，同时针对这种状况，设计成每个 table 表中的字段都会列入到 hbase 中。举个例子，针对订单的情形存入订单主表和订单商品表场景 1:1针对订单主表，我们写入的数据以订单号做 hash，然后以 hash 值： 订单号作为主键降低热点问题，同时定义单 column family，qualifiy 格式为 表： 字段 value 为对应的 value 值，timestamp 为 seqno，场景 1:n针对订单商品表，我们写入的数据同样以订单号生成相应的 rowkey，同时定义单 column family，qualifiy 格式为 表： 字段： 对应记录的 id 值

5、value 为对应的 value 值，timestamp 为 seqno，通过上述写入，能够针对详细到某个字段都有对应的 timestamp 值的更新，为后期写入更新数据能够更新到详细字段级别。2.2.3 es 同步针对上面的同步乱序问题，es 没有 hbase 这种列版本号，es 惟独 doc 级别的 version，假如上述真的浮现 seqno2seqno1, 且 seqno2 早于 seqno1 写入到 es 中，则就会浮现 seqno1 的内容无法写入，也就会造成挨次不全都的状况。那如何去解决这个多表同步问题呢？既然会乱序，那让它有序就好了，数据保证有序不就能够解决这个事情嘛，让囫囵链

6、路有序也就代表 canal 消费 binlog 数据保证有序且丢到 mq 中有序，mq 然后保证挨次投递到 sync 消费处理程序中，通过消费一条消息然后 ack 告知 mq 是否胜利，已达到保证全部数据所有有序（若多线程或多机器处理 mq 中的多个分区都是会存在问题）。如此只要保证 t1 表的数据和 t2 表中的数据在 es 不相互关联，每个数据写入的时候根据 update 方式写入（假如不存在需要做一次 create 操作）， 这样就能保证全部数据根据挨次执行。2.3 配置化同步上文已经讲到数据同步是由一个数据源（这个数据源可以来自于 mq、mysql 等）同步到另外一个数据源（mysql

7、、es、hbase、alert 等），也就是一个管道的过程。借鉴了一下 logstash 官网，同样处理流程分为 input、filter、output 组件，这些流程称之为 task 任务，通过这些组件，抽象化出每个组件都有对应的配置，由这些配置来举行初始化组件，驱动组件去执行流程。容易来说，只需要在页面中配置一些组件，无需开发任何一行代码就能实现同步任务。通过一系列的配置，就能配置出一个任务，针对业务规律，可以采纳动态语言 groovy 来采取脚本化处理（复杂业务场景可以通过 udf 函数来做支持），针对 mqinput 拿到的字段然后经过处理，经过过滤 filter 等，可以挺直拿到相关

8、的数据举行组装，然后配置化的写入到 es 中，无需开发任何一行 java 代码即可实现流程自动配置化，针对复杂的需求也能够高效率支持。配置界面2.3.1 性能瓶颈上述就能解决 es 多表同步的问题，但是同样会存在一些问题：性能瓶颈问题失败积累问题性能瓶颈：比如写入量超级大的场景状况下，而 sync 消费程序只能针对 mq 中的分区（kafka 的 partition 概念）消费，每个分区只能有一个线程去执行，消费速率与消费分区成正比，与消费 rt 成反比，尤其是大促场景下就会造成数据消费不过来，数据积累严峻问题。失败积累：由于是挨次消费，只要某个分区的某条消息消费失败，后续消息就会所有积累，造

9、成数据延迟率超高。所以建议用挨次队列的场景除非是业务量没有性能瓶颈的状况下可以实行用法，而怎么去解决挨次队列或者去掉挨次队列呢？用挨次队列无非就是保证有序，由于 es 没有 hbase 的字段级别版本号，目前订单采纳的是用 hbase 做一层中间处理层，解决该问题，通过借助 hbase 字段级别版本号协助每个表保证表内部字段有序，同时 put 写入完数据之后，通过额外字段 version 做 increment 操作，当这两个写入动作完成之后立马 get 操作拿到 hbase 的数据写入到 es 中，无论并发程度如何，终于起码有一次的 get 哀求拿到的版本 version 字段是最大的，用该

10、 version 作为 es 的外部版本号解决 es 版本号问题。用此计划会有益处：hbase 帮助管理内部字段版本，同时按照内部操作，帮助 es 拿到对应的版本，且数据能拿到最新数据；去掉了挨次队列，hbase 具有良好的吞吐，相对于挨次队列拥有更大的吞吐量；横向拓展增大消费速率；es 可以采纳 index 操作，性能更好。固然也有弊端：hbase 存在颤动的状况，以及主备切换问题。由于存在颤动或者预备切换问题，会造成数据不全都，我们该怎么去解决这个事情呢？2.4 将来扩展目前订单同步是通过加载配置文件形式来做的，也就是横向拓展的机器都会去加载同一份配置文件，各个任务通过异样解耦，理论上不会

11、有影响，但是会存在加载任务的重要度的问题。举个例子：我需要一台机器暂时去消费数据解决线上问题；有个量级很大但又不是很重要的任务，想不影响其他任务的举行；要做对照，增量延迟对照或全量对照数据，但又不希翼影响其他数据；查询日志需要全部机器查看查询（固然，公司有内部日志系统，可挺直上去查看） 如此，可以让同步系统无状态化，每个任务的配置加载有任务配置平台来举行配置，指定相关的机器做相关的处理，扩容也可以动态申请扩容，所示，可以自由分配机器处理不同的任务。三、全都性保障上文讲了有赞在处理订单的时候怎么讲数据同步到 es 或 hbase，数据来源于 binlog，写入到 mq，也就是说处理的来源来自于

12、mq。容易一句话来讲：我们不生产消息，我们是消息的搬运工。搬运工的角色可以做一些事情，同样有赞在处理数据对照也是如此，这章讲讲搬运工可以做什么：3.1 数据对照上述普通状况下不会出问题，那假如出问题了怎么办，需要做数据对照，而数据来源就是我们刚刚抛弃的挨次队列，挨次队列有个缺点就是积累，同样我们也可以利用积累的特性，让其第一条消息积累非常钟，那么后续消息基本上也会积累非常钟，然后就可以消费这个消息举行数据拉取，拿到最新的数据举行数据对照，通过对照结果发送到 alert 中，就可以知道哪些数据不全都，频率多少，这也是一种同步（mq-filter-alert）！3.2 全量对照 / 数据刷入上述我

13、们讲到数据同步到 nosql 中，但是只是讲了增量的一个过程，涉及到历史数据，就需要对历史数据举行迁移，同样，这也是一种数据同步，后面将会出相关博文怎么去做全量数据同步。四、tipstip-1：为什么采纳 es + hbase 处理搜寻和细节？普通状况下，公司达到一定规模，有类似全文检索的需求或者高频 key:value 的时候，大家会推举 es+hbase 的架构体系去完成搜寻和细节的需求，而现实中，绝大多数状况下生产环境不会将数据挺直写入到 es 或者 hbase，大家都会优先写入数据库，不举行双写的操作是由于增强链路影响业务。固然 hbase 可能还好一点，es 本身就是非实时查询系统（

14、为什么是非实时，有爱好的可以去看看 es 读写流程），这种状况下也造就了 es 和 hbase 的一个准实时系统。针对业务来说，准实时是可以满足相关需求的，比如商家搜寻订单并不要求实时。tip-2：为什么有赞选 canal 解析 binlog，而不是采纳业务消息举行数据同步？数据表被更改，比如修数据状况，业务消息不会触发，导致无法写入到对应的 nosql 中造成。数据不全都挨次性问题无法得到相关保障；业务消息并不能拿到全部相关的数据举行写入到 nosql 中。tip-3：seqno 实现方式，为什么不用 binlogoffset？由于 cana 实例与 mysql 实例是 1:n（推举 1:1）， 而大部分业务场景同一种数据普通会落在同一个实例上，canal 就可以通过该台实例的时光与每秒处理的个数相结合。如：timest