一、前言
在正常的服务器运行过程中,时常会面临服务器宕机重启的情况,那么我们的消息此时会如何呢?很不幸的事情就是,我们的消息可能会消失,这肯定不是我们希望见到的结果。所以我们希望AMQP服务器崩溃了也可以将消息恢复,这称之为消息持久化。RabbitMQ自然存在这种策略可以帮助我们完成这件事情。
二、持久化的消息
当RabbitMQ服务器重启后,原先的队列和交换器会随同里面的消息一同消失。原因在于每个队列和交换器都有durable属性,该属性默认是false,它决定了RabbitMQ是否需要在崩溃或者重启之后重新创建队列或者交换器。将它设置为true就代表了持久性,在服务器重启之后就会重新持久的创建队列和交换器。
当然做到这点还不够,我们需要的是持久化的消息,所以在消息发布前,通过将消息的“投递模式”(delivery mode)属性设置为2将消息标记为持久化。到目前为止,消息还只是被表示为持久化,还需要被发布到持久化的交换器中并到达持久化的队列中才行。如果不是这样,包含持久化消息的队列或者交换器挥着Rabbit崩溃重启后不复存在,导致消息成为一个孤儿。因此,总结起来需要做到以下三点:
(1)将消息的投递模式选项设置为2(持久);
(2)将消息发送到持久化的交换器;
(3)消息到达持久化的队列。
注意,如果原先有非持久的交换器或者队列,需要删除后才可重新创建,否则就创建其他名称的交换器或者队列,代码如下:
//声明持久交换器 channel.ExchangeDeclare( "HelloExchange", //交换器名称 ExchangeType.Direct,//交换器类型 true, //是否持久话 false, //是否自动删除 null //关于交换器的详细设置,键值对形式 ); //声明持久队列 channel.QueueDeclare( "HelloQueue",//队列名称 true, //是否持久化 false, //是否只对首次声明的队列可见 false, //是否自动删除 null ////关于队列和队列内消息的详细设置,键值对形式 ); //发布持久消息 string msg_str = "这是生产者第一次发布的消息"; IBasicProperties msg_pro = channel.CreateBasicProperties(); msg_pro.ContentType = "text/plain";//发布的数据类型 msg_pro.DeliveryMode = 2;//标记持久化
三、事务
目前为止,我们已经将消息、队列和交换器设置为持久化。但是事实上还存在着'最后一英里'的距离,就是在把消息写入磁盘前,消息由于服务器宕机而消失该如何?这时候就需要使用到事务,说到事务就会想到SQL中的事务,但是不能搞混了。AMQP中,在把信道设置为事务模式后,通过信道发送消息后还有多个其他的AMQP命令,这些命令是执行还是忽略,取决于消息的发送是否成功,消息发送成功信道会在事务中完成其他AMQP命令,就可以提交事务了,发送失败则其他AMQP命令将不会执行,我们也会知道发送失败,而采取相应的措施。事务保证了解决这最后的问题。
代码如下:
using (IConnection conn = conn_factory.CreateConnection()) { //2.创建信道 using (IModel channel = conn.CreateModel()) { try { channel.TxSelect();//声明事务 //3.发布消息 string msg_str = "这是生产者发布的消息"; IBasicProperties msg_pro = channel.CreateBasicProperties(); msg_pro.ContentType = "text/plain";//发布的数据类型 msg_pro.DeliveryMode = 2; channel.BasicPublish( "HelloExchange", //消息发送目标交换器名称 "hola", //路由键 msg_pro, //消息的发布属性 Encoding.UTF8.GetBytes(msg_str) //消息 ); channel.TxCommit();//提交事务 } catch(Exception ex) { channel.TxRollback();//回滚事务 } } }
四、发送方确认模式
虽然通过事务和持久化的消息、队列和交换器可以确保消息不会丢失,但是对消息的吞吐量有着非常严重的影响,而且使用消息通信就是为了避免同步,可是事务却会导致生产者程序产生同步。所以,有一个更好的方法保证消息投递:发送方确认模式。和事务类似,我们需要将信道channel设置为confirm模式,而且只能通过重新创建信道来关闭该设置。一旦信道进入confirm模式,所有的信道上发布的消息都会被指派一个唯一的ID。当消息被投递到队列后,信道就会发送一个发送方确认模式给生产者程序,使得生产者知道消息安全到达队列了。
发送发确认模式最大的好处是它们是异步的,没有回滚的概念,更加轻量级,对性能的影响也几乎忽略不计。
代码如下:
channel.ConfirmSelect();//开启发送确认模式 //3.发布消息 IBasicProperties msg_pro = channel.CreateBasicProperties(); msg_pro.ContentType = "text/plain";//发布的数据类型 msg_pro.DeliveryMode = 2; for(int i = 0; i < 5; i++) { string msg_str = string.Format("这是生产者发布的消息{0}", i); channel.BasicPublish( "HelloExchange", //消息发送目标交换器名称 "hola", //路由键 msg_pro, //消息的发布属性 Encoding.UTF8.GetBytes(msg_str) //消息 ); if (channel.WaitForConfirms()) Console.WriteLine(i); else Console.WriteLine("发送失败"); }
可以看到channel.WaitForConfirms()方法是同步的,这样的话效率会低一点,我们可以发送完所有的消息,然后用channel.WaitForConfirmsOrDie()一次性提交,如果中途有一个消息提交失败或者超时,就会报错Exception,需要全部重新提交。
五、小结
消息持久化的策略大致就是以上几种,我们可以根据自己的实际需求来选择相应的策略。如果有问题欢迎指出!