java面试---MQ

RabbitMQ介绍

consumer（消费者）：使用队列Queue从Exchange中获取消息的应用

Exchange（交换机）：负责接收生产者的消息并把它们转到合适的队列

Queue（队列）：一个存储exchange发来的消息的缓冲，并将消息主动发送给Consumer，或者Consumer主动来获取

Binging（绑定）：队列和交换机之间的关系。Exchange根据消息的属性和Bingding的属性来转发消息。绑定的一个重要属性是binding_key.

Connection（连接）和Channel（通道）：生产者和消费者需要和MQ建立TCp连接。一些应用需要多个connection，为了节省TCP连接，可以使用Channel，它可以被认为是一种轻型的共享TCP连接的连接。

Message（消息）：MQ转发的二进制对象，包括Header、Properties、Data。其中数据部分不是必要的。producer：消息的生产者，负责产生消息并把消息发到交换机

 

工作队列

当我们把任务当做消息发送到队列中，一个运行在后台的工作者进程就会去除任务然后处理。当运行多个工作者，任务就会在它们之前共享

工作队列就是为了避免等待一些占用大量资源、时间的操作，它会发送一些耗时的任务给多个工作者

 

发布/订阅

用于一对多的通讯，当消息发布者像一个主题topic发送一条消息后，该主题的所有订阅者都会收到这条信息

 

MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务

 

MQ的不足：

1）系统更加复杂，多了一个mq组件

2）消息传递路径更长，延时会增加

3）消息的可靠性和重复性互为矛盾，消息不丢和不重难以同时同时保证

4）上游无法知道下游运行结果

 

什么时候使用MQ

1）数据驱动的任务依赖

三个任务，任务2需要依赖任务1的结果，3依赖2的结果；此时可以用MQ，首先执行1,1结束后发送消息到2,2开始执行，后面同理

MQ只用来传递上游任务执行完成的消息，不用于传递真正的输入输出数据

2）上游不关心执行结果

3）异步返回执行时间长

 

1，发送端MQ-client将消息发给服务端MQ-server

2，服务端MQ-server将消息落地

3，服务端MQ-server回ACK给发送端MQ-client

4，服务端MQ-server将消息发给接收端MQ-client

5，接收端MQ-client回ACK给服务端

6，服务端MQ-server将落地消息删除

消息队列实现消息必达

1）消息落地

2）消息超时，重传，确认

 

消息总线保证幂等

1）在上半场的消息传递生产内部消息ID，全局唯一，MQ生产生成与业务无关

2）在下半场业务发送方带入id，业务接收方去重保证幂等

 

延时消息功能

1、采用定时任务，规定时间内未完成任务执行该任务

缺点：

1）轮询效率低

2）有重复计算的嫌疑

3）时效性不够好

 

2)环形队列和任务集合

 

MQ快速实现流量削峰填谷

1、不管采用直接调用还是mq推送，都有一个缺点，下游接受消息无法控制到达自己的流程，如果调用方不限速，很有可能把下游压垮

2、优化方案：

1）业务上游队列缓冲，限制发送

2）业务下游队列缓冲，限速执行

3、MQ怎么缓冲流量

由MQ-server推模式改为MQ-client拉的模式

客户端根据自身能力，每次拉取若干条消息进行处理

4、总结

1）MQ-client提供拉模式，定时或者批量拉取，可以起到削平流量，下游自我保护的作用（MQ需要做的）

2）要想提升整体吞吐量，需要下游优化，例如批量处理等方式（消息接收方需要做的）

 

怎么解决kafka的数据丢失

producer端：

宏观上看保证数据的可靠安全性，肯定是依据分区数做好数据备份，设立副本数。

broker端：

topic设置多分区，分区自适应所在机器，为了让各分区均匀分布在所在的broker中，分区数要大于broker数。

分区是kafka进行并行读写的单位，是提升kafka速度的关键。

Consumer端

consumer端丢失消息的情形比较简单：如果在消息处理完成前就提交了offset，那么就有可能造成数据的丢失。由于Kafka consumer默认是自动提交位移的，所以在后台提交位移前一定要保证消息被正常处理了，因此不建议采用很重的处理逻辑，如果处理耗时很长，则建议把逻辑放到另一个线程中去做。为了避免数据丢失，现给出两点建议：

enable.auto.commit=false  关闭自动提交位移

在消息被完整处理之后再手动提交位移