关于mq消息丢失问题讨论

网友1：
第一 MQ的特性决定了它在生产方发送数据并不能保证消息一定送到。原因很简单，生产者发送到broker后当次通讯就结束了，broker并不会返回消息是否被消费端正确接收。MQ这种协议天然的就是单方向的，即A产生者只需要发送消息给broker并不需要在意有几个消费端订阅消息，而消费端订阅消息并不清楚是第几次推送过来的消息以及哪个生产者生产的消息，消费消息的客户端和生产消息的客户端并不会直接联系，这才是MQ的最基础也是最核心的点。而up连这都不说明的情况下谈什么保证消息送达的及时性和准确性是否太搞笑。
第二 消费者和生产者是互不关心的，只有一个例外情况就是生产者意外下线或数据服务不可提供时，broker会发出当前生产者第一次connect时的will Message通知各订阅者作出相对应准备。
第三 很多人对QoS的理解是有问题，QoS保证的对象是服务端推送消息时能有几种不同的行为级别。而不是生产者与broker之间，QoS是保证的消息正确推送而不能保证消息发送失败时的重试更不谈什么重复消费了。
连最基础的东西都不清楚，谈MQ别搞笑了，你也就知道kafka/Zookeeper、rocketMQ这种要知道MQ早在二十年前的2000年初在生产订单系统中非常流行了。而现在一些自以为是的小白居然把MQ仅仅只是异步解耦的工具，保证发明MQ的先辈不打你们出屎来。

一，ack，不丢失

broker ack

原因：

1.服务宕机/磁盘坏 ->集群别单机

2.异步，考虑性能与可靠性

消费者 ack

业务逻辑处理完成后，返回ack

二，重复消费

原因：

如果业务处理完成，未发送ack，broker重发

解决幂等方案：

1.消息日志标，消费记录，异步更新

2.redis

三，消息积压

单节点10万处理量，性能可以

原因：消费端

方案：扩容，增强消费能力

优化处理逻辑

思考过程很重要