2周刷完100道前端优质面试真题-无密分享面试

download：2周刷完100道前端优质面试真题-无密分享
RabbitMq音讯丧失缘由及其处理计划
【2周刷完100道前端优质面试真题-无密分享】一、RabbitMQ音讯丧失缘由
1.1、消费者丧失音讯
消费者将数据发送到rabbitmq的时分，可能由于网络问题招致数据就在半路给搞丢了。
1.运用事务（性能差）
? RabbitMQ 客户端中与事务机制相关的办法有三个： channel.txSelect 、channel.txCommit 和 channel.txRollback。channel.txSelect 用于将当前的信道设置成事务形式，channel.txCommit 用于提交事务，channel.txRollback 用于事务回滚。在经过 channel.txSelect 办法开启事务之后，我们便能够发布音讯给 RabbitMQ 了，假如事务提交胜利，则音讯一定抵达了 RabbitMQ 中，假如在事务提交执行之前由于 RabbitMQ异常解体或者其他缘由抛出异常，这个时分我们便能够将其捕获，进而经过执行channel.txRollback 办法来完成事务回滚。留意这里的 RabbitMQ 中的事务机制与大多数数据库中的事务概念并不相同，需求留意辨别。
? 事务的确可以处理音讯发送方和 RabbitMQ 之间音讯确认的问题，只要音讯胜利被RabbitMQ 接纳，事务才干提交胜利，否则便可在捕获异常之后停止事务回滚，与此同时能够停止音讯重发。但是运用事务机制会“吸干”RabbitMQ 的性能。
2.发送回执确认（引荐）
? 消费者将信道设置成 confirm（确认）形式，一旦信道进入 confirm 形式，一切在该信道上面发布的音讯都会被指派一个独一的 ID（从 1 开端），一旦音讯被投递到一切匹配的队列之后，RabbitMQ 就会发送一个确认（Basic.Ack）给消费者（包含音讯的独一 ID），这就使得消费者知晓音讯曾经正确抵达了目的地了。假如音讯和队列是可耐久化的，那么确认音讯会在音讯写入磁盘之后发出。RabbitMQ 回传给消费者确实认音讯中的 deliveryTag 包含了确认音讯的序号，此外 RabbitMQ 也能够设置 channel.basicAck 办法中的 multiple 参数，表示到这个序号之前的一切音讯都曾经得到了处置，留意区分这里确实认和消费时分确实认之间的异同。
留意要点:
事务机制和 publisher confirm 机制两者是互斥的，不能共存。
事务机制和 publisher confirm 机制确保的是音讯可以正确地发送至 RabbitMQ，这里的“发送至 RabbitMQ”的含义是指音讯被正确地发往至 RabbitMQ 的交流器，假如此交流器没有匹配的队列，那么音讯也会丧失。
1.2、RabbitMQ弄丢了数据-开启RabbitMQ的数据耐久化
? 为了避免rabbitmq本人弄丢了数据，这个你必需开启rabbitmq的耐久化，就是音讯写入之后会耐久化到磁盘，哪怕是rabbitmq本人挂了，恢复之后会自动读取之前存储的数据，普通数据不会丢。除非极端稀有的是，rabbitmq还没耐久化，本人就挂了，可能招致少量数据会丧失的，但是这个概率较小。
设置耐久化有两个步骤，第一个是创立queue的时分将其设置为耐久化的，这样就能够保证rabbitmq耐久化queue的元数据，但是不会耐久化queue里的数据；第二个是发送音讯的时分将音讯的deliveryMode设置为2，就是将音讯设置为耐久化的，此时rabbitmq就会将音讯耐久化到磁盘上去。必需要同时设置这两个耐久化才行，rabbitmq哪怕是挂了，再次重启，也会从磁盘上重启恢复queue，恢复这个queue里的数据。
而且耐久化能够跟消费者那边的confirm机制配合起来，只要音讯被耐久化到磁盘之后，才会通知消费者ack了，所以哪怕是在耐久化到磁盘之前，rabbitmq挂了，数据丢了，消费者收不到ack，你也是能够本人重发的。
若消费者那边的confirm机制未开启的状况下，哪怕是你给rabbitmq开启了耐久化机制，也有一种可能，就是这个音讯写到了rabbitmq中，但是还没来得及耐久化到磁盘上，结果不巧，此时rabbitmq挂了，就会招致内存里的一点点数据会丧失。
1.3、消费端弄丢了数据
? 为了保证音讯从队列牢靠地到达消费者，RabbitMQ 提供了音讯确认机制（message acknowledgement）。消费者在订阅队列时，能够指定 autoAck 参数，当 autoAck 等于 false时，RabbitMQ 会等候消费者显式地回复确认信号后才从内存（或者磁盘）中移去音讯（本质上是先打上删除标志，之后再删除）。当 autoAck 等于 true 时，RabbitMQ 会自动把发送进来的音讯置为确认，然后从内存（或者磁盘）中删除，而不论消费者能否真正地消费到了这些音讯。
? 采用音讯确认机制后，只需设置 autoAck 参数为 false，消费者就有足够的时间处置音讯（任务），不用担忧处置音讯过程中消费者进程挂掉后音讯丧失的问题，由于 RabbitMQ 会不断等候持有音讯直到消费者显式调用 Basic.Ack 命令为止。
? 这里我们能够经过RabbtiMQ 的 Web 管理平台上能够看到当前队列中的“Ready”状态和“Unacknowledged”状态的音讯数，分别对应上文中的等候投递给消费者的音讯数和曾经投递给消费者但是未收到确认信号的音讯数。
二、模仿消费端丧失数据
2.1、初始化工程
这里不做说了，能够看我《SpringBoot集成RabbitMQ》中的相关步骤。这里我们直接写消费者和消费者。
2.2、编写消费者
我们在之前的工程上停止相应的修正，经过http方式消费音讯。我们直接在IndexController中新增simpleProducer办法；
内容如下：
/**

@Author julyWhj
@Description IndexController$
@Date 2021/10/7 10:18 上午
**/

@RestController
public class IndexController {

@Autowired private SimpleProducer simpleProducer; @GetMapping("/index") public String index() { return "Hello RabbitMQ"; } @GetMapping("/producer") public String simpleProducer() { for (int i = 0; i < 10; i++) { simpleProducer.sendOrderMessage(Simple.builder() .createTime(new Date()) .name("JulyWhj") .age(i) .no("ID-000" + i) .phone("138XXXXXXXX") .build()); } return "音讯发送胜利"; }

}
复制代码
留意：
? 这里我们运用Debug方式启动，在消费者中加上断点，由于我们的消费者和消费者在同一个效劳中，消费的音讯会被消费者直接消费掉。所以我们加上断点，阻止消费者消费音讯。
这里我们看到，队列中音讯条数为0，呈现了音讯丧失的问题。
? 由于这里我们运用了消费者自动音讯确认机制。当 autoAck 等于 true 时，RabbitMQ 会自动把发送进来的音讯置为确认，然后从内存（或者磁盘）中删除，而不论消费者能否真正地消费到了这些音讯。
2.4、运用手动音讯确认机制
? 我们经过配置spring.rabbitmq.listener.simple.acknowledge-mode=manual属性，开启手动ack形式。默许配置auto自动确认。
在application配置文件中新增如下配置：
spring.rabbitmq.host=host
spring.rabbitmq.port=5672
spring.rabbitmq.virtual-host=/
开启手动ack确认音讯 spring.rabbitmq.listener.simple.acknowledge-mode=manual
三、RabbitMQ音讯牢靠性保证战略
1、消费者开启音讯确认机制
2、音讯队列数据耐久化
3、消费者手动ack
4、消费者音讯记载+定期补偿机制
5、效劳幂等处置
6、音讯挤压处置等
这里的内容我们在后续文章中单独展开剖析，这里只是给大家提供下需求留意的事项。包括TTL和DLX队列的运用等。