【第246期】面试官：说说你对RabbitMQ的理解以及使用场景

2022年5月17日 4:04 pm • 面试问题 • 阅读 18 1.RabbitMQ简介 MQ 代表消息队列。消息队列 (MQ) 是一种应用程序到应用程序的通信方法。应用程序通过在队列中读取和写入消息（应用程序特定数据）来进行通信，而不需要专用连接来链接它们。 消息传递是指程序通过发送消息中的数据来相互通信，而不是通过直接相互调用来进行通信，这通常用于远程过程调用等技术。队列是指应用程序通过队列进行通信。队列的使用消除了接收和发送应用程序同时执行的要求。 RabbitMQ是一个使用Erlang语言开发并基于AMQP协议实现的开源消息队列系统。 AMQP的主要特点是面向消息、面向队列、路由（包括点对点和发布/订阅）、可靠性和安全性。 AMQP协议多用于企业系统，对数据一致性、稳定性和可靠性要求非常高的场景，性能和吞吐量要求是次要的。 2.RabbitMQ使用场景 1、解耦（为面向服务架构（SOA）提供基本的最终一致性实现） 场景描述：用户下单后，订单系统需要通知库存系统。传统的做法是订单系统调用库存系统的接口。 图片 传统模式的缺点： 如果库存系统无法访问，就会导致订单减少失败，导致订单失败。 订单系统与库存系统耦合 引入消息队列 图片 订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，并返回用户订单成功。 库存系统：订阅订单消息，使用pull/push方式获取订单信息。库存系统根据订单信息进行库存操作。 如果：下订单时库存系统无法正常工作。不影响正常下单，因为下单后，订单系统写入消息队列，不再关心后续的其他操作。实现订单系统和库存系统的应用解耦 为了保证肯定有库存，可以将队列大小设置为库存数量，或者使用其他方法来解决问题。 基于消息的模型关注的是“通知”而不是“处理”。 短信、邮件通知、缓存刷新等操作均使用消息队列进行通知。 图片 消息队列和RPC的区别和比较： RPC：异步调用，及时获取调用结果，结果一致性强，关心业务调用处理结果。 消息队列：进行两次异步RPC调用，将调用内容转储到队列中，并选择合适的时间进行投递（非高峰流量控制）2.异步提高效率 场景描述：用户注册后，需要发送注册邮件和注册短信。传统的方法有两种： 1、串行法； 2. 并行法 扩展： 异步并发工具：实际项目中使用CompletionService提升系统性能的实践 (1)串口模式：成功将注册信息写入数据库后，发送注册邮件，然后发送注册短信。以上三个任务全部完成后，返回给客户端 图片 (2)并行方式：注册信息成功写入数据库后，同时发送注册邮件和注册短信。以上三个任务完成后，返回给客户端。与串行的区别在于并行的方法可以提高处理时间 图片 消息队列的引入消除了必要的业务逻辑和异步处理。修改后的架构如下： 图片 3、流量削峰 流量调峰也是消息队列中常见的场景，一般大量用于秒杀或者团抢。 应用场景：系统A在系统其他时间每秒有100个请求，系统可以稳定运行。系统每晚8点有闪购活动，每秒并发请求数增至10000。但系统最大处理能力每秒只能处理1000个请求，因此系统崩溃，服务器宕机。 以往架构：晚上8点高峰期，大量用户（100万用户）通过浏览器同时参与闪购活动。大量请求涌入我们的系统，高峰期达到每秒 5000 个请求。大量请求发送到MySQL，估计每秒执行3000条SQL语句。但一般MySQL每秒可以处理2000个请求。如果达到3000个请求，MySQL可能会直接瘫痪，导致系统无法使用。但高峰期过后，就变成了低峰期。只有10000个用户可能访问系统，每秒的请求数只有50个左右，整个系统几乎没有压力。 引入MQ：100万用户高峰期，每秒大概有5000个请求。如果将这5000个请求写入MQ，系统A每秒最多只能处理2000个请求，因为MySQL每秒只能处理2000个请求。问。系统A缓慢地从MQ拉取请求，每秒拉取2000个请求，不超过其每秒可以处理的请求数。 MQ，每秒有 5000 个请求进来，但只有 2000 个请求出去，所以在秒杀期间（近一个小时）可能有几十万、上百万的请求积压在 MQ 中。 关于流量削峰：秒杀系统的流量削峰应该怎么做？在这短暂的高峰期，积压是没有问题的，因为高峰期过后，每秒只有50个请求进入MQ，但系统仍然以每秒2000个请求的速度处理，所以只要高峰期结束后，系统会快速消耗掉积压的消息。我们这里算一下：MQ每秒积压3000条消息，一分钟积压18万条消息，一小时积压1000万条消息。高峰期过后，积压的1000万条消息一个多小时就可以消耗完。 图片 3.引入消息队列的优缺点 优势 优点是上述场景应用在解耦、异步、削峰等特殊场景下都有其相应的好处。 缺点 系统可用性降低 系统引入的外部依赖越多，系统就越容易挂掉。本来系统A只需要调用BCD这三个系统接口即可。如果四个系统ABCD不报错，则整个系统运行正常。引入MQ后，虽然ABCD系统没有出问题，但MQ失败后整个系统就会崩溃。 系统复杂性增加 引入MQ之后，需要考虑的问题就更多了。如何保证消息不被重复消费？如何保证消息不丢失？如何保证消息传递的顺序？ 一致性问题 系统A发送消息后直接返回成功。但如果BCD系统中任何一个系统写数据库失败，就会出现数据不一致的情况。 总结 所以综上所述，消息队列是一个非常复杂的架构。引入它有很多好处，但必须做出各种额外的技术方案和架构来避免它带来的缺点。 MQ的引入系统复杂度增加了一个数量级，但在某些场景下，即使复杂十倍，仍然需要使用MQ。 作者：海翔 www.sychzs.cn/haifang/p/10199754.html 结尾 推荐十期 【第231期】面试官：Java中serialVersionUID的作用是什么？ 【第232期】面试官：spring的IOC容器比New对象好在哪里？ 【第233期】面试官：什么是耦合？解耦的方法有哪些？ 【第234期】30道必备Java面试题及答案 【第235期】面试官：Redis数据是存储在内存中的吗？说说Redis各种数据类型的使用场景？ 【第236期】面试官：线程池中的多余线程如何回收？ 【第237期】面试官：如何发现Redis热键，解决方案是什么？ 【第238期】面试官：新版本的Redis已经开始引入多线程了。你怎么认为？ 【第239期】面试官：电商系统中如何使用Redis实现库存扣减？ 【第240期】面试官：你了解JVM内存溢出吗？而不是在网上搜索问题？还不赶快关注我们吧~ 版权声明：本文内容由网友自愿贡献，本文所表达的观点仅代表作者自己的观点。本网站仅提供信息存储空间服务，不拥有任何所有权，也不承担相关法律责任。如果您发现本站有任何涉嫌侵权/非法内容，请发送邮件举报。一经核实，该网站将立即删除。 本文由斑马博客整理。本文链接为：https://www.sychzs.cn/index.php/post/8010.html