1、如果某条消息 卡在 ack 机制中 ,下游消费者一直报错 。其他消息是会正常被消费掉,如果此时broker 宕机 那么重启后的broker 是不是 将会重新根据卡ack 机制的offSet 将 offSet后面的全部消息重新消费一遍?
2、能理解事物消息上游发送者的逻辑,但如果下游消费者 一直消费不成功,消息进入死信队列,那么一致性也是不可能保证的 。最终靠人肉运维最终一致性?
3、关于通用幂等的逻辑 见代码如下:
try {
//业务唯一标识幂等
Boolean add = redisApi.addNX(UUID));
if(!add){
logger.error(new Date() + " 消息重复消费.");
//返回消息消费成功
return OrderAction.Success;
}
//消费
toService(msg);
logger.info(new Date() + " 正常消费成功“);
return OrderAction.Success;
} catch (Exception e) {
redisApi.del(UUID);
logger.error("消费失败重试",e);
return OrderAction.Suspend;
}
这样有个问题 确实重复消费时ack 返回确认消费不消费。消费过程中 出现异常 catch住后redis删除 重试可以正常消费,但如果消费过程中 jvm 爆了 下次ack 超时重试的时候 redis里面是有值的 会被认为重复的消息 而实际消费没有成功不会再消费