13 | 技术选型：如何根据应用场景选择合适的消息中间件？
消息中间件的应用场景
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
选择合适的消息中间件对于应用场景至关重要。本文通过电商平台用户注册送积分、送优惠券的场景，以及外卖骑手送餐的案例，深入探讨了消息中间件在异步解耦和削峰填谷方面的重要性。文章还对RocketMQ、Kafka和RabbitMQ等主要消息中间件进行了功能和性能方面的对比分析，强调了在选型时需要综合考虑功能特性、性能和扩展性，以及团队技术栈与中间件编程语言的匹配度。此外，文章提出了在实际选型时的建议，如根据团队的技术栈选择合适的消息中间件。总的来说，本文通过实际案例和技术对比，为读者提供了在选择和应用消息中间件时的参考指南。
《中间件核心技术与实战》，新⼈⾸单¥59
全部留言(7)
- 最新
- 精选
浅qian的痕迹带来的问题和解决办法： 1. 系统可用性会降低 比如：MQ挂掉了 解决方案：MQ集群部署，提高可用性 2、系统复杂性提高 加入MQ，需要考虑消息重复消费、保证消息不丢失、保证消息有序等问题 数据丢失解决方案： 生产端丢失：设置MQ给生产者合理的ACK方式 MQ服务端的数据丢失：比如同步刷盘，牺牲部分性能 消费端数据丢失：同步消费，不在多线程里面消费 3、一致性问题 下游服务消费消息异常，可能导致上下游服务里的数据不一致 解决办法： 可以重复消费，错误报警，对账或者手动修复作者回复: 你好，思考的非常全面，我尝试对你的这些思考，做一个补充说明： 1、引入了MQ,整个系统就多增加了一项外部依赖，出现问题的几率确实会增大，通常的解决方案确实如你所说，MQ需要使用集群部署。 2、第二点，这里我觉得你思考的比较全面，但措施可能有些悲观，我在这里谈谈我的一些观点： 1）消息发送端，设置合理的ack，这个是正确的，通常采取的措施一般类似两阶段提交思想，通过引入半消息，本地消息表来实现消息发送的分布式最终一致性，这块内容在第22讲有重点提及。 2）MQ服务端数据丢失，采取同步刷盘，这样会降低性能，资源的利用率会升高，通常我们会进行权衡，一般而言，只要数据容易恢复，容易进行补偿，通常还是可以使用异步刷盘。关于消费端消息丢失，消息中间件基本都是采取最小位点提交机制(ack)，可以确保在消费端不会丢消息，最多就是会重复消费。 3、一致性问题，通常会使用类似分布式事务机制，例如本地消息表等手段，这块在第22讲有专门介绍，当然对账或手动修复，也是需要的。
2022-07-20归属地：上海8
fireshort“如果公司或团队的技术栈以 Golang 为主，建议选择 RabbitMQ”？这里搞错了，RabbitMQ用的是Erlang。作者回复: 对的，笔误，谢谢指正，已修改。
2022-11-15归属地：广东1
Y a n g带来的问题 数据一致性问题，如果用户注册和发mq消息都在账号中心同一方法内处理，那么很难保证数据的一致性。举例 用户注册写库时未提交数据库事务失败，此时mq消息已发出，再或者下游消费异常，导致数据不一致 解决方法：做分布式事务作者回复: 嗯，对的，如何来做分布式事务，我在我们专栏的第22讲专门介绍了，建议关注一下，多多交流。
2022-07-28归属地：上海1
雨落～紫竹第一 kafka 被称为分布式实时流计算平台 他比其他mq 应该很适合处理这种低延迟的场景 第二 kafka说 丢消息不是它的问题 这锅它不背 第三 确保端到端的稳定和消费 确保不会因为服务导致重启（对于强需求而言 消费端必须手动ack ）第四 随着系统增多 复杂性增高 有必要增加链路追踪服务 将每一步的消息或者重要逻辑处理结果放到追踪服务 方便排查问题2022-07-183- 雨落～紫竹还有 老师 你上面那个流程图 我实在想不出来 为什么 开始就做成异步了 结果又出来两个rpc 无论是在技术上还是业务上2022-07-181
Sudouble从用户角度看：当消息中间件中的处理发生了延迟的情况下，而用户注册后又要立马查看积分信息时，会出现不可用/信息异常的情况。2023-05-17归属地：北京
芋头1.可用性 引入的初衷就包含削峰填谷、解耦整体上提升系统可用性，如果这个环节脆弱也会降低可用性，解决方案：集群及持久化措施 2.复杂性：如何确保消息不丢失、顺序消费、不重复消费都是需要考虑的问题 解决方案：不重复消费可以通过业务幂等性来保证 3.一致性：由于消费存在延迟，如何解决不一致性？待学习2023-03-26归属地：广东1
