kafka 消息中间件的使用场景

异步处理

通常使用队列就是为了异步，消息队列提供了异步处理机制，因为很多时候用户并不需要立即响应来处理消息， 那么通过这个机制就可以把所有消息放入 MQ 中。

比如，某系统发来的数据中包含很多图片信息，如果对其中的信息都进行保存处理， 用户一番操作下来可能会很久。采用异步处理之后，系统会将所有数据存放在 MQ 中， 用户不需要立即处理，大大缩短了系统的响应时间。

解耦

比如我们在一个系统中，需要调用其他的很多个系统，我们当然可以在这个系统中挨个调用其他的系统。但是问题就来了，如果我们需要调用的其他系统有变动，比如增加了新的系统，或者有一些系统不再提供服务了，那么应该怎么办呢？修改系统调用的代码，然后再次上线？

这样显得特别的麻烦，而且也使得这个系统与其他的系统完完全全的耦合在了一起。
所以我们可以把我们的”服务调用“，封装成一个消息，发送到消息中间件上。
对于其他的系统，只需要去这个消息中间件上面拉取自己需要的消息，然后进行处理。
此外，对于用户来说，也不需要等待这么长的时间，只要这个系统将消息丢进了消息中间件就可以返回了，这就保证了更快的响应速度。
这就是我们所说的解耦，一个系统只管把数据发送到中间件中，另外的系统只管从中间件中拿到数据，然后处理。

此时的系统 A 是强依赖系统 B 和系统 C 的，一旦系统 B 出现故障或者需要重新加入 高耦合的系统 D 时，就必须要更改系统 A 的代码。

如果经常出现这种依赖系统迭代的情况，那么系统 A 就会很难维护，可以通过消息 队列对依赖系统进行解耦(如下图)，这样系统 A 也无需关心其他系统的可用性。

削峰填谷

一开口就知道老高并发了。
这个名词我们其实并不陌生，但凡你搜过”高并发“、”秒杀”这一类的关键词，就一定会查到这样的结果。
那么削峰填谷的关键就在于让流量变得更加的平缓。
咱们就拿“秒杀”举例。
那么对于这个商城来讲，这个“秒杀”活动的上游服务就是下单。而这个上游服务需要调用很多的下游服务，比如库存服务生成库存，订单服务生成订单，支付服务，而支付服务又可能需要调用第三方的支付接口等等。简单来讲，就是上游服务的处理速度远远大于下游服务的处理速度。
那么这个时候如果我们不对上游服务做任何的限制，所有的请求直接打到下游服务，那么整个系统都可能挂掉。

所以，我们可以用消息中间件来做“削峰填谷”这件事情。

上游服务只需要将“某某用户在某某时间购买了某某商品”等这些必要的信息，丢进消息中间件中，然后下游服务按照自己的速度，从消息中间件中拉取信息，然后消费。这样，整个系统的处理就能有条不紊了。

比如，有个活动页面平时也就 50qps，某一特殊时刻访问量突然增多，能达到 1000qps，但是当前系统的处理能力最多为 100qps，这个时候可以通过消息队列来进行 削峰填谷，如下图所示。