100%消息投递方案质疑
来源：3-3 消息如何保障 100% 的投递成功方案-2
mongo_m
2018-10-13
忍不住说一下我对课程的感受。我觉得只能称作rabbitmq入门。
我觉得深度不够。而且条理性比不上《rabbitmq实战》这本书。
对于100%消息投递方案一：
也就是“消息数据落库加定时任务轮询中间状态的数据”方案，这个方案我非常不认同。这个方案在免费课程里面讲一讲开阔思路或者练练编码熟练度还可以。在实战课程里面提及，会让我们受到误导。
在《rabbitmq实战》一书中有这样的一段话：
如果持久性通信能够满足性能需求的话，那么使用这种机制确保消息投递是极佳的方式。
所以，这样看的话，这个落库加轮询的方式，纯粹画蛇添足。
对于方案二，我怎么感觉这个不是消息100%投递保障方案，而是一种消息100%被正确处理保障方案。
我怎么感觉老师有种不专业的感觉？心里好害怕。难道我走火入魔了？
3回答
-
感谢小伙伴的提问，这门课程主要也是从基础开始一步步进行讲解的，目的是尽量简单全面的覆盖到关键点。
至于说对可靠性消息投递方案一的质疑，可能每个人的理解会有偏差和不同，方案二主要目的也是为了保证消息能够投递成功，或者说消息能够消费得到，这个我觉得是一个意思哈，欢迎相互学习交流，只能帮到你这里啦，相互学习进步，感谢小伙伴支持012018-10-13 -
阿神
2018-10-13
至于您说的画蛇添足部分，我了解到的大型互联网公司基础架构封装，都是类似采取这种策略去做可靠性投递的。可能也会有更好的方式，但是还是感谢小伙伴提问
182018-10-14 -
阿神
2018-10-13
首先您说的第一个画蛇添足部分，当网络发生闪断的时候，如果消息的生产者没有收到确认投递响应，我们不做定时任务应该如何去做呢。？难道不去处理这条消息么？
第二点画蛇添足部分，当消费成功后，做ack签收是表示consumer的动作，broker收到ack后确实会进行标识消息已经处理，如果没有收到ack，那么我们的做法是进入死信队列补偿处理。当然，如果消费端已经ack，对于消端而言我们就认为消息已经成功处理啦，感谢提问，相互交流，??022018-10-14
相似问题