RabbitMQ

面试问 : 消息可靠性,高可用,幂等性

掌握交换机的类型和如何转发消息到队列

交换机的类型:
Fanout exchange（扇型交换机 或 广播）(重要)该交换机与队列绑定时无需指定路由key(RoutingKey)，该交换机会将消息发送给所有与之绑定的队列！
Direct exchange（直连交换机 或 定向）(重要) 获取消息中的路由key和绑定时指定的路由key,两者进行匹配,成功则转发
Topic exchange（主题交换机 或 通配符）(重要)将消息交给符合路由key的队列
Headers exchange（头交换机）
默认交换机(重要)一个生产者,多个消费者,之间是竞争关系(或者说是轮循,135,246,这样可以保证压力平均分配给消费者),一个数据只能有一个消费者获取到
本质就是一个队列可以被多个消费者监听

MQ消息队列,存消息的中间件,

交换机和队列绑定
分布式系统的两种通信方式:直接调用和借助第三方通信
发送方是生产者,接收的是消费者
MQ优势:1.应用解耦(提升了系统容错性和可维护性)2.异步提速(提高用户体验和系统吞吐量),3.削峰填谷(提高系统稳定性)
MQ缺点:1.系统可用性降低(依赖越多,可用性越低)2.系统复杂性提高(重复消费,消息丢失,消息传递的顺序性)3.一致性问题(有些系统处理成功,有些处理失败,几个系统之间要保持一致)
一个协议(AMQP,类比于HTTP) 一个规范(JMS,类比于JDBC)
面试常问区别:两个不是一回事,有什么区别,一个是协议,一个是规范
MQ六种工作模式:

AMQP:高级消息队列协议,网络协议
交换机,将消息转发给队列
队列,暂存消息
消费者通过Connection从队列中取消息
步骤
1.创建生产者工程,消费者工程
2.将MQ的依赖导入两个工程
-----helloword模式(用的默认交换机)-----------
3.创建连接工厂
4.设置参数(ip,端口,虚拟机,用户名,密码)
5.创建连接
6.创建queue
7.发送消息

-----Word-queues(默认交换机)模式-----------
一个生产者,多个消费者,之间是竞争关系(或者说是轮循,135,246,这样可以保证压力平均分配给消费者),一个数据只能有一个消费者获取到
本质就是一个队列可以被多个消费者监听
应用场景,队列消息过多,消费者来不及消费,队列消息积压

-----pubsub模式(广播)(掌握交换机类型,转发规则)(Fanout exchange(扇形)交换机)-----------
交换机(不存储数据):接收生产者发送的消息,转发给相关的队列(前提:交换机和队列进行绑定)
Fanout exchange:这种交换机和路由key没关系,该交换机将接收到的消息转发给所有和它绑定的队列,发消息时不需要指定路由key.

-----Routing(直连交换机)模式-----------
Direct 交换机(直连交换机/定向交换机):要用到路由key(交换机和队列进行绑定时,生产者发送消息时,都需要指定)
转发规则:获取消息中的路由key和绑定时指定的路由key,两者进行匹配,成功则转发
交换机判断信息类型
绑定的时候要声明级别,多个级别的话就多绑定几次
好处就是可以限制消费者接收到消息类型

-----Topics(主题/通配符交换机)模式-----------
交换机和队列绑定时要指定路由key(可以使用通配符)
生产者发送消息时,需要给每个消息指定路由key,需要精确编写(不能使用通配符)
转发规则:获取两边的路由key,进行 通配符 匹配,成功则转发

"."词和词之间的分隔符
"*":匹配一个单词
"#":匹配0或者多个单词

默认交换机:
1. 默认会和所有队列绑定,绑定时路由key就是对应的队列名称
2.是direct 类型交换机

 

消息的可靠投递
生产者确认(confirm)模式(可以明确知道消息是否发送成功):
从生产者到交换机,如果消息传递成功回调函数(confirmCallback)返回true,错误返回false
步骤:1.确认模式开启2.在rabbitTemplate中定义回调函数

生产者回退(return)模式(和生产者确认两者结合使用):
交换机到队列,通过路由key发送给队列,如果发送失败,会返回一个returnCallback.
当消息发送给交换机,交换机没有找到对应的路由key,
默认会将这条消息抛弃,可设置返回

----------------------------------------------------------
ACK(exchange交换机,是否成功收到了消息,true成功): 确认,表示消费端收到消息后放入确认方式

三种确认:
自动确认(acknowledge="none")(默认):出现异常消息会自动丢失 消息一旦被消费者接受到,则自动确认收到,并将相应的message(消息)
从MQ的缓存中移除.实际的业务开发中,很可能消息接收到,业务出现异常,那消息就会丢失.

手动确认(acknowledge="manual"):等待业务处理没有问题后再去调用代码channel.basicAck()手动签收,有异常的话可以调用channel.basicNack()方法重新发送

根据异常情况确认(acknowledge="auto")(比较麻烦,不用)
+++++++++++++++++++++++++++++++++++++++++++++++

死信消息:默认丢掉
----------------------------------------------------------
消息的高可用,就是利用消费端限速:
消费端限速
1.确保消费端确认模式为手动确认2.配置prefetch(相当于缓冲池,到达一定数量队列就不能推了)属性(设置消费端一次拉取多少消息)
消费者获取队列的方式 push:queue主动推送给消费者(无脑推) pull:消息者主动从队列中拉取消息(卓个拉取)
prefetch: 1.保护消费者 2.多个消费者,根据性能分配

++++++++++++++++++++++++++++++++++++++++
TTL(单位都是ms毫秒)设置过期时间
队列设置过期时间,会对整个队列消息使用统一过期时间设置。
自动删除是从队列头部信息开始删除(要头部信息过期)
可以给消息设置过期时间,消息到达存活时间后,会被自动清除
如果同时设置了消息和队列的过期时间,以短的为准
队列过期后,会清空里面的所有消息

----------------------------------------------
消息到达队列后,过期了,是会被删除还是放入死信队列?????还是开启了死信队列会放入,没开启就删除???
答:死信消息不处理的话,默认会被丢弃.

队列设置过期时间,会对整个队列消息使用统一过期时间设置。
队列设置了过期时间,队列到达了过期时间删除了,里面的信息呢,是不是全部删除????
答;是将队列里面的消息删除,队列不会删除
...................................................................

死信队列(死信交换机,给某个队列设置):
用处:主要是把成为死信的消息收集起来,进行处理.
死信消息不处理的话,默认会被丢弃.
成为死信的三种情况:
1.队列消息长度到达限制(队列中的消息已经到达了限制长度)
2.消费者拒收消息 ,并且不重回对列.
3.原队列存在消息过期设置,消息到达超时时间未被消费.
++++++++++++++++++++++++++++++++++++
延迟队列(TTL+死信队列):
消息到达队列后不会立即被消费,可以被延迟一定时间后才会被消费.
比如下单后30分钟后未支付

消息补偿机制:消息落地入库,循环重试,100%保证消息一定能被正确处理
-----------------------------------------------
幂等性保障:
幂等性:消费多条相同的消息,得到与消费该消息一次的结果
如何解决(有多种方案):对数据库操作(增删改),使用乐观锁,根据版本确定

集群搭建:
1.虚拟机关闭MQ,改变端口
2.克隆窗口,设置管理控制台,改端口
3.先停止节点服务
4.重置数据 ,再重启
5.另一个窗口,重置,加入集群
问题: 到现在为止里面数据还不能同步 主节点挂掉,从节点没数据
6.设置镜像队列(解决上面问题)
7.搭建负载均衡(用处:在java代码中方便访问)
7.1安装环境
7.2上传源码包
7.3解压,编译
7.4安装,创建文件夹
7.5添加组,添加用户
7.6创建文件
7.7修改端口号
7.8节点通信
7.9启动
8.0进入监控平台