为什么使用MQ？优点？
- 支持异步处理,可以提高系统吞吐量
- 应用解耦,可以通过消息通讯,无需关心其他系统的处理结果。
- 流量削峰,消费者可以一次拉取一个或多条消息进行消费,而不是一下子消费生产者产生的大量请求。
MQ有什么缺点呢？
- 系统复杂度变高,当你的系统引进一个中间件的时候,就要考虑中间件是否会宕机等情况。
- 一致性问题,你发送一条消息给A和B两个系统,A系统正常消费了,B系统消费失败了,导致了数据不一致的问题。
MQ有哪些常见的问题？如何解决这些问题？
- 消息的幂等性问题。
- 如果某个提供者由于网络等问题,无法确认消息已经发送了,从而又发送了一次,就会导致消费者会消费两次这条消息,所以需要消费者进行一个幂等性的保证,可以通过某个字段做一个唯一性校验。例如消息体中某个字段对应DB中的唯一索引,这样消息来之前看这条消息是否已经处理过了。
- 消息的顺序性问题？
- 消息的顺序性指的是消费者按照消息的发送顺序来进行消费。但我们现在的服务都是分布式的,存在多台消费者,那么这种情况可能就导致了,不同消息的消费顺序可能会不一致。
- 解决方案：可以从业务的角度上去处理这种顺序问题,例如将有序的两个操作放在同一个消息体中。
RabbitMQ中的基本概念？
- Exchange：交换器,指定了消息按照什么规则,路由到那个队列。
- Queue:消息队列,消息存储的地方。
- Binding:绑定,交换器和队列要通过 路由规则 进行绑定。
- Routing key:路由key,指定了这条消息的路由规则,交换器根据其进行消息投递
你们的RabbitMQ采用哪种路由模式？
常用的路由模式有三种： 1.fanout: 如果交换器收到消息,将会广播到所有绑定的队列上。 2.direct: 如果路由键完全匹配,消息会被投递到响应的队列上。 3.topic： 支持路由键模糊匹配,#代表多个单词, * 代表一个单词
如何保证生产者消息正确的发送至MQ？
- RabbitMQ提供了一个 confirm模式,即生产者确认消息,所有在信道上发布的消息会被指派一个唯一ID。
- 消息被投递到目的队列后,或者写入磁盘后,信道会发送一个确认给生产者,包含了唯一ID。
- 发送发确认模式有同步模式和异步模式,同步模式就是等待消息队列响应,异步模式就是提供了一个监听者回调方法,有ack和nack两个方法,发送成功就是ack,发送失败就是nack。
如何保证消费者消费了消息？
- 可以采用消费者确认模式,消费者接收到消息后手动进行ACK。
如何保证MQ可靠传输？
- 消息不可靠有几种情况：
- 生产者丢失消息：生产者确认机制
- 消息队列丢失消息：将消息进行持久化
- 消费者丢失消息：关闭自动确认机制,使用手动确认机制,正常消费后才会被在队列删除。或者我们用DB存储异常消息。
消息堆积如何解决？
- 先修复消费者的问题,然后可以多绑定几个队列与该交换器,消费者端配置并发消费的属性,同时接收几条消息。
设计MQ有哪些思路？
- 需要考虑消息的持久性
- 以及消息队列服务的高可用性。
- 以及消息的通讯是否高效等。
