[GitHub] [rocketmq] zergduan edited a comment on issue #3885: Local transaction messages are rollback when slave broker is downtime.

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

zergduan edited a comment on issue #3885:
URL: https://github.com/apache/rocketmq/issues/3885#issuecomment-1050915161


   ShannonDing, 非常感谢您的解答
   
   我同意您的说法：”对于同步复制来说，SLAVE_NOT_AVALIABLE 被定义为消息发布失败“，这点可以通过消息追踪确认（对于sendStatus 为 SLAVE_NOT_AVALIABLE 的消息，消息追踪中标识为 status: failed。
   
   但是我依然有疑问为什么 RocketMQ 对于 status: failed (sendStatus: SLAVE_NOT_AVALIABLE) 的不同消息，处理方法不一致？
   
   我测试了：普通消息（同步发送，异步发送），顺序消息，定时消息，这些消息在 status: failed (sendStatus: SLAVE_NOT_AVALIABLE) 时，都可以被正常消费。 也就是说当生产者收到 status: failed (sendStatus: SLAVE_NOT_AVALIABLE) 并不需要做任何特殊处理，消息依然可以成功消费。
   
   而对事物消息，当 status: failed (sendStatus: SLAVE_NOT_AVALIABLE)发生 时，消息因为被强制Rollback，导致无法从 RMQ_SYS_TRANS_HALF_TOPIC 复制到指定的 Topic 中，所以无法被正常消费。
   
   所以我依然存在以下2个问题：
   
   1. 如果如您所说：”当消费者收到 status: failed (sendStatus: SLAVE_NOT_AVALIABLE) 时，应该自行处理“；那么岂不是要消费者收到 sendStatus: SLAVE_NOT_AVALIABLE时，在针对发送消息的类型（判断是否时事物消息）使用不一样的处理方式？为什么要设计这种不一致的处理方式？（对于不同消息类型，处理方式不一致）
   
   2. 当收到 status: failed (sendStatus: SLAVE_NOT_AVALIABLE) 时，消费者应该做什么样的处理呢？
   我测试了重发消息，结果在 2M-2S 的集群中，当其中1个Slave节点宕机时，消费者重发消息，并不能确保将消息发送到完整的M-S中，而依然会依照负载均衡策略，轮询发送（即有可能多次都发送到Slave宕机的M-S中）。
   
   谢谢


-- 
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