非常强悍的 RabbitMQ 总结,看完别再说你不会RabbitMQ

rabbitMQ是基于AMQP协议的,通过使用通用协议就可以做到在不同语言之间传递。

核心概念

非常强悍的 RabbitMQ 总结,看完别再说你不会RabbitMQ

交换机的类型,direct、topic、fanout、headers,durability(是否需要持久化true需要)auto delete当最后一个绑定Exchange上的队列被删除Exchange也删除。

The default exchange is implicitly bound to every queue, with a routing key equal to the queue name. It is not possible to explicitly bind to, or unbind from the default exchange. It also cannot be deleted.

非常强悍的 RabbitMQ 总结,看完别再说你不会RabbitMQ_第1张图片

非常强悍的 RabbitMQ 总结,看完别再说你不会RabbitMQ

在高并发场景下,每次进行db的操作都是非常消耗性能的。我们使用延迟队列来减少一次数据库的操作。

幂等性是什么?

我对一个动作进行操作,我们肯能要执行100次1000次,对于这1000次执行的结果都必须一样的。比如单线程方式下执行update count-1的操作执行一千次结果都是一样的,所以这个更新操作就是一个幂等的,如果是在并发不做线程安全的处理的情况下update一千次操作结果可能就不是一样的,所以并发情况下的update操作就不是一个幂等的操作。对应到消息队列上来,就是我们即使收到了多条一样的消息,也和消费一条消息效果是一样的。

理解confirm消息确认机制

Return消息机制处理一些不可路由的消息,我们的生产者通过指定一个Exchange和Routinkey,把消息送达到某一个队列中去,然后我们消费者监听队列进行消费处理!在某些情况下,如果我们在发送消息的时候当Exchange不存在或者指定的路由key路由找不到,这个时候如果我们需要监听这种不可到达的消息,就要使用Return Listener!

Mandatory 设置为true则会监听器会接受到路由不可达的消息,然后处理。如果设置为false,broker将会自动删除该消息。

什么是消费端的限流?

假设我们有个场景,首先,我们有个rabbitMQ服务器上有上万条消息未消费,然后我们随便打开一个消费者客户端,会出现:巨量的消息瞬间推送过来,但是我们的消费端无法同时处理这么多数据。这时就会导致你的服务崩溃。 其他情况也会出现问题,比如你的生产者与消费者能力不匹配,在高并发的情况下生产端产生大量消息,消费端无法消费那么多消息。

void basicQOS(unit prefetchSize,ushort prefetchCount,Boolean global)方法。

TTL time to live 生存时间。

死信队列:DLX,Dead-Letter-Exchange

利用DLX,当消息在一个队列中变成死信(dead message,就是没有任何消费者消费)之后,他能被重新publish到另一个Exchange,这个Exchange就是DLX。

消息变为死信的几种情况:

DLX也是一个正常的Exchange,和一般的Exchange没有任何的区别,他能在任何的队列上被指定,实际上就是设置某个队列的属性。当这个队列出现死信的时候,RabbitMQ就会自动将这条消息重新发布到Exchange上去,进而被路由到另一个队列。可以监听这个队列中的消息作相应的处理,这个特性可以弥补rabbitMQ以前支持的immediate参数的功能。

死信队列的设置

非常强悍的 RabbitMQ 总结,看完别再说你不会RabbitMQ

非常强悍的 RabbitMQ 总结,看完别再说你不会RabbitMQ

federation插件是一个不需要构建Cluster,而在Brokers之间传输消息的高性能插件,federation可以在brokers或者cluster之间传输消息,连接的双方可以使用不同的users或者virtual host双方也可以使用不同版本的erlang或者rabbitMQ版本。federation插件可以使用AMQP协议作为通讯协议,可以接受不连续的传输。

非常强悍的 RabbitMQ 总结,看完别再说你不会RabbitMQ_第2张图片

非常强悍的 RabbitMQ 总结,看完别再说你不会RabbitMQ

Federation Exchanges,可以看成Downstream从Upstream主动拉取消息,但并不是拉取所有消息,必须是在Downstream.上已经明确定义Bindings关系的Exchange,也就是有实际的物理Queue来接收消息,才会从Upstream拉取消息到Downstream。使用AMQP协议实施代理间通信,Downstream 会将绑定关系组合在一起, 绑定/解除绑定命令将发送到Upstream交换机。因此,FederationExchange只接收具有订阅的消息.

HAProxy是一款提供高可用性、负载均衡以及基于TCP (第四层)和HTTP(第七层)应用的代理软件,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。 HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上,完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中同时可以保护你的web服务器不被暴露到网络上。

数据的方式完成读写操作,这会节约大量的CPU时钟周期及内存带宽

零复制转发(Zero-copy forwarding),在Linux 3.5及以上的OS中还可以实现心零复制启动(zero-starting)

建一个会话的时长

的低开销来保持计时器命令、保持运行队列命令及管理轮询及最少连接队列

KeepAlived软件主要是通过VRRP协议实现高可用功能的。VRRP是Virtual Router RedundancyProtocol(虚拟路由器冗余协议)的缩写,VRRP出现的目的就是为了解决静态路由单点故障问题的,它能够保证当个别节点宕机时,整个网络可以不间断地运行所以,Keepalived - -方面具有配置管理LVS的功能,同时还具有对LVS下面节点进行健康检查的功能,另一方面也可实现系统网络服务的高可用功能

Keepalived高可用服务对之间的故障切换转移,是通过VRRP (Virtual RouterRedundancy Protocol ,虚拟路由器冗余协议)来实现的。在Keepalived服务正常工作时,主Master节点会不断地向备节点发送( 多播的方式)心跳消息,用以告诉备Backup节点自己还活看,当主Master节点发生故障时,就无法发送心跳消息,备节点也就因此无法继续检测到来自主Master节点的心跳了,于是调用自身的接管程序,接管主Master节点的IP资源及服务。而当主Master节点恢复时备Backup节点又会释放主节点故障时自身接管的IP资源及服务,恢复到原来的备用角色

领取更多Java核心技术主流资料和大厂面试题,转发+关注私信我

你可能感兴趣的:(非常强悍的 RabbitMQ 总结,看完别再说你不会RabbitMQ)