削峰填谷

在有些业务系统的使用上，可能会出现超高并发场景。由于后端的服务来不及处理过多的请求，可能导致请求的阻塞，严重的时候可能由于请求过多导致Web端服务器瘫痪。

在实际场景中，我们的实际流量并不像是我们想象的那么平稳，而是会出现流量波峰和波谷，如图所示。例如像是12306一样，在春运期间的使用流量与在平时的使用流量是完全不一样的。

为了能够支持大流量的请求，我们可以采用直接进行服务器扩容的方式来，增加系统的吞吐量，但是所带来的问题就是，在流量小的时候，所有的扩容的服务器都成了闲置的服务器。

那么如何能够平衡节假日高流量与平时低流量的矛盾呢？这个时候我们就可以用消息队列来解决这个问题。例如现在比较流行的Apache RocketMQ、Apache Kafka等等，都是目前业界比较常用的手段。利用消息队列来处理订票请求，告知用户会在30分钟之内通知购票结果，这样不但提升了系统的性能，也不影响用户体验。

程序间解耦

不同端的业务在联合开发的时候，由于各个项目组的排期，人员、分工等的不同。都会导致项目出现各种各样的问题。从软件开发的角度上来讲，就是项目系统耦合度太高了。

因为上下游业务之间的联动性，上游的业务如果没有开发测试完成，是没有办法进行下游业务的开发的，这个时候。消息队列就完全可以解决这个问题。如下图所示。

加入了消息队列之后，上下游的开发、联调、上线等操作都不会出现上游对下游有所影响的问题。也就是说系统之间形成了完全解耦操作，系统之间可以独立的进行开发自己的业务。只需要执行统一的数据交换方式即可。

异步消息处理

在上面的内容中我们提到了一个火车票的案例，当我们提交订票的请求之后，会进入到消息队列中进行等待，对于检查车次、检查库存、检查时间等一系列的耗时操作都交给了系统来完成。于此同时，用户可以处理其他的事情，在30分钟之内会将最终的订票结果通知到用户，而不需要用户一直在订票页面上等待。这样就完成了异步消息的处理。

解决数据最终一致性

在日常的开发中我们都会遇到，多个系统之间的通信问题，如下图所示。

如果通信失败了，如何能够保证两个银行之间的转账操作是正确的呢？利用消息对就可以解决这个问题，我们只需要将消息提交到消息队列中，剩余的重试操作都交给了消息队列，即使这个时候两个银行任意的一个出现问题了，也不会影响到用户的正常使用APP，等到系统恢复之后，消息队列中的消息就会进行重试来完成款项的扣除操作。

常见的消息队列