[GitHub] [rocketmq] caigy commented on a diff in pull request #4146: [ISSUE #4145] docs: Add 'at most once' feature in the feature documents.

[GitBox <gi...@apache.org>]

caigy commented on code in PR #4146:
URL: https://github.com/apache/rocketmq/pull/4146#discussion_r867303295


##########
docs/cn/features.md:
##########
@@ -27,15 +27,22 @@ RocketMQ支持消息的高可靠，影响消息可靠性的几种情况：
 
 5)、6)属于单点故障，且无法恢复，一旦发生，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，例如与Money相关的应用。注：RocketMQ从3.0版本开始支持同步双写。
 
-## 5 至少一次
-至少一次(At least Once)指每个消息必须投递一次。Consumer先Pull消息到本地，消费完成后，才向服务器返回ack，如果没有消费一定不会ack消息，所以RocketMQ可以很好的支持此特性。
+## 5 至少一次(At Least Once)
+- 生产端：当消息发送给 Master Broker 后,如果同步给 Slave Broker 出现超时等异常(不限于这种情况,还有 Broker 收到消息后，发送响应(Ack)信息给 Producer 出现网络异常等)时，消息在重试机制中，可能会被重复发送。
+- 消费端：Consumer先Pull消息到本地，消费完成后，才向服务器返回ack，如果没有消费一定不会ack消息，所以 RocketMQ 可以很好的支持此特性。
 
-## 6 回溯消费
+## 6 至多一次(At Most Once)
+- 生产端：Producer 的 `sendOneway` 方法，将消息发送给目标 `MessageQueue` 后，忽略 Broker 对发送结果的反馈，也不会有任何重试机制，所以单条消息的发送，可能会失败。
+
+## 7 严格一次(Exactly Once)
+RocketMQ 不支持消息严格传输一次的特性。

Review Comment:
   Could you provide tips about how to handle duplicate messages? It would be more valuable to users.



##########
docs/cn/features.md:
##########
@@ -27,15 +27,22 @@ RocketMQ支持消息的高可靠，影响消息可靠性的几种情况：
 
 5)、6)属于单点故障，且无法恢复，一旦发生，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，例如与Money相关的应用。注：RocketMQ从3.0版本开始支持同步双写。
 
-## 5 至少一次
-至少一次(At least Once)指每个消息必须投递一次。Consumer先Pull消息到本地，消费完成后，才向服务器返回ack，如果没有消费一定不会ack消息，所以RocketMQ可以很好的支持此特性。
+## 5 至少一次(At Least Once)
+- 生产端：当消息发送给 Master Broker 后,如果同步给 Slave Broker 出现超时等异常(不限于这种情况,还有 Broker 收到消息后，发送响应(Ack)信息给 Producer 出现网络异常等)时，消息在重试机制中，可能会被重复发送。
+- 消费端：Consumer先Pull消息到本地，消费完成后，才向服务器返回ack，如果没有消费一定不会ack消息，所以 RocketMQ 可以很好的支持此特性。
 
-## 6 回溯消费
+## 6 至多一次(At Most Once)
+- 生产端：Producer 的 `sendOneway` 方法，将消息发送给目标 `MessageQueue` 后，忽略 Broker 对发送结果的反馈，也不会有任何重试机制，所以单条消息的发送，可能会失败。

Review Comment:
   IMO **at-most-once delivery** means that message is **guaranteed** to be  delivered once or never to be delivered. In other words, any message won't to be delivered more than once.  You may refer to [akka doc](https://doc.akka.io/docs/akka/current/general/message-delivery-reliability.html?language=scala#discussion-what-does-at-most-once-mean-) or documents of other MQs for details.
   It seems that it is not rigorous **at-most-once delivery** here, but just providing a mechanism for producer approaching to (but is not exactly) at-most-once delivery. 
   Should it be more suitable as supplement to part 5 instead of an independent part describing at-most-once delivery?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org