消息中间件深度解析

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

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

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

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

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

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

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

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

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

1.异步处理 

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

2.应用解耦

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

3.流量削峰

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

4.日志处理

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

5.消息通讯

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

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

常见消息中间件比较

消息中间件深度解析_第1张图片

如何选择合适的中间件:

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

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

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

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

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

你可能感兴趣的:(消息中间件深度解析)