消息队列的理解

 

我的认为消息队列的主要特色是异步处理，主要目的是减小请求响应时间和解耦。因此主要的使用场景就是将比较耗时并且不须要即时（同步）返回结果的操做做为消息放入消息队列。同时因为使用了消息队列，只要保证消息格式不变，消息的发送方和接收方并不须要彼此联系，也不须要受对方的影响，即解耦和。

使用场景的话，举个例子：
假设用户在你的软件中注册，服务端收到用户的注册请求后，它会作这些操做：

1. 校验用户名等信息，若是没问题会在数据库中添加一个用户记录
2. 若是是用邮箱注册会给你发送一封注册成功的邮件，手机注册则会发送一条短信
3. 分析用户的我的信息，以便未来向他推荐一些志同道合的人，或向那些人推荐他
4. 发送给用户一个包含操做指南的系统通知
5. 等等……

可是对于用户来讲，注册功能实际只须要第一步，只要服务端将他的帐户信息存到数据库中他即可以登陆上去作他想作的事情了。至于其余的事情，非要在这一次请求中所有完成么？值得用户浪费时间等你处理这些对他来讲可有可无的事情么？因此实际当第一步作完后，服务端就能够把其余的操做放入对应的消息队列中而后立刻返回用户结果，由消息队列异步的进行这些操做。

或者还有一种状况，同时有大量用户注册你的软件，再高并发状况下注册请求开始出现一些问题，例如邮件接口承受不住，或是分析信息时的大量计算使cpu满载，这将会出现虽然用户数据记录很快的添加到数据库中了，可是却卡在发邮件或分析信息时的状况，致使请求的响应时间大幅增加，甚至出现超时，这就有点不划算了。面对这种状况通常也是将这些操做放入消息队列（生产者消费者模型），消息队列慢慢的进行处理，同时能够很快的完成注册请求，不会影响用户使用其余功能。

因此在软件的正常功能开发中，并不须要去刻意的寻找消息队列的使用场景，而是当出现性能瓶颈时，去查看业务逻辑是否存在能够异步处理的耗时操做，若是存在的话即可以引入消息队列来解决。不然盲目的使用消息队列可能会增长维护和开发的成本却没法获得可观的性能提高，那就得不偿失了。