何时在队列/数据库失败时关闭消息处理？

Question

对于应用程序接收消息，将它们持久保存到数据库以及可能发送消息的常见情况，这是一个最佳实践问题。

• 假设事务性排序原子提交;关于什么时候完全关闭应用程序的好政策是什么？
• 如果数据库失败，应用程序可能会被消息淹没，最终会拒绝该消息。它应该立即放弃吗？
• 如果出站邮件服务失败，数据库将充满回滚。再次，最好立即放弃吗？

在这种情况下，有关如何最好地强制关闭spring应用程序的任何提示的更多布朗尼点，因为默认侦听器包含将捕获任何运行时异常并继续运行。

Answer 1

根据我的理解，您正在寻找以下内容：

1. 不要仅仅因为应用程序无法处理来自入站队列的消息。
2. 如果在处理期间发生错误，何时停止处理。

首先，分析您正在处理的基础设施以及您必须处理的情况非常重要。典型的停机时间以及它们在系统的各个层中出现的频率。网络有多可靠，你是一个rac服务器等等。

1. JMS已经提供了重试机制。如果消息处理失败，请将其发送回队列，直到退休为止。只有在加上延迟时才有意义，这样就不会发生泛滥。如果小延迟不会影响交易，我建议使用延迟消息。根据您的JMS提供程序，支持自定义容器。当无法处理来自入站队列的消息时，使用死信或异常队列可以帮助丢失消息。

2. 再次，你可以成为最好的情况判断。您可以将属性定义为到死信队列的多次连续发送构成关闭条件。您可以在系统测试期间调整它以避免误报。

Answer 2

如破获所有人也提到的，不建议立即放弃。

我认为最好的方法是让其他数据库准备好在主要故障时运行。收到不成功的确认后，您可以将它们路由到次要确认。因此，您不会丢失那么多数据。对于这种情况，您可以在JMS中使用“保证交付”功能。

通过保证传递，消息传递系统使用内置数据存储来保留消息。安装消息传递系统的每台计算机都有自己的数据存储，以便可以在本地存储消息。当发件人发送邮件时，发送操作无法成功完成，直到邮件安全地存储在发件人的数据存储中。随后，消息不会从一个数据存储中删除，直到它成功转发并存储在下一个数据存储中。通过这种方式，一旦发送方成功发送消息，它就会始终存储在至少一台计算机的磁盘上，直到成功传送到接收方并由接收方确认。1