RabbitMQ（三）RabbitMQ消息过期时间（TTL）
在RabbitMQ（二）AMQP协议mandatory和immediate标志位区别中我们提到，在RabbitMQ3.0以后的版本里，去掉了immediate参数支持，要实现类似的确认功能要使用TTL和DLX。
TTL，Time-To-Live Extensions（过期时间）
RabbitMQ 允许你对 message 和 queue 设置 TTL 值。
Per-Queue Message TTL
通过在 queue.declare 中设置 x-message-ttl 参数，可以控制被 publish 到 queue 中的 message 被丢弃前能够存活的时间。当某个 message 在 queue 留存的时间超过了配置的 TTL 值时，我们说该 message “已死”。值得注意的是，当一个 message 被路由到多个 queue 中时，其可以在不同的时间“死掉”，或者可能有的不会出现“死掉”情况。在某个 queue 中的某个 message 的“死亡”不会对相同 message 在其他 queue 中的生存状况。
服务器会保证“死掉”的 message 将不会被包括在任何的 basic.get-ok 或 basic.deliver 方法中。更进一步，服务器将努力在 TTL 到期或到期后的短时间内处理掉该 message 。
参数 x-message-ttl 的值 必须是非负 32 位整数 (0 <= n <= 2^32-1) ，以毫秒为单位表示 TTL 的值。这样，值 1000 表示存在于 queue 中的当前 message 将最多只存活 1 秒钟，除非其被投递到 consumer 上。实参可以是以下 AMQP 类型：short-short-int 、short-int 、long-int 或者 long-long-int 。
下面的 Java 实例代码创建了一个 queue ，且 message 在该 queue 的存活时间最大为 60 秒： ：
Map<String, Object> args = new HashMap<String, Object>();
args.put("x-message-ttl", 60000);
channel.queueDeclare("myqueue", false, false, false, args);
rabbitmqctl set_policy TTL ".*" '{"message-ttl":60000}' --apply-to queues
还可以通过HTTP接口调用如下：
$ curl -i -u guest:guest -H "content-type:application/json" -XPUT
-d'{"auto_delete":false,"durable":true,"arguments":{"x-message-ttl": 60000}}'
http://localhost:15672/api/queues/{vhost}/{queuename}
当 message 被 requeue 的时候，其原始过期时间将被保留（例如由于设置了 requeue 参数的 AMQP 方法的使用，或者由于 channel 的关闭）。
设置 x-message-ttl 为 0 将使得，在 message 在到达 queue 之后但尚未被立即投递到 consumer 的情况下，判定为过期。这种方式相当于 RabbitMQ server 在3.0.0以后不支持 basic.publish 中 immediate 标识情况下的等价实现。与 immediate 标帜方式不同的是，将不会有 basic.returns 命令的调用，但是在设置了 dead letter exchange 的情况下，这些 message 将被处理为 dead-lettered（详见下面的DLX） 。
Per-Message TTL
在RabbitMQ 3.0.0以后的版本中，TTL 设置可以具体到每一条 message 本身，只要在通过 basic.publish 命令发送 message 时设置 expiration 字段。
expiration 字段以微秒为单位表示 TTL 值。且与 x-message-ttl 具有相同的约束条件。因为 expiration 字段必须为字符串类型，broker 将只会接受以字符串形式表达的数字。
当同时指定了 queue 和 message 的 TTL 值，则两者中较小的那个才会起作用。
下面的 Java 示例 publish 了最多能在 queue 中存活 60 秒的 message ：
byte[] messageBodyBytes = "Hello, world!".getBytes();
AMQP.BasicProperties properties = new AMQP.BasicProperties();
properties.setExpiration("60000");
channel.basicPublish("myexchange", "routingkey", properties, messageBodyBytes);
还可以通过HTTP接口调用如下：
$ curl -i -u guest:guest -H "content-type:application/json" -XPOST
-d'{"properties":{"expiration":"60000"},"routing_key":"routingkey","payload":"my
body","payload_encoding":"string"}'
http://localhost:15672/api/exchanges/{vhost}/{exchangename}/publish
虽然 consumer 从来看不到过期的 message ，但是在过期 message 到达 queue 的头部时确实会被真正的丢弃（或者 dead-lettered ）。当对每一个 queue 设置了 TTL 值时不会产生任何问题，因为过期的 message 总是会出现在 queue 的头部。当对每一条 message 设置了 TTL 时，过期的 message 可能会排队于未过期 message 的后面，直到这些消息被 consume 到或者过期了。在这种情况下，这些过期的 message 使用的资源将不会被释放，且会在 queue 统计信息中被计算进去（例如，queue 中存在的 message 的数量）。
对于第一种设置队列TTL属性的方法，一旦消息过期，就会从队列中抹去，而第二种方法里，即使消息过期，也不会马上从队列中抹去，因为每条消息是否过期时在即将投递到消费者之前判定的，为什么两者得处理方法不一致？因为第一种方法里，队列中已过期的消息肯定在队列头部，RabbitMQ只要定期从队头开始扫描是否有过期消息即可，而第二种方法里，每条消息的过期时间不同，如果要删除所有过期消息，势必要扫描整个队列，所以不如等到此消息即将被消费时再判定是否过期，如果过期，再进行删除。
Queue TTL
queue.declare 命令中的 x-expires 参数控制 queue 被自动删除前可以处于未使用状态的时间。未使用的意思是 queue 上没有任何 consumer ，queue 没有被重新声明，并且在过期时间段内未调用过 basic.get 命令。该方式可用于，例如，RPC-style 的回复 queue ，其中许多 queue 会被创建出来，但是却从未被使用。
服务器会确保在过期时间到达后 queue 被删除，但是不保证删除的动作有多么的及时。在服务器重启后，持久化的 queue 的超时时间将重新计算。
用于表示超期时间的 x-expires 参数值以微秒为单位，并且服从和 x-message-ttl 一样的约束条件，且不能设置为 0 。所以，如果该参数设置为 1000 ，则表示该 queue 如果在 1 秒钟之内未被使用则会被删除。
下面的 Java 示例创建了一个 queue ，其会在 30 分钟不使用的情况下判定为超时。
Map<String, Object> args = new HashMap<String, Object>();
args.put("x-expires", 1800000);
channel.queueDeclare("myqueue", false, false, false, args);
下一篇：RabbitMQ（四）RabbitMQ死信邮箱（DLX）