本文为原创文章，转载请注明出处
在之前的文章 Apache Pulsar 之 TTL 与 Retention 策略 中提到过 "死信队列"，它与 TTL 策略有一个共同点，就是可以将 consumer 未确认的消息转变到确认的状态，但是二者的处理方式又有所不同，这篇文章，将和大家探讨一下，Pulsar 中 “死信队列” 是如何工作的。
在任何一个分布式系统中，都没有办法保证不出错，系统能提供的是，当你遇到错误时，如何更好的提供保障机制，“死信队列” 就是这样的一个存在，由于某些原因消息无法被正确的投递，为了确保消息不会被无故的丢弃，一般将其置于一个特殊角色的队列，这个队列一般称之为死信队列。
在 Pulsar 中，提供了一个 DeadLetterPolicy 用来实现 “死信队列”，具体如下：
public class DeadLetterPolicy {
private int maxRedeliverCount;
private String deadLetterTopic;
}
它包含了两个参数 maxRedeliverCount 和 deadLetterTopic 。
- maxRedeliverCount
当 consumer 端消费消息出错时，默认情况下，某些消息会尽可能多次重新发送，甚至可能永远不会停止。为了避免这种情况发生，DeadLetterPolicy 提供了一个参数 maxRedeliverCount 来覆盖此行为。用户可以自己设置，在消息出错时，我将最多继续尝试发送多少次，如果达到用户设置的最大值，消息还没有成功发送，此时 Pulsar 会将消息推送到 “死信队列” 中。
注意：此时该条 message 会从未确认转换为已确认的状态
- deadLetterTopic
这个参数提供给用户来设置 “死信队列” 的名字，其本质是一个 topic 的 name。默认情况下，“死信队列” 的 topic name 形如：{TopicName}-{Subscription}-DLQ。
对于一条消息来说，只有当 consumer 接收并确认这条消息，才算完成消费动作。同样，Pulsar 也给用户提供了消息确认的接口：Ack 。但有些情况下，可能由于网络抖动，consumer 暂时性的故障等，导致 ack 的时间理论上会无限长。这种情况同样可能在 “死信队列” 中发生，如果用户在启动 consumer 时，并没有设置 ack timeout（默认不开启，这就意味着，除非当前的 consumer crash 掉，否则消息将永远不会再次被投递到 consuemr），那么 maxRedeliverCount 中提到的消息最大投递次数，其实并没有生效。为了避免这种情况发生，Pulsar 提供了另一个消息确认的接口：AckTimeout 即可以让用户自己设定 timeout 的时间为多长。如果用户没有设定 timeout 的时长，在 “死信队列” 中，该时长将被自动设置为：30s，来确保 “死信队列” 能够正常工作。
下面是一个使用示例，供大家参考：
Consumer<byte[]> consumer = pulsarClient.newConsumer(Schema.BYTES)
.topic(topic)
.subscriptionName("my-subscription")
.subscriptionType(SubscriptionType.Shared)
.ackTimeout(3, TimeUnit.SECONDS)
.receiverQueueSize(100)
.deadLetterPolicy(DeadLetterPolicy.builder() //启用死信队列功能
.maxRedeliverCount(maxRedeliveryCount)//在进入死信队列之前，消息最多被重新投递的最大次数
.deadLetterTopic("persistent://my-property/my-ns/dead-letter-custom-topic-my-subscription-custom-DLQ")// 死信队列的topic name
.build())
.subscriptionInitialPosition(SubscriptionInitialPosition.Earliest)
.subscribe();
当消息进入 “死信队列” 后，用户可以根据自己的需求，对消息做相应的处理。
nack VS ackTimeout
上面提到，在消息进入 “死信队列” 之前，用户可以设置该消息将继续被重新投递多少次，但是每次投递的时长，由 ack timeout 来控制。在很多情况下，对于特定消息的出错情况，应用程序很难自己做处理，pulsar 目前提供了以下方式来供用户选择：
- ackTimeout
如果消息被正常投递到应用程序，但是在 timeout 的时间内，并没有收到 ack，此时将会触发重新传递消息。ackTimeout 的主要问题在于它和应用程序是强绑定的。在大多数情况下，1 分钟的 ack timeout 是一个非常好的值，但如果处理平均需要3分钟，则会多次触发每条消息的重新发送...因此，默认情况下无法启用 ack-timeout。
- 手动处理
阻塞当前消费，做重试的处理。这种方式可能存在的问题如下：
- 可能只有一条消息失败（可能是临时的），而其余的消息都很好。在这种情况下，需要阻塞 consumer 来处理所有消息，直到这个出错的消息通过。
- 可能只是其中一个 consumer 出现故障，其它 consumer 处于正常状态。
- Nack
基于上述场景，相对理想的情况是当消息出错需要处理时，用户可以将该条消息 nack 掉，并触发重传机制。所以在启用 死信队列 的功能之后，用户可以通过 ack-timeout 或者 nack 两种方式来将消息路由到 “死信队列” 中。nack 和 ack-timeout 的重传机制是一样的，二者可以结合使用，需要注意的是，nack 的操作需要发生在 ack-timeout 之前。
note: 目前 “死信队列” 只支持了 shared 的订阅类型，当前版本：2.3.1
