跳到主要内容

保证消息确认

保证消息的传递是通过ACK（确认）和NACK（未确认）来实现的。这样，生产者可以从代理那里接收到确认，表示代理已经接收并接受了消息，而消费者则向事件代理发送确认，告诉它他们已经接收并完成了消息的处理。

生产者​

当应用程序发送保证消息时，API代表应用程序将消息传递给事件代理。如果API在可配置的超时内没有收到消息的确认，API会重新传输消息。这不会导致重复消息，因为事件代理确保重复传输的消息不会重复。

超时时间可以作为API属性进行配置。例如，在Java API（JCSMP）中，它通过JCSMPProperties类的PUB_ACK_TIME属性设置，默认为2000毫秒或2秒。大多数应用程序使用默认设置。

当接收保证消息时，事件代理在以下情况中首先发生时向生产者发送ACK：

  • 事件代理接收到1/3窗口值的消息后。
  • 自上次接收未确认消息以来已经过去了1秒。

1/3和1秒的设置不可配置。

请注意，从代理发送到生产者的ACK是累积的，可以确认多条消息。然而，API在每个消息的基础上通知应用程序消息已被确认。

一些API允许发布应用程序请求立即确认消息。在这种情况下，事件代理在接收并处理消息后立即发送ACK。例如，在Java API（JCSMP）中，消息类有setAckImmediately()方法，它接受一个布尔参数，默认设置为false。

消费者​

从队列或主题端点向消费者传递保证消息有两种不同类型的确认：应用程序确认（Application ACKs）和传输确认（Transport ACKs）。

应用程序确认告诉事件代理应用程序已完成消息处理，可以将其从队列或主题端点中移除。API作为保证消息协议的一部分发送传输确认，该协议将消息从事件代理传递到API。然后，API将消息传递给应用程序。

应用程序确认​

API在以下情况下发送应用程序确认：

  • 应用程序调用API的方法来确认消息。
  • 如果应用程序使用自动确认，则消息回调返回。

一旦事件代理将消息传递给消费者，它会无限期地等待消费者的应用程序确认，只要消费者保持连接。只有在客户端断开连接或消费者（在某些API中也称为流程）在应用程序未确认消息的情况下关闭时，消息才会重新传递。

传输确认​

API在以下情况中首先发生时发送传输确认：

  • 消费者或流程接收到可配置百分比的窗口值的消息。
  • 自消息接收以来已过去了可配置的时间量。

请注意，传输确认是累积的，可以确认多条消息。

窗口的百分比可以作为API属性进行配置。例如，在Java API（JCSMP）中，它通过JCSMPProperties类的SUB_ACK_WINDOW_THRESHOLD属性设置，默认为60%。超时时间也是可配置的。例如，在Java API（JCSMP）中，它通过JCSMPProperties类的SUB_ACK_TIME属性设置，默认为1秒。因此，通过默认设置，Java API（JCSMP）在以下情况下发送传输确认：

  • 流程接收到60%窗口值的消息。
  • 自消息接收以来已经过去了1秒。

再次强调，传输确认仅告诉事件代理API已接收消息以传递给应用程序。接收到传输确认不会导致事件代理从队列或主题端点中移除消息。这只有在应用程序通过应用程序确认消息时才会发生。

当向消费者发送保证消息时，事件代理在重新传输消息给消费API之前等待2秒的传输确认。重新传输不会导致重复消息，因为API确保重复传输的消息不会重复，并且不会将它们传递给应用程序。2秒的超时时间不可配置。