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