正告
此模块以后被标记为可能会更改，因为它是一项新性能，须要依据理论应用反馈的状况确定最终 API。这意味着 API 或语义能够更改，而不会收回正告或弃用期限。还不建议您在生产中立刻应用此模块。

模块信息

要应用牢靠的交付，请将模块增加到您的我的项目中：

介绍

失常的消息传递可靠性最多只能传递一次，这意味着音讯可能会失落。那应该很少见，但依然可能。

对于某些 actors 之间的交互，这是不可承受的，并且须要至多一次交付或无效一次解决。此处介绍的牢靠交付工具有助于实现这一指标。没有应用程序的合作，它不可能在幕后主动实现。这是因为确认音讯何时已被齐全解决是业务级别的问题。仅确保将其通过网络传输或传递到参与者的邮箱是不够的，因为参与者可能在解决音讯之前就解体了。

依据须要检测，从新发送和删除反复邮件。此外，它还包含用于音讯发送的流控制，以防止疾速生产者吞没较慢的用户或以比能够通过网络传输的音讯更高的速率发送音讯。这可能是参与者之间交互中的常见问题，会导致致命谬误，例如 OutOfMemoryError，因为参与者的邮箱中排队的邮件过多。失落音讯的检测和流控制是由用户方驱动的，这意味着生产方方的发送速度不会快于用户方的要求。除非消费者方要求，否则生产者方不会推送重发。

有 3 种受反对的模式，以下各节中进行了介绍：

点对点
工作拉
分片