消息队列
标签（空格分隔）： 面试 消息队列
1. 为什么使用消息队列
会用消息队列, 但是为什么要用消息队列呢?
- 系统解耦 异步 削峰填谷
1.1 解耦
解决因为数据处理能力不同, 薄弱阶段一旦崩溃, 导致的一死全死.
假设 系统A 发布消息, 此时系统B,C,D 接收并处理消息. 这个时候我们需要将B,C,D以及未来更多的消息接受者接入系统A,需要不断地修改系统A的代码,过于麻烦.
- 我们接入中间件消息队列, 此时系统A将消息 写入消息队列, 消息消费者只需要订阅消息队列即可接收消息, 此时达到了低耦合的目标.
1.2 异步
将一些非必要的业务逻辑以同步的方式运行会比较耗费时间. 这样 全程同步并阻塞的设计理念是渐渐被淘汰的, 正如阿里微服务框架一直在追求的全程异步非阻塞相契合.
1.3 削峰
当突然之间有大量请求涌入的时候, 按照传统模式进行开发的框架, 在同一时间内无法处理如此多的请求, 系统A不断地处理请求, 并且和数据库进行交互操作, 可能会造成数据库无法承受如此之高的并发量造成异常.
- 引入消息队列, 系统A可以慢慢地处理并发量, 在这个短暂的高峰期造成些许的消息积压,相对于系统的崩溃是更加可以令人接受的.
2. 为什么不可以使用消息队列
无论是什么技术 ,如果框架中集成了越多的技术, 就会使其本身可用性不断降低, 系统的整体复杂性不断地提高.
- 如果消息队列挂了, 那么系统就挂了. 如果做到消息一致性, 保证消息不会被重复消费, 如何保证消息的可靠传输, 不丢失消息.
3. 为什么是 RockerMQ 或 RabbitMQ
3.1 RocketMQ
阿里巴巴开发并且已将加入到Apache, 其后续的维护开发值得信赖, 阿里出品并发极高, 可用性依靠他的分布式和主从模式在可用性方面也很无敌. 在消息积压方面可以做到亿级消息积压而不丢失, 应对削峰有很大的优势. 并且支持事务类消息.
3.2 RabbitMQ
管理界面很强大,而且社区很活跃, 并且万级的吞吐量已经足够用了. 首先选择一个功能强大,虽然吞吐量没有RocketMQ那么高, 但是已经足够了.
3.3 如何保证消息队列是高可用的.
引入消息队列之后, 系统的可用性下降, 在开发环境中我们经常使用单机模式的消息队列, 但是在生产环境当中是应该是将其部署为集群模式. RocketMQ的集群部署,RabbitMQ的集群部署