14-数据同步-同步方案分析

14-数据同步-同步方案分析

1.数据同步问题分析

elasticsearch中的酒店数据来自于mysql数据库，因此mysql数据发生改变时，elasticsearch也必须跟着改变，这个就是elasticsearch与mysql之间的数据同步。

在微服务中，负责酒店管理（操作mysql ）的业务与负责酒店搜索（操作elasticsearch ）的业务可能在两个不同的微服务上，数据同步该如何实现呢？

2.数据同步问题分析

方案一：同步调用

假设现在有两个微服务，一个叫hotel-admin酒店管理服务，一个叫hotel-demo酒店搜索服务。我们假设这两个服务之间互相不能访问对方的数据库，酒店管理服务只能访问Mysql，酒店搜索服务只能访问ES，这也符合微服务里面的标准和规范。现在问题来了：我在酒店管理服务里面完成了数据的新增，ES怎么去同步？这种做法是这样的：当有人做新增删除或者修改的业务的时候，我首先要去把数据写到数据库里，以前的话就结束了。但是现在还要去更新ES。又没办法直接调，那我就回去调用hotel-demo当中的更新索引库的一个接口，你没办法更新es，你调用我的接口，我自己去更新就行了。所以在在原来的过程中，就从一步变成了三部，先写数据库，然后调hotel-demo，然后hotel-demo更新es，而且这三个步骤是依次执行的，也就是写完数据库了才能去调这个接口，而调接口了以后才能去调es的api实现更新，而更新完成结果才能返回到hotel-demo，houtel-demo处理完才会返回给hotel-admin，admin才会返回给用户。这种方式依次执行，所以叫做同步调用。

同步调用有什么问题呢？

1.数据耦合，业务耦合：原来只是写数据库，写完就结束了。现在你在写数据库的后面还加了一个调用hotel-demo的代码，业务逻辑发生了修改。并且调用hotel-demo这个接口的业务跟这个新增业务没有关系，现在硬把这两个代码耦合在一起了，这不就业务耦合了吗？业务耦合必然影响性能，为什么？你原来写完数据库结束了，耗时50ms，现在你写完数据库还得等待hotel-demo这个接口的响应，而他又要去调用es这块的响应，总耗时是这三个耗时相加，达到100多ms。性能自然就下降了。并且如果步骤二和步骤三任意一个位置发生了异常，整个业务也就出问题了。这就是耦合带来的问题。

方案二：异步通知

基于之前学习的mq的知识来实现。当有人来做新增时，我先去写数据库，写完以后我不去调用任何人的接口，而是发一条消息，通知一下别人说我这里数据新增了，至于是谁来监听这个消息，监听了以后做什么，什么时候做，和我没有关系。这样业务的耦合就解除了。并且你这里更新耗时多少s和我这边没影响。我写完数据库发完消息就结束了。性能就得到了提升。解决了前面的同步调用问题。

方案三：监听binlog

mysql里面binlog默认是关闭的，但是一旦开启了binlog，每当mysql里在做增删改操作时，都会将相应的操作记录在binlog中，也就是说，只要是数据变化了，binlog就会变化，而我们可以利用类似于canal这样的中间件去监听binlog。一旦发现binlog发生变化，立马通知对应的微服务，这个微服务就知道数据发生变化了，就可以去更新es了。但是这种方式要开启mysql的binlog，对于mysql来说压力就增加了，并且还要引入新的中间件canal，实现起来比较复杂。

3.总结：

方式一：同步调用

​ 优点：实现简单，粗暴

​ 缺点：业务耦合度高

方式二：异步通知

​ 优点：低耦合，实现难度一般

​ 缺点：依赖mq的可靠性

方式三：监听binlog

​ 优点：完全解除服务间耦合

依赖mq的可靠性

方式三：监听binlog

​ 优点：完全解除服务间耦合

​ 缺点：开启binlog增加数据库负担、实现复杂度高