如果队列/数据库出现故障，何时关闭消息处理？
对于应用程序接收消息、将其保存到数据库并可能因此发送消息的常见情况，这更像是一个最佳实践问题。
- 假设事务性排序原子提交；关于何时完全关闭应用程序的好策略是什么？
- 如果数据库发生故障，应用程序可能会被消息淹没，最终会拒绝这些消息。是不是应该立即放弃呢？
- 如果出站消息服务失败，数据库将充满回滚。再说一遍，是不是最好立即放弃？
在这种情况下，有关如何最好地强制 Spring 应用程序关闭的任何提示的更多奖励点，因为默认侦听器包含将捕获任何运行时异常并继续运行。
This is more of a best practice question for the common case of an application receiving messages, persisting them to a database, and possibly sending messages as a result.
- Assume transactionality sorts out atomic commit; what is a good policy on when to shut the application down altogether?
- If the database fails, the application could get flooded by messages, which it will end up rejecting. Should it give up immediately?
- If the outbound messaging service fails, the database will be flooded with rollbacks. Again, is it best to give up immediately?
More brownie points for any hints on how to best force a spring app to shut down in this case, as the default listener contain will catch any runtime exception and keep running.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
据我了解，您正在寻找以下内容：
首先，分析您正在处理的基础设施以及您必须处理的情况类型非常重要。典型的停机时间以及它们在系统各层发生的频率。网络的可靠性如何，您是否使用 rac 服务器等。
JMS 已经提供了重试机制。如果消息处理失败，则将其发送回队列，直到退休到期。只有与延迟相结合才能避免发生洪水，这才有意义。如果小的延迟不会影响交易，我建议使用有延迟的消息。根据您的 JMS 提供商，这是支持自定义容器的。当入站队列中的消息无法处理时，使用死信或异常队列有助于防止消息丢失。
再说一次，你可以成为情况的最佳判断者。您可以将属性定义为有多少次连续发送到死信队列构成关闭条件。您可以在系统测试期间对其进行调整以避免误报。
From what I understand you're looking for following:
First of all it's important to analyze the infrastructure you're dealing with and the kind of situations you'll have to deal with. Typical down times and how often they occur in various tiers of the system. How reliable is the network, is you db a rac server etc.
JMS already provides for mechanisms of retry. If message processing fails, send it back to queue until retires expire. This makes sense only if coupled with a delay so that flooding doesn't occur. If a small delay will not affect the transaction, I would recommend using messages with a delay. depending on your JMS provider, this is supported custom to container. Using a dead letter or exception queue when message from inbound queue cannot be processed can help with loss of messages.
Again, you can be the best judge of situation. You can define a property as how many many consecutive sends to dead letter queue constitute a shut down condition. You can tweak it during your system test to avoid false positives.
正如cracked_all也提到的，不建议立即放弃。
我认为最好的方法是让其他数据库在主数据库发生故障时准备好运行。收到不成功的确认后，您可以将它们路由到辅助确认。因此，您不会丢失那么多数据。对于这种情况，您可以使用 JMS 中的“保证交付”功能。
通过保证交付，消息传递系统使用内置数据存储来保存消息。安装消息系统的每台计算机都有自己的数据存储，以便可以在本地存储消息。当发送者发送消息时，只有在消息安全地存储在发送者的数据存储中时，发送操作才能成功完成。随后，消息不会从一个数据存储中删除，直到它成功转发到并存储在下一个数据存储中。这样，一旦发送者成功发送消息，该消息将始终存储在至少一台计算机上的磁盘上，直到成功传递给接收者并被接收者确认。1
As cracked_all also mentioned, it is not recommended to give up immediately.
I think the best way would be to have other databases ready to function as the primary fails. Upon receiving unsuccessful acknowledgment, you can route them to the secondary one. Therefore, you don't lose that much of data. For this case, you can use "Guaranteed Delivery" feature in JMS.
With Guaranteed Delivery, the messaging system uses a built-in data store to persist messages. Each computer the messaging system is installed on has its own data store so that the messages can be stored locally. When the sender sends a message, the send operation does not complete successfully until the message is safely stored in the sender’s data store. Subsequently, the message is not deleted from one data store until it is successfully forwarded to and stored in the next data store. In this way, once the sender successfully sends the message, it is always stored on disk on at least one computer until is successfully delivered to and acknowledged by the receiver.1