100%消息投递方案质疑

Question

忍不住说一下我对课程的感受。我觉得只能称作rabbitmq入门。
我觉得深度不够。而且条理性比不上《rabbitmq实战》这本书。

对于100%消息投递方案一：
也就是“消息数据落库加定时任务轮询中间状态的数据”方案，这个方案我非常不认同。这个方案在免费课程里面讲一讲开阔思路或者练练编码熟练度还可以。在实战课程里面提及，会让我们受到误导。

在《rabbitmq实战》一书中有这样的一段话：

如果持久性通信能够满足性能需求的话，那么使用这种机制确保消息投递是极佳的方式。

所以，这样看的话，这个落库加轮询的方式，纯粹画蛇添足。

对于方案二，我怎么感觉这个不是消息100%投递保障方案，而是一种消息100%被正确处理保障方案。

我怎么感觉老师有种不专业的感觉？心里好害怕。难道我走火入魔了？

Answer 1

阿神 2018-10-13 23:39:39

感谢小伙伴的提问，这门课程主要也是从基础开始一步步进行讲解的，目的是尽量简单全面的覆盖到关键点。
至于说对可靠性消息投递方案一的质疑，可能每个人的理解会有偏差和不同，方案二主要目的也是为了保证消息能够投递成功，或者说消息能够消费得到，这个我觉得是一个意思哈，欢迎相互学习交流，只能帮到你这里啦，相互学习进步，感谢小伙伴支持

• 提问者 mongo_m #1

  非常感谢！

Answer 2

阿神 2018-10-13 23:42:19

至于您说的画蛇添足部分，我了解到的大型互联网公司基础架构封装，都是类似采取这种策略去做可靠性投递的。可能也会有更好的方式，但是还是感谢小伙伴提问

• 提问者 mongo_m #1

  各个方案的具体的表现，只能通过实际测试以及生产环境中的表现来断定了。谢谢老师对我的反对意见的包容。感谢老师！

• 阿神 回复 提问者 mongo_m #2

  嗯，相互交流很重要，是一起进步学习的过程，谢谢支持

• 阿神 回复 提问者 mongo_m #3

  另外有些时候，做架构设计要懂得取舍，有些地方需要钻牛角尖，有些地方不要钻牛角尖，其实钻与不钻这个很难去判断和界定。我个人理解的标准就是，比如mq生产端投递消息，我们一定要保证可靠性投递，也就是100%消息不丢失。这个点也是我理解需要钻牛角尖的点。至于不钻牛角尖，就比如刚才在您画图里提到的，如果消费端ack应答给broker后，我们才算消息投递成功的话，那是针对于broker而言的，如果这种情况发生情况下，我们设置队列一个消息过期时长，一直没处理，或者说没有收到consumer回送的ack的话，则采用死信队列去兜底。所以我说只有consumer ack了，就认为消息已经消费结束，且处理完毕啦。

点开查看后面5条评论

Answer 3

阿神 2018-10-13 23:50:48

首先您说的第一个画蛇添足部分，当网络发生闪断的时候，如果消息的生产者没有收到确认投递响应，我们不做定时任务应该如何去做呢。？难道不去处理这条消息么？
第二点画蛇添足部分，当消费成功后，做ack签收是表示consumer的动作，broker收到ack后确实会进行标识消息已经处理，如果没有收到ack，那么我们的做法是进入死信队列补偿处理。当然，如果消费端已经ack，对于消端而言我们就认为消息已经成功处理啦，感谢提问，相互交流，??

• 提问者 mongo_m #1

  老实说，老师您的这些提问，我要继续多学点才敢再来回答。

• 阿神 回复 提问者 mongo_m #2

  嗯，有疑问就是学习最好的动力，加油(ง •̀_•́)ง