【后端面经】【消息队列】22 | 消息队列:消息队列可以用来解决什么问题?-03 扩展性+可用性+事件驱动思想

简介: 【5月更文挑战第8天】本文探讨了扩展性、可用性和事件驱动的概念。扩展性方面,消息队列简化了新下游的接入,而同步调用需要复杂的协调。在保证高可扩展性和研发效率的设计中,若无法使用消息队列,可以提供一致性抽象来减轻接入负担。可用性上,消息队列只需确保消息发送,而同步调用需保证所有下游成功,更易出错。事件驱动是一种通过事件进行组件间通信的架构模式,具有低耦合、高扩展性和高可用性,适合处理复杂流程。结合SAGA的事件驱动方案能实现高级分布式事务管理,即使实时性稍弱,但能保证事务的异步和高效执行。

扩展性

扩展性就是:如果一个新的下游要接入进来有多难?在使用消息队列的时候,新的下游要接入,只需要自己去订阅消息就可以,完全不需要通知任何人。

2024-05-09-20-05-23-image.png

但是如果是同步调用,事情就麻烦很多,你需要下游提供RPC服务地址(定位信息),根据下游的API设计构造请求、处理响应,再一起联调、测试、上线。

在使用消息队列的情况下,消息发送者完全不关心谁会去消费这些消息。同样地,如果有一个新的业务方要订阅这个消息,它可以自主完成。而同步调用的时候,上游必须知道下游的接口,然后要知道如何构造请求、如何解析响应,还要联调、测试、上线,整个过程都得和下游密切合作,因此效率特别低,可扩展性很差。

但是这里你可以刷一个亮点,就是在类似的场景下,如果因为一些业务情况确实不能使用消息队列,那么可以考虑提供一个一致性的抽象来减轻这种接入的负担

如果在某些场景下确实不能用消息队列,那么这个扩展性问题可以通过一些技术手段来缓解。比如说上游提供一整套的对接规范,包括 API 定义、请求和响应中每个字段的含义。这样下游就对着这个 API 定义来提供实现,上游就不需要适配每一个下游了。

然后你进一步总结。

这是对接众多下游的基本设计,可以充分保障高可扩展性和高研发效率。

可用性

在使用消息队列的方案里,你只需要确保自己把消息发送到了消息队列里,就认为操作已经成功了。

在同步调用方案里,必须要确保所有的下游都成功了才算成功,还需要额外考虑部分成功部分失败的问题。对比而言,同步调用方案更容易出错,容错也更难。

事件驱动

事件驱动是一种软件开发模式,也可以看作一种架构,核心思想是通过把系统看作一系列事件的处理过程,来实现对系统的优化和重构。

可以直观地理解为,整个系统不同组件之间的通信是通过事件完成的。也就是组件1发送一个事件到消息队列上,然后组件2消费这个消息。组件2消费完成后再发出一个消息到消息队列。每一个事件就是一个消息。

这些消息可能有不同的Topic,也可能发送到不同的消息队列集群。但是毫无疑问他们需要通过紧密合作来解决一个问题。

它的优点十分明显:

  • 低耦合性: 各个组件只依赖消息队列,组件之间通过消息的定义间接地耦合在一起。组件只需要知道消息的定义,并不需要知道发送消息的组件是哪个。

  • 可扩展性: 事件驱动的应用程序有很强的扩展性,可以通过添加新的事件处理程序、组件等来实现系统的扩展和升级

  • 高可用: 可以充分利用消息队列的可靠性、可重复消费等特性,来保证消息发送、消费高可用,从而保证整个系统的高可用。

事件驱动适合用来解决一些复杂、步骤繁多、流程冗长的业务问题。在下面的亮点方案里面,我用的就是事件驱动结合 SAGA 分布式事务的方案。这个方案足够高级、冷僻、奇异。它原本用在一个大规模的分布式系统里面,是一个高性能和高可用的分布式事务解决方案。你可以看一下事件驱动和 SAGA 结合之后的形态。

2024-05-09-20-19-11-image.png

也就是说,当某一个步骤完成之后,就会发出一个或者多个事件,驱动事务中的后续步骤。包括回滚也是这样,比如说发出一个代表某一个步骤执行失败的事件,对应的消费者就会去执行反向补偿步骤。
2024-05-09-20-19-24-image.png

使用事件驱动的优点是低耦合、高扩展性、异步、高可用。不过在实时性上要比同步调用差一点。我用一个最简单的例子给你解释清楚它的运作。比如说你有一个分布式事务,就是要求先更新 DB,再更新缓存。那么在缓存更新失败的场景下,过程看起来就像图里展示的这样。
2024-05-09-20-19-49-image.png

可以考虑这样介绍这个方案。

之前我们公司用事件驱动实现了 SAGA 的分布式事务解决方案。基于事件驱动的 SAGA 模式就是在每一个步骤结束之后发送事件,不同的步骤会发送一个或者多个事件。然后消费者消费了消息之后,就开始执行下一个步骤。比如说在更新 DB 再更新缓存的场景里就可以这样用。这种形态和一般的事务比起来,优势是低耦合、高扩展、高可用。

目录
相关文章
|
6月前
|
消息中间件 Dubbo Java
Spring全家桶 、Dubbo、分布式、消息队列后端必备全套开源项目
基于 Spring Boot 2.X 版本的深度入门教程。 市面上的 Spring Boot 基础入门文章很多,但是深度入门文章却很少。对于很多开发者来说,入门即是其对某个技术栈的最终理解,一方面是开发者“比较懒”,另一方面是文章作者把 Spring Boot 入门写的太浅,又或者不够全面。
|
5月前
|
NoSQL 消息中间件 数据库
|
5月前
|
消息中间件 Java Spring
JavaWeb后端开发Spring框架之消息 消息队列案例--订单短信通知
JavaWeb后端开发Spring框架之消息 消息队列案例--订单短信通知
50 0
|
6月前
|
消息中间件 Kafka 数据库
【后端面经】【消息队列】22 | 消息队列:消息队列可以用来解决什么问题?-02 超时场景+性能问题
【5月更文挑战第7天】 本文介绍了电商中订单超时取消的处理方法,通过使用消息队列实现延时消息。当订单30分钟后未支付,消息队列将触发取消操作,但需注意并发问题,如采用分布式锁或乐观锁避免并发更新订单状态。乐观锁确保只有订单状态为未支付时才允许支付。主流消息队列如RocketMQ支持延迟消息,而Kafka不支持。 使用消息队列的好处在于解耦和提高系统性能、扩展性和可用性。同步调用会导致性能下降,因为必须等待所有调用完成。并发调用虽可提升性能,但仍逊于消息队列,且无法解决扩展性和可用性问题。
118 1
|
6月前
|
消息中间件 NoSQL Redis
【后端面经】【消息队列】22 | 消息队列:消息队列可以用来解决什么问题?-01
【5月更文挑战第6天】消息队列的核心特性是异步、削峰和解耦,常用于日志处理和消息通讯,实现事件驱动架构。面试中可能涉及问题包括公司是否使用消息队列、应用场景、优缺点以及延时队列、秒杀架构等。秒杀场景下,消息队列将校验和库存扣减(轻量级)与订单创建(重量级)分隔,减轻系统压力,依赖于Redis性能。使用消息队列能解决高并发、复杂流程同步等问题。
102 0
|
消息中间件 微服务
微服务通信:RPC、消息队列和事件驱动架构的比较
在微服务架构中,微服务之间的通信是至关重要的。为了实现松耦合、高效可靠的通信,开发人员可以选择不同的通信方式,包括RPC(远程过程调用)、消息队列和事件驱动架构。本文将对这三种常见的微服务通信方式进行比较,探讨它们的特点、适用场景和优缺点,帮助开发人员选择合适的通信方式。
339 0
|
消息中间件 存储 安全
2021-Java后端工程师面试指南-(消息队列)(下)
前言 文本已收录至我的GitHub仓库,欢迎Star:github.com/bin39232820… 种一棵树最好的时间是十年前,其次是现在
157 0
|
消息中间件 NoSQL 算法
2021-Java后端工程师面试指南-(消息队列)(上)
前言 文本已收录至我的GitHub仓库,欢迎Star:github.com/bin39232820… 种一棵树最好的时间是十年前,其次是现在
173 0
|
4月前
|
消息中间件 C语言 RocketMQ
消息队列 MQ操作报错合集之出现"Connection reset by peer"的错误,该如何处理
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
4月前
|
消息中间件 Java C语言
消息队列 MQ使用问题之在使用C++客户端和GBase的ESQL进行编译时出现core dump,该怎么办
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
下一篇
无影云桌面