基于Bifrost的数据同步方案
技术选型
项目组决定找一个开源中间件，它需要满足以下5点要求。
1）支持实时同步。
2）支持增量同步。
3）不用写业务逻辑。
4）支持MySQL之间的同步。
5）活跃度高。
根据这些要求，可以选用以下几个开源中间件：Canal、Debezium、DataX、Databus、Flinkx、Bifrost。
这些中间件的对比结果见表14-1。
从以上对比来看，比较贴近场景需求的是Bifrost。
其实Bifrost是一个相对比较年轻的中间件，而且它不支持集群。那为什么使用它呢？原因如下。
1）它的界面管理比较方便。
2）它的架构比较简单，出现问题后，可以自己调查问题，相对比较可控。之后即使作者不维护，团队也可以自己维护起来。
3）作者更新很活跃。
4）自带监控报警功能。
项目组最终决定使用Bifrost，此时整个方案的架构如图14-4所示。
• 图14-4 基于Bifrost的数据同步方案架构
Bifrost架构
在使用这个技术之前，还是要了解一下它的基本原理。Bifrost架构图如图14-5所示。
• 图14-5 Bifrost架构图
可以看出，Bifrost其实也是模拟成MySQL的从库，监听源数据库的Binlog，然后再同步到目标数据库。它支持多种目标数据库，本项目是从MySQL同步到MySQL。
注意事项
使用数据同步这个方案时，应该注意什么？
1.数据同步的延时
这个数据同步方案是有一定延时的，所以如果业务对同步功能有高时效的要求，那么尽量不要使用这个方案。
举个例子，这里虽然同步了商品的数据到订单数据库，但是订单服务当中，如果提交订单需要检查库存的话，不建议把库存数据同步到订单数据库里，而是让订单服务每次都去请求商品数据库的库存。
所以，其实同步过来的数据基本上只是用来展示、查询的，不涉及业务数据变更。
2.同步过来的数据是只读的
因为这里的数据同步是单向的，所以目标数据库中同步过来的数据是不能修改的。在这个方案里，肯定不会去修改订单数据库里面同步过来的商品数
据。也有一些其他场景，比如同步一些基础配置或者公用数据到各个数据库，而后在使用这些同步数据时，可能会发现一些遗漏，比如城市/区/县数据，这种情况下，也不能直接在业务数据库里修改，而是应该通知提供数据的系统去修改，之后再同步过来。
3.监控一定要到位
Bifrost不是高可用的，它本身也提供了一些告警的功能。除了依赖它本身的告警功能以外，还要额外监控Bifrost这个服务的状态，确保它出现异常时能及时发现。Bifrost本身也提供了API接口，用来让第三方的监控对接。
4.核心逻辑不建议依赖同步数据
因为同步过来的数据是有延时的，并且Bifrost本身没有设计高可用，所以并不推荐在核心逻辑上使用同步的数据。
小结
系统上线后，商品数据的同步比较稳定。之后，商品服务的开发人员只需要关注自己的逻辑，无须关注使用数据的人。如果需要关联使用商品数据的采购单，采购服务的开发人员也不需要关注商品数据的同步问题，只需要在查询时加上关联语句即可，算是一个双赢的结局。
唯一遗憾的是Bifrost不是集群，无法应对高可用场景。不过，到目前为止，这个系统还没有出现宕机的情况，反而是那些部署多台节点负载均衡的后台服务常常出现这种情况。
Bifrost 的 作 者 也 介 绍 了 他 为 什 么 没 有 设 计 集 群（
https://wiki.xbifrost.com/other/clusterwhynot/），部分引用如下。
在实际工作中，项目组很大一部分时间其实都是在处理线上高可用、分布式遇到的各种问题。
工作经验告诉我们，很多开源系统的高可用可能并不是我们想象中的那样高可用，尤其是那些对数据一致性有要求的场景，会存在很多问题。
在实际工作中，绝大多数一开始就使用各种分布式、高可用设计的项目，最后都失败了。
功能很多，又使用分布式和高可用，很难排查问题。
Bifrost是一个面向生产环境的产品，对生产环境抱有敬畏之心。
Bifrost并不想在一个项目刚开始的时候，就进行各种分布式、高可用等设计。
这些描述不一定准确，但是笔者的确碰到过两次“高可用最终并不是真正的高可用”的情况，所以那时候就想在系统当中引入一个非高可用的中间件进行尝试。当然，为了保证系统出错以后能够及时解决，也做了很多定制的监控。
事实证明，高可用不一定真的高可用，单机也未必不能高可用。当然，也不能以偏概全地说高可用设计没有必要，那就因噎废食了，这种状况毕竟只是特例。而且，项目组也随时准备着改造这个中间件，增加灾备能力。不管怎么样，项目组最终解决了服务之间数据依赖的问题。接下来，就要直接面对服务之间逻辑或流程上依赖的问题了。
