微服务架构下的事件驱动的主从复制具体应该如何做？

[inter18099]

我看了

https://microservices.io/patterns/data/event-driven-architecture.html

https://medium.com/trendyol-tech/event-driven-microservice-architecture-91f80ceaa21e

https://medium.com/@john_freeman/querying-data-across-microservices-8d7a4667668a

等等，

搜索了 how to do data replication in mysql microservices，microservice data replication which is master which is slave 。

等等

=====================================================================

只看出来事件驱动能解决不同服务的耦合问题，能实现松耦合，然后事件驱动的数据最终一致性问题可以由主从复制来实现。我以前不知道什么是主从复制，我搜了下，发现就是一个 master 库一个 slave 库，配好了，自从从 master 库同步到 slave 库。

现在问题来了，假如我有 4 个微服务，1 个 order，1 个 product，1 个 shipment，1 个 pay，那么假如，order 微服务需要 product 微服务的数据库数据，那么我就在 order 微服务下创建一个 product 微服务数据库的 slave 库？这会不会太重了？

我是菜鸟，新入坑，希望有些实践经验的高手回复我下，我来 v2 学习下。

[billlee]

你是不是理解得有点问题，这三篇文章都没有说用 mysql 主从复制来实现最终一致性吧？数据库当然是每个微服务各自分开的

[inter18099]

@billlee
https://medium.com/@john_freeman/querying-data-across-microservices-8d7a4667668a
里面 Selective data replication 这个说的就是主从复制吧？

[billlee]

@inter18099 #2 刚才没仔细看，以为说的是通用意义上的数据复制。基于数据库的，实际应用场景主要在统计、分析类的业务上吧，主库做 OLTP, 从库做 OLAP.你假设的这个场景似乎确实不适合用 replication 方案。

[xuanbg]

微服务的数据一致性，最通行也最简单的做法是用消息队列来实现最终一致性。也就是说，你把数据丢队列里面就算是完了，剩下的就是消费者如何保证完成任务的事了，生产者无需关心。消费者一方基本上也就是搞两个队列，一个正常队列，一个延时重试队列。正常消费失败的死信丢到延时队列以避免消息丢失就可以了。

系统越复杂，可用性就越差。