23 | 异步架构：如何避免互相依赖的系统间耦合？
李智慧
该思维导图由 AI 生成，仅供参考
上一篇文章中我们讨论过，使用缓存架构可以减少不必要的计算，快速响应用户请求。但是缓存只能改善系统的读操作性能，也就是在读取数据的时候，可以不从数据源中读取，而是通过缓存读取，以加速数据读取速度。
但是对于写操作，缓存是无能为力的。虽然缓存的写入速度也很快，但是通常情况下，我们不能把用户提交的数据直接写入缓存中，因为缓存通常被认为是一种不可靠的存储。缓存通常无法保证数据的持久性和一致性等这些数据存储的基本要求，因此数据写操作还是需要写入到 RDBMS 或者 NoSQL 数据库中，但是数据库操作通常都比较慢。
那么如何提高系统的写操作的性能呢？
此外，两个应用系统之间需要远程传递数据，常规的做法就是直接进行远程调用，用 HTTP 或者其他 RMI 方式进行远程调用。但是这种方式其实是把两个应用耦合起来了，被调用的应用产生了故障或者升级，都可能会引起调用者故障，或者也不得不升级。
这种系统间的耦合情况又该如何避免呢？
解决以上问题的主要手段就是使用消息队列的异步架构，有时候也被称为事件驱动架构。
使用消息队列实现异步架构
消息队列实现异步架构是目前互联网应用系统中一种典型的架构模式。所谓异步架构是和同步架构相对应的。同步架构是说，当应用程序调用服务的时候，当前程序需要阻塞等待服务完成，返回服务结果后才能继续向下执行。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
异步架构通过消息队列实现，是一种典型的互联网应用系统架构模式。相较于同步架构，异步架构能够改善写操作请求的响应时间，更容易进行伸缩，削峰填谷，以及隔离失败。通过消息队列实现异步架构，生产者应用程序可以快速将消息发送到消息队列后继续向下执行，无需等待耗时的消息消费处理，从而实现更高的写操作性能和更低的耦合性。此外，消息队列还能让系统更容易进行伸缩，实现针对特定功能的集群伸缩，以及在系统访问高峰和低谷时保持资源利用率。另外，消息队列还能隔离失败，即使消费者在处理消息时失败，也不会传递给生产者，提高了应用程序的可用性。异步架构通过消息队列的应用，为系统性能和可靠性提供了有效的解决方案。 消息队列实现异步架构是改善互联网应用写操作性能的重要手段，也是一种低耦合、易扩展的分布式应用架构模式。但是使用这种架构有些方面也需要注意。比如，消费者程序可能没有完成用户请求的操作，这就需要更复杂的用户交互和处理方法。在选择消息队列产品时，需要考虑各产品的优缺点，以及适用场景，以确保选择最适合的产品。 异步架构中最主要的技术就是消息队列，目前主要的消息队列产品有哪些？各有什么优缺点？欢迎你在评论区说说你对消息队列产品的了解，我会和你一起交流，也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《后端技术面试 38 讲》，新⼈⾸单¥59
《后端技术面试 38 讲》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(13)
- 最新
- 精选
_funyoo_消息队列我接触过的有rabbitMQ，kafka和RocketMQ 在消息模型方面 Kafka和rocketMQ是一致的，可以称作发布订阅模型 而rabbit更多是依赖于exchage的策略，多个消费者有多个队列对应 而对于kafka和rocketMQ而说，在实现事务方面 kafka: “攒一波，一起发送”，他比较关注，这一波数据我有没有发成功，没有反查机制。分布式事务依赖服务端事务协调者。 rocketMQ：关注本地事务和发消息两个操作是事务的，有反查机制。分布式事务依赖于半消息机制。2020-01-2128
escray
在第一个发送邮件的例子那里，是不是少了一张不使用消息队列的图？另外还有一个 typo：”ClintCode”。 消息队列的主要使用场景：异步处理（秒杀）、流量控制（削峰填谷）、服务解耦（主题订阅）。 听说过，但是没有使用过的消息队列有：Kafka、ActiveMQ、RabbitMQ、RocketMQ、Pulsar……其实不难发现，我基本上没有在生产环境用过消息队列。 * RabbitMQ 是“开箱即用”的消息队列，轻量级，部署、使用和维护都比较容易； * 如果应用场景是处理在线业务，比如在交易系统中用消息队列传递订单，在意响应时延，那么选择 RocketMQ，每秒大概能处理几十万条消息，性能比 RabbitMQ 搞一个数量级； * Kafka 与周边生态兼容性最好，异步收发性能较好，但是不太适合在线业务，适合处理海量消息，比如收集日志、监控信息或者前端埋点数据，或者是和大数据、流计算相关 消息队列的缺点： * 引入消息队列带来延迟 * 增加了系统复杂度 * 可能产生数据不一致 以上内容来自隔壁的《消息队列高手课》，我觉的留言中的所有问题似乎都可以去隔壁找答案。2020-10-075- 奔奔奔跑智慧老师好，我是go开发，我说说go的吧，有有赞封装的NSQ，优点是轻量，性能高，消息不丢失。缺点消息无顺序，2020-01-184
- Paul Shan异步架构是解耦请求和执行，传统cs架构，客户端发起请求，服务端接受请求，客户端等待服务端完成，服务端返回结果。这和我们去银行办业务有点像，我们去银行，然后在大堂等待，等到了，把业务办好，例如转账。异步模式就像我们给银行的服务人员打电话，把我们的需求告诉对方，然后该干啥干啥，银行会安排资源，在空闲的时候，把我们的转账业务完成，然后通知我们。我们作为客户免去了等待时间，银行可以统筹安排资源，不用那么多面对客户的柜员了，这里付出的代价是需要有一个系统去管理这些请求，也就是消息队列系统，来管理优先级，平衡负载，来对消息进行分类和分发等。另一方面，我个人感觉异步编程模式学习曲线较为陡峭，出错也较难排查，这就对架构和编码提出更高的要求。2020-02-2512
不要挑战自己的智商订阅者模式只中：假设某消息被五个订阅者拿去执行，四个执行完成，一个执行异常，此时怎么办？该消息应该已经在队列中被删除了。另外，五个订阅者处理同一消息的速度也是不同步的。。。处理异常代码应该放哪呢？如果不同订阅者之间无法完全解藕，有新增订阅者的话，很可能还是要需改原来的代码。 感觉没有落到代码层面，还是很抽象的。。。2020-07-3121- yieyu采用消息队列后，部分业务逻辑被分拆到消费者，那么如何管理这一大堆消费者（逻辑关联，代码，部署）也是个问题2020-07-151
lakeslove李老师，文中只提及了消息队列的好处，坏处一笔掠过。希望能详细说一下消息队列的坏处，哪些场景不适合消息队列。现在的瓶颈感觉是：某个技术的优缺点以及适用场景只是大体了解，但不能够明确把握。2020-02-1131
test主要的消息队列：kafka、rocketmq、rabbitmq。 rocketmq可以有事务和反查机制。 kafka吞吐量高。2022-11-06归属地：广东
java小霸王kafka 大数据组件常客，优点 生态成熟，社区活跃，缺点业务定制功能不足 阿里的mq 业务功能较多 缺点。。。2022-07-01
文武木子
redis也可以作为轻量级的消息队列，也是发布订阅模型2021-12-02
收起评论
