技术选型
项目组决定找一个开源中间件,它需要满足以下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架构图如图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并不想在一个项目刚开始的时候,就进行各种分布式、高可用等设计。
这些描述不一定准确,但是笔者的确碰到过两次“高可用最终并不是真正的高可用”的情况,所以那时候就想在系统当中引入一个非高可用的中间件进行尝试。当然,为了保证系统出错以后能够及时解决,也做了很多定制的监控。
事实证明,高可用不一定真的高可用,单机也未必不能高可用。当然,也不能以偏概全地说高可用设计没有必要,那就因噎废食了,这种状况毕竟只是特例。而且,项目组也随时准备着改造这个中间件,增加灾备能力。不管怎么样,项目组最终解决了服务之间数据依赖的问题。接下来,就要直接面对服务之间逻辑或流程上依赖的问题了。
资源获取:
大家 点赞、收藏、关注、评论啦 、 查看 微信公众号获取联系方式
精彩专栏推荐订阅:在 下方专栏
每天学四小时:Java+Spring+JVM+分布式高并发,架构师指日可待