1. 为什么你们公司抉择RabbitMQ作为消息中间件

在音讯队列选型时，咱们调研了市场上比拟罕用ActiveMQ，RabbitMQ，RocketMQ，Kafka。

  1. RabbitMQ绝对成熟稳固，这是咱们抉择它最次要的起因。
  2. 社区比拟沉闷，有欠缺的材料能够参考。
  3. Rabbitmq的吞吐量能够达到万级，齐全满足咱们零碎的要求。
  4. RabbitMQ是Erlang语言开发的，性能比拟好。
  5. 有欠缺的可视化界面，不便查看。

2. 音讯队列的长处和毛病有哪些

长处有：

  • 异步解决 - 相比于传统的串行、并行形式，进步了零碎吞吐量。
  • 利用解耦 - 零碎间通过音讯通信，不必关怀其余零碎的解决。
  • 流量削锋 - 能够通过音讯队列长度管制申请量；能够缓解短时间内的高并发申请。

毛病有：

  • 零碎可用性升高
  • 零碎复杂度进步

3. RabbitMQ罕用的工作模式有哪些

2.1 简略模型

  • p：生成者
  • C：消费者
  • 红色局部：quene，音讯队列

2.2 工作模型

这种模式下一条音讯只能由一个消费者进行生产，默认状况下，每个消费者是轮询生产的。

  • p：生成者
  • C1、C2：消费者
  • 红色局部：quene，音讯队列

2.3 公布订阅模型（fanout）

这种模型中生产者发送的音讯所有消费者都能够生产。

  • p：生成者
  • X：交换机
  • C1、C2：消费者
  • 红色局部：quene，音讯队列

2.4 路由模型（routing）

这种模型消费者发送的音讯，不同类型的音讯能够由不同的消费者去生产。

  • p：生成者
  • X：交换机，接管到生产者的音讯后将音讯投递给与routing key齐全匹配的队列
  • C1、C2：消费者
  • 红色局部：quene，音讯队列

2.5 主题模型（topic）

这种模型和direct模型一样，都是能够依据routing key将音讯路由到不同的队列，只不过这种模型能够让队列绑定routing key 的时候应用通配符。这种类型的routing key都是由一个或多个单词组成，多个单词之间用.宰割。

通配符介绍：

*：只匹配一个单词

#：匹配一个或多个单词

4. 如何保障音讯不失落（如何保障音讯的可靠性）

一条音讯从生产到生产经验了三个阶段，别离是生产者，MQ和消费者，对于RabbitMQ来说，音讯的传递还波及到交换机。因而RabbitMQ呈现音讯失落的状况有四个

别离是

  1. 音讯生产者没有胜利将音讯发送到MQ导致音讯失落
  2. 交换机未路由到音讯队列导致音讯失落
  3. 音讯在MQ中时，MQ产生宕机导致音讯失落
  4. 消费者生产音讯时出现异常导致音讯失落

针对下面提到的四种状况，别离进行解决

  1. amqp协定提供了事务机制，在投递音讯时开启事务，如果音讯投递失败，则回滚事务，很少有人去应用事务。除了事务之外，RabbitMQ还提供了生产者确认机制（publisher confirm）。生产者将信道设置成confirm（确认）模式，一旦信道进入confirm模式，所有在该信道下面公布的音讯都会被指派一个惟一的ID（从1开始），一旦音讯被投递到所有匹配的队列之后，RabbitMQ就会发送一个确认（Basic.Ack）给生产者（蕴含音讯的惟一ID），这就使得生产者通晓音讯曾经正确达到了目的地了。
# 开启生产者确认机制，# 留神这里确认的是是否达到交换机spring.rabbitmq.publisher-confirm-type=correlated
@RestControllerpublic class Producer {    @Autowired    private RabbitTemplate rabbitTemplate;    @GetMapping("send")    public void sendMessage(){        /**         * 生产者确认音讯         */        rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {            @Override            public void confirm(CorrelationData correlationData, boolean ack, String cause) {                System.out.println(correlationData);                System.out.println(ack);                System.out.println(cause);            }        });        rabbitTemplate.convertAndSend("s","error","这是一条谬误日志！！！");    }}
  1. 音讯从交换机未能匹配到队列时将此条音讯返回给生产者
spring.rabbitmq.publisher-returns=true
@RestControllerpublic class Producer {    @Autowired    private RabbitTemplate rabbitTemplate;    @GetMapping("send")    public void sendMessage(){        /**         * 音讯未达队列时返回该条音讯         */        rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {            @Override            public void returnedMessage(ReturnedMessage returnedMessage) {                System.out.println(returnedMessage);            }        });        rabbitTemplate.convertAndSend("s","error","这是一条谬误日志！！！");    }}
  1. 音讯在交换机或队列中产生失落，咱们只须要将交换机和队列进行长久化。
/**  * 定义一个长久化的topic交换机  * durable 长久化  * @return */@Beanpublic Exchange exchangeJavatrip(){    return ExchangeBuilder.topicExchange(EXCHANGE).durable(true).build();}/** * 定义一个长久化的队列 * durable 长久化 * @return */@Beanpublic Queue queueJavatrip(){    return QueueBuilder.durable(QUEUE).build();}
  1. 消费者开启手动签收模式，生产实现后进行ack确认。
spring.rabbitmq.listener.simple.acknowledge-mode=manual
@RabbitListener(queues = MqConfig.QUEUE)public void receive(String body, Message message, Channel channel) throws Exception{    long deliveryTag = message.getMessageProperties().getDeliveryTag();    System.out.println(deliveryTag);    // 零碎业务逻辑判断是否签收    if(deliveryTag % 2 == 0){        channel.basicAck(deliveryTag,false);    }else{        // 第二个参数是否批量确认，第三个参数是否从新回队列        channel.basicNack(deliveryTag,false,true);    }}

5. 如何保障音讯不反复生产（如何保障音讯的幂等性）

音讯反复的起因有两个：

  1. 生产时音讯反复

    因为生产者发送音讯给MQ，在MQ确认的时候呈现了网络稳定，生产者没有收到确认，实际上MQ曾经接管到了音讯。这时候生产者就会从新发送一遍这条音讯。

  2. 生产时音讯反复。

    消费者生产胜利后，在给MQ确认的时候呈现了网络稳定，MQ没有接管到确认，为了保障音讯被生产，MQ就会持续给消费者投递之前的音讯。这时候消费者就接管到了两条一样的音讯。

因为音讯反复是网络稳定等起因造成的，无奈防止，咱们能做的的就是保障音讯的幂等性，以防业务反复解决。具体解决计划为：

让每个音讯携带一个全局的惟一ID，即可保障音讯的幂等性，具体生产过程为：

  1. 消费者获取到音讯后先依据id去查问redis/db是否存在该音讯。
  2. 如果不存在，则失常生产，生产结束后写入redis/db。
  3. 如果存在，则证实音讯被生产过，间接抛弃。
@RabbitListener(queues = MqConfig.QUEUE)public void receive(Message message, Channel channel){    String messageId = message.getMessageProperties().getMessageId();    String body = new String(message.getBody());    String redisId = redisTemplate.opsForValue().get(messageId)+"";    // 如果redis中存有以后音讯的音讯id    // 则证实生产过    if(messageId.equals(redisId)){        return;    }    redisTemplate.opsForValue().set(messageId, UUID.randomUUID());}

6. 音讯大量沉积应该怎么解决

音讯沉积的起因有两个

  1. 网络故障，消费者无奈失常生产
  2. 生产方生产后未进行ack确认

解决方案如下：

  1. 查看并修复消费者故障，使其失常生产
  2. 编写长期程序将沉积的音讯发送到容量更大的MQ集群，减少消费者疾速生产
  3. 沉积音讯生产结束后，进行长期程序，恢复正常生产

7. 死信是什么？死信如何解决

当一条音讯在队列中呈现以下三种状况的时候，该音讯就会变成一条死信。

  • 音讯被回绝(basic.reject / basic.nack)，并且requeue = false
  • 音讯TTL过期
  • 队列达到最大长度

当音讯在一个队列中变成一个死信之后，如果配置了死信队列，它将被从新publish到死信交换机，死信交换机将死信投递到一个队列上，这个队列就是死信队列。

一条音讯成为死信后，个别会通过死信队列进行存库，而后定时将库中的死信进行从新投递到音讯队列上。

8. 如果我有一笔订单，30分钟未领取则敞开订单，应用RabbitMQ如何来实现

RabbitMQ能够应用死信队列来实现延时生产，用户下单之后，将订单信息投递到音讯队列中，并且设置音讯过期时常为30分钟。如果用户领取则失常敞开订单，如果用户未领取，音讯达到过期工夫，音讯会进入死信替换，由消费者进行生产死信队列来敞开订单。

9. RabbitMQ如何保障高可用

RabbitMQ有两种集群模式，别离是一般集群和镜像集群，一般模式无奈保障RabbitMQ的高可用。

一般集群

如果有三个节点，rabbitmq1、rabbitmq2、rabbitmq3，音讯实际上只存在于其中一个节点，三个节点仅有雷同的元数据，即队列的构造，当音讯进入rabbitmq2节点的queue后，consumer从rabbitmq1的节点进行生产，rabbitmq1和rabbitmq2会进行长期通信，从rabbitmq2中获取音讯而后返回给consumer。

这种模式存在以下两个问题：

  1. 当rabbitmq2宕机后，音讯无奈失常生产，没有做到真正的高可用
  2. 理论数据还是在单个实例上，存在瓶颈问题

镜像集群

如果有三个节点，rabbitmq1、rabbitmq2、rabbitmq3，每个实例之间都能够互相通信，每次生产者写音讯到queue的时候，每个rabbitmq节点上都有queue的音讯数据和元数据。这种模式应用于可靠性要求较高的场景。

点关注、不迷路

如果感觉文章不错，欢送关注、点赞、珍藏，你们的反对是我创作的能源，感激大家。

如果文章写的有问题，请不要吝惜文笔，欢送留言指出，我会及时核查批改。

如果你还想看到更多别的货色，能够微信搜寻「Java旅途」进行关注。回复“手册”支付Java面试手册！