RabbitMQ(三):消息持久化策略

一、前言

  在正常的服务器运行过程中,时常会面临服务器宕机重启的情况,那么我们的消息此时会如何呢?很不幸的事情就是,我们的消息可能会消失,这肯定不是我们希望见到的结果。所以我们希望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,需要全部重新提交。

五、小结

  消息持久化的策略大致就是以上几种,我们可以根据自己的实际需求来选择相应的策略。如果有问题欢迎指出!

posted @ 2018-11-30 20:18  树杈  阅读(...)  评论(...编辑  收藏