世上最全的RabbitMQ-总结

rabbitMQ是基于AMQP协议的，经过使用通用协议就能够作到在不一样语言之间传递。

AMQP协议

核心概念

1. server：又称broker，接受客户端链接，实现AMQP实体服务。
2. connection：链接和具体broker网络链接。
3. channel：网络信道，几乎全部操做都在channel中进行，channel是消息读写的通道。客户端能够创建多个channel，每一个channel表示一个会话任务。
4. message：消息，服务器和应用程序之间传递的数据，由properties和body组成。properties能够对消息进行修饰，好比消息的优先级，延迟等高级特性；body是消息实体内容。
5. Virtual host：虚拟主机，用于逻辑隔离，最上层消息的路由。一个Virtual host能够若干个Exchange和Queue，同一个Virtual host不能有同名的Exchange或Queue。
6. Exchange：交换机，接受消息，根据路由键转发消息到绑定的队列上。
7. banding：Exchange和Queue之间的虚拟链接，binding中能够包括routing key
8. routing key： 一个路由规则，虚拟机根据他来肯定如何路由 一条消息。
9. Queue：消息队列，用来存放消息的队列。

Exchange

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

1. Direct Exchange,全部发送到Direct Exchange的消息被转发到RouteKey 中指定的Queue,Direct Exchange可使用默认的默认的Exchange （default Exchange），默认的Exchange会绑定全部的队列，因此Direct能够直接使用Queue名（做为routing key ）绑定。或者消费者和生产者的routing key彻底匹配。

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.

1. Toptic Exchange,是指发送到Topic Exchange的消息被转发到全部关心的Routing key中指定topic的Queue上。Exchange 将routing key和某Topic进行模糊匹配，此时队列须要绑定一个topic。所谓模糊匹配就是可使用通配符，“#”能够匹配一个或多个词，“”只匹配一个词好比“log.#”能够匹配“log.info.test” "log. "就只能匹配log.error。
2. Fanout Exchange:不处理路由键，只需简单的将队列绑定到交换机上。发送到改交换机上的消息都会被发送到与该交换机绑定的队列上。Fanout转发是最快的。

消息如何保证100％投递

什么是生产端的可靠性投递？

1. 保证消息的成功发出
2. 保证MQ节点节点的成功接收
3. 发送端MQ节点（broker）收到消息确认应答
4. 完善消息进行补偿机制

可靠性投递保障方案

1. 消息落库，对消息进行打标
2. 消息的延迟投递

在高并发场景下，每次进行db的操做都是每场消耗性能的。咱们使用延迟队列来减小一次数据库的操做。

消息幂等性

幂等性是什么？

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

高并发的状况下如何避免消息重复消费

1. 惟一id+加指纹码，利用数据库主键去重。

   优势：实现简单

   缺点：高并发下有数据写入瓶颈。

2. 利用Redis的原子性来实习。

   使用Redis进行幂等是须要考虑的问题

   • 是否进行数据库落库，落库后数据和缓存如何作到保证幂等（Redis和数据库如何同时成功同时失败）？
   • 若是不进行落库，都放在Redis中如何这是Redis和数据库的同步策略？还有放在缓存中就能百分之百的成功吗？

confirm 确认消息、Return返回消息

理解confirm消息确认机制

• 消息的确认，指生产者收到投递消息后，若是Broker收到消息就会给咱们的生产者一个应答，生产者接受应答来确认broker是否收到消息。

如何实现confirm确认消息。

• 在Channel上开启确认模式：channel.confirmSelect()
• 在channel上添加监听：addConfirmListener，监听成功和失败的结果，具体结果对消息进行从新发送或者记录日志。

return消息机制

Return消息机制处理一些不可路由的消息，咱们的生产者经过指定一个Exchange和Routinkey，把消息送达到某一个队列中去，而后咱们消费者监听队列进行消费处理！在某些状况下，若是咱们在发送消息的时候当Exchange不存在或者指定的路由key路由找不到，这个时候若是咱们须要监听这种不可到达的消息，就要使用Return Listener！

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

消费端自定义监听

消费端限流

什么是消费端的限流？

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

• rabbitMQ提供了一种qos（服务质量保证）的功能，即非自动确认消息的前提下，若是有必定数目的消息（经过consumer或者Channel设置qos）未被确认，不进行新的消费。

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

• prefetchSize:0 单条消息的大小限制。0就是不限制，通常都是不限制。
• prefetchCount: 设置一个固定的值，告诉rabbitMQ不要同时给一个消费者推送多余N个消息，即一旦有N个消息尚未ack，则consumer将block掉，直到有消息ack
• global：truefalse 是否将上面的设置用于channel，也是就是说上面设置的限制是用于channel级别的仍是consumer的级别的。

消费端ack与重回队列

• 消费端进行消费的时候，若是因为业务异常咱们能够进行日志的记录，而后进行补偿！（也能够加上最大努力次数的尝试）
• 若是因为服务器宕机等严重问题，那咱们就须要手动进行ack保证消费端的消费成功！

消息重回队列

• 重回队列就是为了对没有处理成功的消息，把消息从新投递给broker！
• 实际应用中通常都不开启重回队列。

TTL队列/消息

TTL time to live 生存时间。

• 支持消息的过时时间，在消息发送时能够指定。
• 支持队列过时时间，在消息入队列开始计算时间，只要超过了队列的超时时间配置，那么消息就会自动的清除。

死信队列

死信队列：DLX，Dead-Letter-Exchange

利用DLX，当消息在一个队列中变成死信（dead message，就是没有任何消费者消费）以后，他能被从新publish到另外一个Exchange，这个Exchange就是DLX。

消息变为死信的几种状况：

1. 消息被拒绝（basic.reject/basic.nack）同时requeue=false（不重回队列）
2. TTL过时
3. 队列达到最大长度

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

死信队列的设置

• 设置Exchange和Queue，而后进行绑定

  • Exchange: dlx.exchange(自定义的名字)
  • queue: dlx.queue（自定义的名字）
  • routingkey: #（#表示任何routingkey出现死信都会被路由过来）
  • 而后正常的声明交换机、队列、绑定，只是咱们在队列上加上一个参数：arguments.put("x-dead-letter-exchange","dlx.exchange");

rabbitMQ集群模式

1. 主备模式：实现rabbitMQ高可用集群，通常在并发量和数据不大的状况下，这种模式好用简单。又称warren模式。（区别于主从模式，主从模式主节点提供写操做，从节点提供读操做，主备模式从节点不提供任何读写操做，只作备份）若是主节点宕机备份从节点会自动切换成主节点，提供服务。

2. 集群模式：经典方式就是Mirror模式，保证100%数据不丢失，实现起来也是比较简单。

   • 镜像队列，是rabbitMQ数据高可用的解决方案，主要是实现数据同步，通常来讲是由2-3节点实现数据同步，（对于100%消息可靠性解决方案通常是3个节点）

1. 多活模式：这种模式也是实现异地数据复制的主流模式，由于shovel模式配置相对复杂，因此通常来讲实现异地集群都是使用这种双活，多活的模式，这种模式须要依赖rabbitMQ的federation插件，能够实现持续可靠的AMQP数据。rabbitMQ部署架构采用双中心模式（多中心）在两套（或多套）数据中心个部署一套rabbitMQ集群，各中心的rabbitMQ服务须要为提供正常的消息业务外，中心之间还须要实现部分队列消息共享。多活架构以下：

federation插件是一个不须要构建Cluster，而在Brokers之间传输消息的高性能插件，federation能够在brokers或者cluster之间传输消息，链接的双方可使用不一样的users或者virtual host双方也可使用不一样版本的erlang或者rabbitMQ版本。federation插件可使用AMQP协议做为通信协议，能够接受不连续的传输。

Federation Exchanges,能够当作Downstream从Upstream主动拉取消息，但
并非拉取全部消息，必须是在Downstream.上已经明肯定义Bindings关系的
Exchange,也就是有实际的物理Queue来接收消息，才会从Upstream拉取消息
到Downstream。使用AMQP协议实施代理间通讯，Downstream 会将绑定关系
组合在一块儿， 绑定/解除绑定命令将发送到Upstream交换机。所以，Federation
Exchange只接收具备订阅的消息.

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

HAProxy性能为什么这么好？

1. 单进程、事件驱动模型显著下降了.上下文切换的开销及内存占用.
2. 在任何可用的状况下，单缓冲(single buffering)机制能以不复制任何

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

1. 借助于Linux 2.6 (>= 2.6.27.19). 上的splice()系统调用，HAProxy能够实现

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

1. 内存分配器在固定大小的内存池中可实现即时内存分配，这可以显著减小创

建一个会话的时长

1. 树型存储:侧重于使用做者多年前开发的弹性二叉树，实现了以O(log(N))

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

keepAlive

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

keepAlive的做用

1. 管理LVS负载均衡软件
2. 实现LVS集群节点的健康检查中
3. 做为系统网络服务的高可用性(failover)

Keepalived如何实现高可用

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