消息中间件深度解析

常用的消息中间件有：activateMQ、rabbitMQ、Kafka、RocketMQ

消息中间件在架构方面主要用于解决架构的伸缩性和扩展性。符合开闭原则：扩展开放、修改封闭

如果使用传统的RPC去进行消息传递，务必回导致这样的问题：

当我们下了订单之后，服务端可能会除了进行相关业务处理，还需要发送邮件，发送短信，如果将这些过程使用传统RPC结构去实现，那么会导致我们下了订单之后，还需要等待邮件和短信进行处理完成后才会进行。（除非你使用future模式）

另外，如果我们想要再次添加一个将消息发送给一个客服平台，我们就需要修改其中的业务代码，导致整个系统耦合度太强，并且不利于维护。

此时，我们使用消息中间件（具有可插拔功能），我们不需要修改业务代码，只需要进行相关模块的配置，即可到达我们的要求，此刻达到模块之间的解耦，利于开发和维护

除此之外，使用消息中间件还具有异步通信能力（使得每个系统能够充分执行自己的逻辑而无需等待），缓冲能力（消息来不及处理时可以先存储起来，然后交由后台慢慢进行处理，典型场景就是秒杀）

解决RPC模式的依赖性和同步性

消息中间件的常见应用场景：

1.异步处理 

 比如在完成某个业务需要进行发短信和发邮件，串行方式是发了短信才能发送邮件，而使用异步，在发短信的同时可以发送邮件。如以上描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？引入消息队列，将不是必须的业务逻辑，异步处理。

2.应用解耦

 比如订单和库存模块，传统RPC请求在订单中调用库存模块时，如果库存模块无法访问，将导致订单生成失败。使用消息中间件，使得订单和库存之间解耦，订单在生成之后将消息存储在消息中间件中，库存处理相关业务时，只需要去消息中间件中拉取消息即可

3.流量削峰

 在秒杀等场景中同一时间会出现大量的信息，如果此时全部进行处理，服务器承受不住。为解决这个问题，一般需要在应用前端加入消息队列：可以控制活动的人数；可以缓解短时间内高流量压垮应用。用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面；秒杀业务根据消息队列中的请求信息，再做后续处理

4.日志处理

  日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。日志采集客户端，负责日志数据采集，定时写入kafka消息队列，负责日志数据的收集、存储和转发；日志处理应用：订阅并消费kafka队列中的日志消息

5.消息通讯

 点对点通讯。客户端A和客户端B同时使用同一队列，一方发送消息，一方接受消息

 topic通讯。客户端A、B、C同时订阅同一主题，进行消息发布和接受

常见消息中间件比较

如何选择合适的中间件：

用户访问量在activeMQ的可承受范围之内，而且确实主要是基于解耦和异步来用的，可以考虑activeMQ

       RabbitMQ，但是确实erlang语言阻止了我们去深入研究和掌控，对公司而言，几乎处于不可控的状态，但是确实是开源的，有比较稳定的支持，活跃度也高

对自己公司技术实力有绝对自信的，可以采用rocketMq

中小型公司，技术实力一般，技术挑战不是特别高，用ActiveMQ、RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择

如果是大数据领域的实时计算、日志采集等场景，用kafka是业内标准的，社区活跃度很高