数据同步

1. 应用场景

• 业务数据发展到一定水平，需要将大部分冷热数据从熟悉的DB迁移到其他存储进行复杂查询和分析
• 分库分表后，某些报表类查询无法工作，需要汇总到单库表进行操作
• 分库分表有多个维度，需要拷贝多份数据达成冗余
• 通过伪数据共享（没办法引入MQ、无法共享库表）进行业务改造
• 慢存储–>Cache之间的同步
• 不停服数据迁移/scheme变更
• 导数据导数据

很多时候，DataBus提供的仅仅是一个工具集。要完成最终的功能，大多数需要引入其他组件，如MQ、JOB等进行配合。同时，大部分数据同步工具需要有规范的数据库支持。所以，在忙着进行数据同步之前，需要对遗留数据进行一次集中数据治理。

一般数据同步，可以应用驱动双写：应用层同时向数据库或者多个存储写数据。因为代码在自己手中，这种方式在直觉上是简单可控的。但它引入的一致性问题将会是非常大的减分，因为没有复杂的协调协议（比如两阶段提交协议或者paxos算法），当出现问题时，很难保证多个存储处于相同的锁定状态。两个系统需要精确完成同样的写操作，并以同样的顺序完成序列化。如果写操作是有条件的或是有部分更新的语义，那么事情就会变得更麻烦。

基于数据库日志：将数据库作为唯一真实数据来源，并将变更从事务或提交日志中提取出来。这可以解决一致性问题，但是很难实现，MySQL这样的数据库有私有的交易日志格式和复制冗余解决方案，难以保证版本升级之后的可用性。由于要解决的是处理应用代码发起的数据变更&