Javaswing菜鸟教程，使⽤指南
1. 消息的可靠性投递
在使⽤ RabbitMQ 的时候，作为消息发送⽅希望杜绝任何消息丢失或者投递失败场景。
RabbitMQ 为我们提供了两种⽅式⽤来控制消息的投递可靠性模式。
confirm 确认模式：当消息从 producer 发送到 exchange 则会执⾏ confirmCallback中的confirm⽅法。
return 退回模式：当消息发送给Exchange后, Exchange将消息路由到queue失败会执⾏ReturnCallBack。
确认模式会返回{1.相关配置信息, 2.交换机是否成功接收到消息 , true 成功 false失败 3.失败原因 }
回退模式会返回{1.消息对象,2.错误码,3.错误信息,4.交换机名称,5.路由键}
2.Consumer ACK(消费者 ACK)
ack指Acknowledge，确认。 表⽰消费端收到消息后的确认⽅式。
RabbitMQ提供三种确认⽅式：
⾃动确认: acknowledge=“none” 当消息⼀旦被Consumer接收到，则⾃动确认收到，并将相应 message 从 RabbitMQ 的消息缓存中移除。
⼿动确认: acknowledge=“manual” 如果出现异常，则调⽤channel.basicNack()⽅法，让其⾃动重新发送消息。
根据异常情况确认：acknowledge=“auto”。
3. 消息过期(TTL)
TTL 全称 Time To Live（存活时间/过期时间）。当消息到达存活时间后，还没有被消费，会被⾃动清
除。
RabbitMQ可以对消息设置过期时间，也可以对整个队列（Queue）设置过期时间。
消息过期, 可以让队列统⼀过期, 也可以让它单独的消息过期。
4. 死信队列
死信队列，英⽂缩写：DLX 。Dead Letter Exchange（死信交换机），当消息成为Dead message (死信)后，可以被重新发送到另⼀个交换机，这个交换机就是DLX。
消息成为死信的三种情况：
1.队列消息长度到达限制；
2.消费者拒接消费消息，并且不把消息重新放⼊原⽬标队列;
3.原队列存在消息过期设置，消息到达超时时间未被消费；
死信队列和死信交换机：
死信队列和死信交换机与正常的队列和交换机⼀模⼀样, 没有任何区别 !!
如何实现队列与死信交换机绑定 , 给队列设置如下参数：
x-dead-letter-exchange : 设置死信交换机
x-dead-letter-routing-key : 设置死信路由key
javaswing实现购买
5. 延迟队列
消息进⼊队列后不会⽴即被消费，只有到达指定时间后，才会被消费。 例如:
延迟队列是⼀个很强⼤的功能 , 但是在RabbitMQ中并没有提供延迟队列功能。可以使⽤：TTL(消息过期)+死信队列组合实现延迟队列的效果。
实现流程图如下 :
6. 消费端限流
当系统峰值⽐较⾼的时候 , 我们我们可以使⽤RabbitMQ实现削峰填⾕, 让我们系统处理的请求更加平稳
实现步骤
1. 设置akc机制为⼿动确认
2. 配置监听容器
7.RabbitMQ应⽤问题 (消息补偿机制)
我们通过之前的消息可靠性投递 , ACK 确认机制 , 以及死信队列 , 基本上已经能够保证消息投递成功了 !
为什么还要消息补偿机制呢？ 难道消息还会丢失，没错，系统是在⼀个复杂的环境，不要想的太简单了，虽然以上的三种⽅案，基本可以保证消息的⾼可⽤不丢失的问题，但是作为有追求的程序员来讲，要绝对保证我的系统的稳定性，有⼀种危机意识。
⽐如：持久化的消息，保存到硬盘过程中，当前队列节点挂了，存储节点硬盘⼜坏了，消息丢了，怎么办？
产线⽹络环境太复杂，所以不知数太多，所以要做消息补偿机制 !
消息补偿机制需要建⽴在业务数据库和MQ数据库的基础之上 , 当我们发送消息时 , 需要同时将消息数据保存在数据库中, 两者的状态必须记录。 然后通过业务数据库和MQ数据库的对⽐检查消费是否成功，不成功，进⾏消息补偿措施，重新发送消息处理
最后
关于⾯试刷题也是有⽅法可⾔的，建议最好是按照专题来进⾏，然后由基础到⾼级，由浅⼊深来，效果会更好。当然，这些内容我也全部整理在⼀份pdf⽂档内，分成了以下⼏⼤专题：
Java基础部分
算法与编程
数据库部分
流⾏的框架与新技术（Spring+SpringCloud+SpringCloudAlibaba）

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。