Erlang死信队列答案

【问题标题】：Erlang dead letter queueErlang死信队列
【发布时间】：2015-11-03 19:01:20
【问题描述】：

假设我的 Erlang 应用程序从外部接收到一条重要消息（例如，通过公开的 API 端点）。由于应用程序中的错误或格式不正确的消息，处理消息的进程崩溃。

消息会发生什么？我如何影响消息的处理方式？进程邮箱中等待的其他消息会发生什么？我是否必须引入进程层次结构以确保没有消息丢失？

在 Erlang 中是否有类似 Akka 的死信队列的东西？假设我想稍后处理消息 - 通过修复消息或修复应用程序本身的错误，然后重新运行消息处理。

我很惊讶关于这个主题的信息如此之少。

【问题讨论】：

每种语言在某种程度上都有自己的范式，你可以在其中工作，也可以反对它。在您需要的时候拥有高性能的低保证设施是很好的，如果您想要更多，在 Erlangs 案例中 OTP 可能会提供您需要的大部分功能。

标签： erlang

【解决方案1】：

没有信息，因为没有死信队列，如果您的应用程序在处理您的消息时崩溃，则该消息已经收到，为什么它会进入死信队列（如果存在的话）。

这样的队列将是一个主要的可扩展性问题，用处不大（您会收到无法发送且完全脱离上下文的任意消息）

如果您需要确保消息得到处理，您通常会使用一种方法在消息被处理时得到回复，例如 gen_server 调用。

如果您的消息非常重要，如果丢失将是一场灾难，您可能应该将其保存在外部数据库中，否则如果您的计算机崩溃，传输中的所有消息会发生什么情况？

【讨论】：

这意味着对于问题中提到的用例，Erlang 应用程序可以而且应该与外部消息传递系统（例如 RabbitMQ）相结合。
@GaborKulcsar 不一定。它取决于整个系统（包括客户端、中间体和服务器）的架构/概念。通常，进行处理的服务并不是决定它有多重要的服务——那是中介或客户的关注点。 RabbitMQ 可能是这样的中介，但在任何情况下都说“它可以而且应该结合”是一种过分的做法，一条消息可能对我来说很重要。大多数情况下，对序列化或幂等消息进行客户端重试就足够了。
有点像UDP vs TCP； TCP 被认为是可靠的，而 UDP 则不是，但如果 UDP 足够，那么它将是一个更有效的工具。课程用马。
@GaborKulcsar 值得注意的是，RabbitMQ 是用 Erlang 编写的。 :-)