赞
踩
- MQ全称是Message Queue,消息的队列,因为是队列,所以遵循FIFO 先进先出的原则,它是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务
流量削峰:解决高并发问题
- 例如秒杀活动,可能会在短时间内产生大量请求同时打到服务端,如果后端对每个请求都进行数据库读写操作,定会造成服务器压力过大,产生服务异常甚至不可用。我们可以通过使用MQ实现流量缓冲,将所有请求先放入消息队列中,服务端每次处理业务先从消息队列获取,从而实现流量削峰,解决高并发问题
应用解耦:提升系统可用性
- 例如电商应用中有订单系统、库存系统、物流系统、支付系统,当用户创建订单后,先后调用库存系统、物流系统、支付系统,任何一个子系统出了故障,都会造成下单失败。引入消息队列后,系统间耦合调用的问题会减少,任何一个子系统出现故障都不会影响用户下单,子系统故障恢复后,会继续处理消息,提升系统可用性。
异步处理:提升响应速度
- 当用户在客户端提交了一个同步请求,后端处理需要耗时很久才能响应,这对用户体验来说无疑是致命的。如果说用户并不关心请求是否处理完成,对于一些耗时的非事务性的业务处理,可以使用消息队列异步请求的方式,将请求信息放入消息队列,直接返回客户端响应,后端监听队列自行处理,提升响应速度
Kafka
- 大数据领域内的消息传输,则绕不开Kafka,这款为大数据而生的消息中间件,以其百万级TPS的吞吐量名声大噪
- 优点:单机写入TPS约在百万条/秒,最大的优点,就是吞吐量高。时效性ms级可用性非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用,消费者采用Pull方式获取消息,消息有序,通过控制能够保证所有消息被消费且仅被消费一次;有优秀的第三方Kafka Web管理界面Kafka-Manager;在日志领域比较成熟,被多家公司和多个开源项目使用;主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集场景中大规模使用。
- 缺点:单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,Load越高,发送消息响应时间变长,使用短轮询方式,实时性取决于轮询间隔时间,消费失败不支持重试;支持消息顺序,但是一台代理宕机后,就会产生消息乱序,社区更新较慢
RabbitMQ
- 2007年发布,是一个在AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一。
- 优点:由于erlang语言的高并发特性,性能较好;吞吐量到万级,MQ功能比较完备、健壮、稳定、易用、跨平台、支持多种语言,如:Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等,支持AJAX文档齐全;开源提供的管理界面非常棒,用起来很好用,社区活跃度高,更新频率相当高。
- 缺点:商业版需要收费,学习成本较高
RocketMQ
- 2007年发布,是一个在AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一。
- 优点:由于erlang语言的高并发特性,性能较好;吞吐量到万级,MQ功能比较完备、健壮、稳定、易用、跨平台、支持多种语言,如:Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等,支持AJAX文档齐全;开源提供的管理界面非常棒,用起来很好用,社区活跃度高,更新频率相当高。
- 缺点:商业版需要收费,学习成本较高
ActiveMQ
- ActiveMQ是一款非常古老的MQ。
- 优点:单机吞吐量万级,时效性ms级,可用性高,基于主从架构实现高可用性,消息可靠,丢失数据的概率较低。
- 缺点:官方社区现在对ActiveMQ 5.x维护越来越少, 高吞吐量场景较少使用。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。