一 .概述
首先我们先说一下消息中间件的主要的作用:
[1]异步处理
[2]解耦服务
[3]流量削峰
上面的三点是我们使用消息中间件最主要的目的.
下面我们来揭示一下如何实现上述的行为.
异步处理和解耦服务常常伴随在一起,当我们的业务复杂程度比较高的时候,我们常常希望能够按照一定的规则将我们的业务进行划分,此时就会出现一个问题,就是业务之间如何通信的问题.
消息中间件提供了一种可靠的方式保证消息的投递和消费的成功,将通信的代价降到底最小,通过消息中间件,我们就能满足我们的服务解耦.
消息本身就是异步的,因此在我们使用消息中间件的时候本身就是在做异步的处理,我们知道异步初拉力可以带来性能的提升,
当我们在一定时间段内,我们的服务会充斥大量的请求访问,在这个时候,如果我们不进行处理,服务器很容器出现瘫痪,此时我们可以使用消息中间件帮助我们实现请求的中转,当请求过多的时候,直接删除掉多于的请求,这样就能帮助我们
解决请求过多的情况.
二 . 消息中间件的选型问题
Activmq是一个比较好的中间件,但是现在更新的不是很快,而且性能在大并发的情况很容易就出现问题,我们在一些情况下选用这个消息中间件也是比较合适的,因此这个消息中间件遵循JMS规范,对于java的支持是比较好的.
Rabbitmq是一个中小企业使用的比较多的消息中间件,在可靠性和性能方面都很不错,而且遵循AMPQ协议,现在又是spring的亲儿子,前景是非常美好的,我们本次就首先学习一下Rabbitmq.
另外一个比较好的中间件就是kafka,这个消息中间件是一个日志处理的中间件,对可靠性的要求比较低,但是处理的吞吐量是最大的,如果我们使用这个消息中间件作为一个对数据一致性要求不高的环境下,是一个非常好的选择.
三 .常见的消息中间的使用场景(下面为https://my.oschina.net/vshcxl/blog/1787964中的内容)
2.1异步处理
场景说明：用户注册后，需要发注册邮件和注册短信,传统的做法有两种1.串行的方式;2.并行的方式
(1)串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务全部完成后才返回给客户端。 这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西.
(2)并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。 
假设三个业务节点分别使用50ms,串行方式使用时间150ms,并行使用时间100ms。虽然并性已经提高的处理时间,但是,前面说过,邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功,英爱是写入数据库后就返回.
(3)消息队列
引入消息队列后，把发送邮件,短信不是必须的业务逻辑异步处理 
由此可以看出,引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的3倍,是并行的2倍。
2.2 应用解耦
场景：双11是购物狂节,用户下单后,订单系统需要通知库存系统,传统的做法就是订单系统调用库存系统的接口.
这种做法有一个缺点:
- 当库存系统出现故障时,订单就会失败。(这样马云将少赚好多好多钱^ ^)
-
订单系统和库存系统高耦合.
引入消息队列 -
订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。
- 库存系统:订阅下单的消息,获取下单消息,进行库操作。
就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失(马云这下高兴了).
流量削峰
流量削峰一般在秒杀活动中应用广泛
场景:秒杀活动，一般会因为流量过大，导致应用挂掉,为了解决这个问题，一般在应用前端加入消息队列。
作用:
1.可以控制活动人数，超过此一定阀值的订单直接丢弃(我为什么秒杀一次都没有成功过呢^^)
2.可以缓解短时间的高流量压垮应用(应用程序按自己的最大处理能力获取订单)
1.用户的请求,服务器收到之后,首先写入消息队列,加入消息队列长度超过最大值,则直接抛弃用户请求或跳转到错误页面.
2.秒杀业务根据消息队列中的请求信息，再做后续处理.
