消息队列的应用场景总结详解编程语言

小红是小明的姐姐。 
小红希望小明多读书，常寻找好书给小明看，之前的方式是这样：小红问小明什么时候有空，把书给小明送去，并亲眼监督小明读完书才走。久而久之，两人都觉得麻烦。 
后来的方式改成了：小红对小明说「我放到书架上的书你都要看」，然后小红每次发现不错的书都放到书架上，小明则看到书架上有书就拿下来看。          
书架就是一个消息队列，小红是生产者，小明是消费者。 
这带来的好处有： 
1.小红想给小明书的时候，不必问小明什么时候有空，亲手把书交给他了，小红只把书放到书架上就行了。这样小红小明的时间都更自由。 
2.小红相信小明的读书自觉和读书能力，不必亲眼观察小明的读书过程，小红只要做一个放书的动作，很节省时间。 
3.当明天有另一个爱读书的小伙伴小强加入，小红仍旧只需要把书放到书架上，小明和小强从书架上取书即可（唔，姑且设定成多个人取一本书可以每人取走一本吧，可能是拷贝电子书或复印，暂不考虑版权问题）。 
4.书架上的书放在那里，小明阅读速度快就早点看完，阅读速度慢就晚点看完，没关系，比起小红把书递给小明并监督小明读完的方式，小明的压力会小一些。 
 
这就是消息队列的四大好处： 
1.解耦每个成员不必受其他成员影响，可以更独立自主，只通过一个简单的容器来联系。小红甚至可以不知道从书架上取书的是谁，小明也可以不知道往书架上放书的人是谁， 
  在他们眼里，都只有书架，没有对方。毫无疑问，与一个简单的容器打交道，比与复杂的人打交道容易一万倍，小红小明可以自由自在地追求各自的人生。 
2.提速小红选择相信「把书放到书架上，别的我不问」，为自己节省了大量时间。小红很忙，只能抽出五分钟时间，但这时间足够把书放到书架上了。 
3.广播小红只需要劳动一次，就可以让多个小伙伴有书可读，这大大地节省了她的时间，也让新的小伙伴的加入成本很低。 
4.削峰假设小明读书很慢，如果采用小红每给一本书都监督小明读完的方式，小明有压力，小红也不耐烦。反正小红给书的频率也不稳定，如果今明两天连给了五本， 
  之后隔三个月才又给一本，那小明只要在三个月内从书架上陆续取走五本书读完就行了，压力就不那么大了。 
   
当然，使用消息队列也有其成本： 
1.引入复杂度毫无疑问，「书架」这东西是多出来的，需要地方放它，还需要防盗。 
2.暂时的不一致性假如妈妈问小红「小明最近读了什么书」，在以前的方式里，小红因为亲眼监督小明读完书了，可以底气十足地告诉妈妈， 
  但新的方式里，小红回答妈妈之后会心想「小明应该会很快看完吧……」这中间存在着一段「妈妈认为小明看了某书，而小明其实还没看」的时期， 
  当然，小明最终的阅读状态与妈妈的认知会是一致的，这就是所谓的「最终一致性」。 
   
那么，该使用消息队列的情况需要满足什么条件呢？ 
1.生产者不需要从消费者处获得反馈引入消息队列之前的直接调用，其接口的返回值应该为空，这才让明明下层的动作还没做，上层却当成动作做完了继续往后走——即所谓异步——成为了可能。 
  小红放完书之后小明到底看了没有，小红根本不问，她默认他是看了，否则就只能用原来的方法监督到看完了。 
2.容许短暂的不一致性妈妈可能会发现「有时候据说小明看了某书，但事实上他还没看」，只要妈妈满意于「反正他最后看了就行」，异步处理就没问题。 
  如果妈妈对这情况不能容忍，对小红大发雷霆，小红也就不敢用书架方式了。 
3.确实是用了有效果即解耦、提速、广播、削峰这些方面的收益，超过放置书架、监控书架这些成本。否则如果是盲目照搬，「听说老赵家买了书架，咱们家也买一个」， 
  买回来却没什么用，只是让步骤变多了，还不如直接把书递给对方呢，那就不对了。

个人认为消息队列的主要特点是异步处理，主要目的是减少请求响应时间和解耦。所以主要的使用场景就是将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。 
同时由于使用了消息队列，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即解耦和。 
使用场景： 
举个例子：假设用户在你的软件中注册，服务端收到用户的注册请求后，它会做这些操作： 
1.校验用户名等信息， 
2.如果没问题会在数据库中添加一个用户记录如果是用邮箱注册会给你发送一封注册成功的邮件，手机注册则会发送一条短信 
3.分析用户的个人信息，以便将来向他推荐一些志同道合的人，或向那些人推荐他 
4.发送给用户一个包含操作指南的系统通知 
5.等等…… 
但是对于用户来说，注册功能实际只需要第一步，只要服务端将他的账户信息存到数据库中他便可以登录上去做他想做的事情了。至于其他的事情，非要在这一次请求中全部完成么？ 
值得用户浪费时间等你处理这些对他来说无关紧要的事情么？ 
所以实际当第一步做完后，服务端就可以把其他的操作放入对应的消息队列中然后马上返回用户结果，由消息队列异步的进行这些操作。 
或者还有一种情况，同时有大量用户注册你的软件，再高并发情况下注册请求开始出现一些问题，例如邮件接口承受不住，或是分析信息时的大量计算使cpu满载，这将会出现虽然用户数据记录很快的添加到数据库中了， 
但是却卡在发邮件或分析信息时的情况，导致请求的响应时间大幅增长，甚至出现超时，这就有点不划算了。 
面对这种情况一般也是将这些操作放入消息队列（生产者消费者模型），消息队列慢慢的进行处理，同时可以很快的完成注册请求，不会影响用户使用其他功能。 
所以在软件的正常功能开发中，并不需要去刻意的寻找消息队列的使用场景，而是当出现性能瓶颈时，去查看业务逻辑是否存在可以异步处理的耗时操作，如果存在的话便可以引入消息队列来解决。 
否则盲目的使用消息队列可能会增加维护和开发的成本却无法得到可观的性能提升，那就得不偿失了。