这是一个创建于 1488 天前的主题，其中的信息可能已经有所发展或是发生改变。
我看了
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 学习下。
 |
1
billlee 2020-03-29 21:12:33 +08:00
你是不是理解得有点问题，这三篇文章都没有说用 mysql 主从复制来实现最终一致性吧？数据库当然是每个微服务各自分开的
|
 |
2
inter18099 OP @billlee
https://medium.com/@john_freeman/querying-data-across-microservices-8d7a4667668a 里面 Selective data replication 这个说的就是主从复制吧？ |
|
3
billlee 2020-03-29 21:31:52 +08:00
@inter18099 #2 刚才没仔细看，以为说的是通用意义上的数据复制。基于数据库的，实际应用场景主要在统计、分析类的业务上吧，主库做 OLTP, 从库做 OLAP.你假设的这个场景似乎确实不适合用 replication 方案。
|
 |
4
xuanbg 2020-03-30 09:23:40 +08:00
微服务的数据一致性，最通行也最简单的做法是用消息队列来实现最终一致性。也就是说，你把数据丢队列里面就算是完了，剩下的就是消费者如何保证完成任务的事了，生产者无需关心。消费者一方基本上也就是搞两个队列，一个正常队列，一个延时重试队列。正常消费失败的死信丢到延时队列以避免消息丢失就可以了。
系统越复杂，可用性就越差。 |
Select Language