【RabbitMQ学习笔记#5】持久化和策略

2017年8月27日 0 条评论 865 次阅读 0 人点赞

一、持久化消息

默认情况下,重启RabbitMQ服务器后,之前的队列和交换器(随同里面的消息)都会消失。原因在于每个队列和交换器的durable属性,该属性默认情况为false,决定了rabbitMQ是否需要在重启或者崩溃之后重新创建队列(或者交换器)。

持久化消息:能从AMQP服务器中恢复的消息。

二、持久化的实现条件

1、投递模式选项设置为2(持久)。

2、发送到持久化交换器,其durable属性是true的交换器。

3、到达持久化队列,其durable属性是true的队列。

三、持久化实现方式

将持久化消息发送到持久化队列之前,现在磁盘上写入一个人持久化日志文件。如果路由到非持久化队列,将会把该条消息从持久化日志中移除

四、持久化的代价:性能

1、写入磁盘的速度比写入内存慢。

2、极大地减少rabbitMQ服务器每秒可处理地的消息总数。

3、消息吞吐量降低10倍并不少见。

4、持久化消息在rabbitMQ内建集群环境下工作得并不好。由于队列均匀地分布在各个节点而没有冗余(集群中地任何一个队列都没有备份地拷贝),如果运行seed_bin队列地集群节点崩溃了,直到节点恢复之前,这个队列(持久化的)也就从整个集群中消失了。当节点宕机时,其上的队列也都不可用了,持久化队列也无法重建。

五、什么情况下使用持久化消息通信

要保证消息的投递这一关键本质决定了相对于其他类型的消息(例如日志消息)会有更低的吞吐量。

为关键消息使用持久化机制。

可以考虑同时运行非持久化消息通信的传统RabbitMQ集群和持久化消息通信的活动/热备非集群RabbitMQ服务器(负载均衡)。

六、AMQP事务

AMQP事务确认和保证消息的投递。

在AMQP中,把信道设置成事务模式后,通过信道发送发送那些想要确认的消息,之后还有多个其他AMQP命令,这些命令是执行还是忽略取决于第一条消息是否发送成功。

事务的缺点:几乎吸干了rabbit性能,降低大约2--10倍的消息吞吐量,会使生产者应用程序产生同步。====>使用消息通信是为了避免同步。

RabbitMQ团队给出的方案,保证消息投递:发送方确认模式

发送方确认模式是异步的。

1、将信道设置成confirm模式<===只能通过重新创建信道来关闭该设置。

2、该模式下,信道上的所有消息都会被指派一个唯一的ID号(从1开始)。

3、消息投递给匹配队列之后,信道会发送一个发送方确认模式给生产者应用程序(包括消息的唯一ID)。===>如果队列和消息都是持久化的,确认消息只会在队列把消息写入磁盘之后才会发出。

4、生产者应用在等待确认的同时继续发送下一条

5、确认消息最终收到的时候,生产者应用的回掉方法就会被触发来处理该确认消息。

Note:如果rabbit发生内部错误从而导致消息的丢失,rabbit会发送一条nack(not acknowledged,未确认)消息。

 

realks

这个人太懒什么东西都没留下

文章评论(0)