Overview
关系型数据库，以OLTP（Online Transaction Process）形式在存储和实体逻辑关联领域带来的价值毋庸置疑，然而在搜索，缓存，数据分析等场景却并不见长。
关系型数据库作为企业重要的数据源，为了丰富数据的应用场景，由此产生了数据同步的需求。
下文以搜索场景的数据同步为例说明
Solutions
1、同步双写
以搜索系统建设的场景为例，业务侧应用中触发的dml事件，同时应用于rdb和Search，将dml的事件上下文以同步的形式分发到需要扩展的目标数据源，以满足Search的数据要求。
问题：
1）能力复用：数据同步的能力复用性不够。
2）耦合性：业务的侵入性较大，开发阶段和运行时，对应用侧都有额外的开销。
3）一致性：双写成功率的保证，需要额外的工作去实现。
2、批量更新
通过可调度的批量任务，拉取并加工数据，推送到指定的异构系统(Search)，
以满足对数据需要。
问题：
1）同步时延：同步延时受scheduled job的周期影响，需要根据场景定制。
2）耦合：同步任务的开发质量影响rdb的资源。
3）可复用的能力不够，不同场景需要多次介入；比如：同步的目标数据源是Cache、Queue、Hive。
Syner
我们的方案，整体采用事件驱动模式，设计如下：
binlog-parser：通过同步binlog-parser（databus，canal）模拟rdb从库解析binlog，实时感知dml操作的变化，将rdb的binlog当成是事件源，解决同步延时的问题。
Queue：事件驱动模式中，很重要的一部分是事件存储，我们通过MQ来做的实现。存储基于数据库表的维度来做Queue的切分，以保证表级别的事件顺序。
Syner：核心能力是将具体的事件映射到N个目标异构系统（Search，Cache…）。简单的逻辑映射如下，左侧表示事件的来源，其本质是rdb表的行的变更（binlog基于row模式解析），右侧表示目标系统（异构系统的数据建模考虑，留待其他文章讨论）。
Syner的工作过程：
1）获取存储层的事件信息
2）过滤异构系统不关注的事件信息
3）基于事件的数据模型，转换事件的数据模型（普遍情况下与目标异构系统数据模型存在差异，源事件需要一个转换的过程）以满足异构系统的模型要求
4）基于转换后的数据，下沉到异构系统
Syner的行为抽象：
1）连接存储层获取事件
2）事件分发到应用场景，并依据“规则”转换
3）下沉数据到异构系统
规则引擎模式是流程自动化
基于抽象，在步骤相对确定的情况下，通过规则引擎模式来表达整个过程，可以使得整体流程趋于自动化，达到降低开发和接入成本的目标。
确定以规则引擎的建设思路后，工作内容分为了以下两个大的部分：
定义规则
1）subscribe：表示当前规则“感兴趣”的事件源范围，细化到field级别
2）mapping：包含两个部分：
a.事件源与目标异构系统之间的数据模型映射；
b.事件的数据模型，普遍情况下与目标异构系统数据模型存在差异，需要有一个转换的过程，这个过程通过业务侧提供的api来实现；api的设计目标有两个：其一、将数据转换的过程从Syner脱离出来，业务侧自由定制，提高灵活性；其二、api的去向也是一种默认的sink方向（此处结合下文提到的“命令模式”理解）
3）sinker：表示需要数据需要被分发的目标异构系统。
实现引擎
相对上一步来说，解析规则是引擎的一个部分工作内容，另外还需考虑：
1）规则本身的生命周期的管理
2）可用性：错误隔离，资源分配（比如：线程数量，队列大小，网络IO timeout 等等）
3）吞吐量：数据一致性问题对吞吐量的影响
4）API动态集成：对转换API的动态集成与管理
5）同步过程管理：全量、增量、修复、校验...
6）监控、告警
整体架构如下
admin：负责规则生命周期的管理，同步过程的管理（未来可包括引擎本身的动态调优）
api-srv：负责提供指定的api接口实现，并注册到服务发现集群
如何保证数据一致性？
1）binlog本身的记录方式基于时间的全局序列事件；
2）Queue，存储以表维度的拆分binlog的全局序列，保证局部有序即可；用table hash mode 可能存在Queue数据量倾斜问题，未来可通过一致性hash等的思路来解决数据平衡的问题；
3）Syner作为事件驱动模型的dispatcher部分，为了提高吞吐量，使用的是异步多线程模型，未解决数据的不一致问题，引入趋势递增的序列号（原理借鉴snowflake）。趋势递增序列号为什么能解决这个问题？binlog本质上还是数据的snapshot，而且在到达Queue之前是严格的时间顺序，比如某一行数据x=a，第一次update之后 x=b，第二次update之后x=c，第一次update事件标记序列号为1，第二次标记为2（趋势递增必定>=2）,从数据的最终一致性来理解，编号2的事件才是数据的最终版本。因此事件在最终消费时，只消费编号>=上一次的事件即可解决多线程消费下的数据一致问题。基于这个思路，还可以优化事件容量，原理类似Redis的AOF重写，一段时间内多个事件可以聚合为一个最终事件。
针对高可用的工作内容
1）binlog-parser的集群多节点主备，主备节点自动切换；
2）Syner集群在规则引擎之间的相互隔离；
3）enrich api的异步使用（结合Queue）
4）enrich api的response的使用命令模式（SAVE、UPDATE、DELETE、NONE、ASYNC）编排sink行为
5）同步过程中各环节数据的修复能力（自动和手动形式结合）
命令模式
这是一个整体的tradeoff，Syner可在不关注invoke的结果的情况下，将目标数据源的操作行为全部交由api-srv自行处理，如下图的一种实现方案（实际并未采用）
tradeoff
1）成本：中等规模团队首要发展，仍以业务迭代为主，且对于异构数据源API学习成本偏高，投入产出相对不高
2）质量：API的实现质量因人而异
3）安全：目标异构源的安全性（对一个中小型团队来说仍然需要不少工作内容）。
命令模式（指令）的划分
Syner统一实现对于目标异构源的操作（写操作无外乎增、删、改），invoke api的返回结构中包含两个部分：1）转换后的数据内容；2）将数据内容应用于目标数据源的操作指令。
SAVE、UPDTE、DELETE 理解为针对写的常规操作；
NONE：表示当前事件，无需执行任何后续的操作；
ASYNC：表示异步模式，收到当前请求后立即结束后续流程；
NONE与ASYNC的区别在于：NONE表示不存在任何后续的操作行为，ASYNC表示收到当下的请求返回，即可结束，但是会存在异步线程处理数据结果。
最终效果
通过管理端（admin）对规则的定义，Syner自动感知规则生命周期变化，并动态管理规则引擎无需重启。通过已经注册好的enriche api实现数据模型的转换。同时在admin中管理同步过程。
对于用户来说，整体过程的感知只有以下两个步骤：
1）开发enriche api
2）可视化的规则配置