引言
1、队列应用场景:
MQ(Message Queue,消息队列)
消息队列在实际应用中常用的使用场景(优点):异步处理
,应用解耦
,流量削锋
和消息通讯
四个场景。
2、目前使用较多的消息队列:
有老牌的ActiveMQ、RabbitMQ,ZeroMQ,炙手可热的Kafka,MetaMQ,阿里巴巴的RocketMQ。
3、如何选型(目前现状):
ActiveMQ,性能不是很好,因此在高并发的场景下,直接被pass掉了。它的Api很完善,在中小型互联网公司可以去使用。最早大家都用 ActiveMQ,但是现在确实大家用的不多了,社区也不是很活跃,不推荐用这个了;
后来大家开始用 RabbitMQ,但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它,对公司而言,几乎处于不可控的状态,但是确实人家是开源的,比较稳定的支持,活跃度也高,可视化的管理界面比较友好;
不过现在确实越来越多的公司,会去用 RocketMQ,确实很不错(阿里出品),它是纯Java开发,它高性能、满足可靠性、分布式事物、支持水平扩展、上亿级别的消息堆积、主从之间的切换等等。MQ的所有优点它基本都满足。但是它最大的缺点:商业版收费。但社区可能有突然黄掉的风险,对自己公司技术实力有绝对自信的,推荐用 RocketMQ,否则老老实实用 RabbitMQ 吧,毕竟RabbitMQ有活跃的开源社区,绝对不会黄。
所以中小型公司,技术实力较为一般,技术挑战不是特别高,用 RabbitMQ 是不错的选择;大型公司,基础架构研发实力较强,用 RocketMQ 是很好的选择。
如果是大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,适合产生大量数据的互联网服务的数据收集业务等。社区活跃度很高,何况几乎是全世界这个领域的事实性规范。kafka,主要强调高性能,如果对业务需要可靠性消息的投递的时候。那么就不能够选择kafka了。
4、使用消息队列缺点:
-
系统可用性降低:系统引入的外部依赖越多,越容易挂掉,万一MQ挂了,整套系统崩溃了。
-
系统复杂性提高:加MQ进来,怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?
-
一致性问题:A系统处理完了直接返回成功了,后面的如果失败了,这数据就不一致了。
一、RabbitMQ
1、RabbitMQ概述
AMQP
,即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。
AMQP协议更多用在企业系统内,对数据一致性、稳定性和可靠性要求很高的场景,对性能和吞吐量的要求还在其次。
RabbitMQ
是实现了高级消息队列协议(AMQP)的开源消息代理软件(亦称面向消息的中间件)。RabbitMQ服务器是用Erlang语言编写的。
RabbitMQ 是比较有代表性的,因为是基于主从(非分布式)做高可用性
的。
2、RabbitMQ原理图
RabbitMQ通过信道
的方式传输数据,将消息发布到交换机上,消息拥有一个路邮键,由消息创建时设定,通过队列路由键,可以把队列绑定到交换机上,消息到达交换机后,RabbitMQ将消息的路由键与队列的路由键进行匹配(不同的交换机有不同的路由规则),匹配到相应的队列,消息投递到队列的队列中供消费者消费。
多个消费者可以订阅同一个Queue,消息将以
循环(round-robin)
的方式发送给消费者,每条消息只会发给一个订阅的消费者,而不是每个消费者都收到所有的消息并处理。
每个Channel运行在独立的线程上,多个线程共享同一个socket。
相关概念:
-
ConnectionFactory(连接管理器):应用程序与Rabbit之间建立连接的管理器,程序代码中使用;
-
Broker:简单来说就是消息队列服务器实体。
-
Channel(信道):消息推送使用的通道;
-
Exchange(交换器):用于接受、分配消息;
-
Queue(队列):用于存储生产者的消息;
-
RoutingKey(路由键):用于把生成者的数据分配到交换器上;【最大255个字节】
-
BindingKey(绑定键):用于把交换器的消息绑定到队列上;【最大255个字节】
-
vhost(虚拟主机)每个Rabbit都能创建很多vhost,每个虚拟主机其实都是mini版的RabbitMQ,拥有自己的队列,交换器和绑定,拥有自己的权限机制。
3、RabbitMQ常用的三种交换机
RabbitMQ常用的三种Exchange:fanout,direct,topic
(1)Direct Exchange :
直连型交换机,根据消息携带的路由键将消息投递给对应队列。
大致流程,有一个队列绑定到一个直连交换机上,同时赋予一个路由键 routing key。 然后当一个消息携带着路由值为X,这个消息通过生产者发送给交换机时,交换机就会根据这个路由值X去寻找绑定值也是X的队列。
(2)Fanout Exchange:
扇型交换机,这个交换机没有路由键概念,就算你绑了路由键也是无视的。 这个交换机在接收到消息后,会直接转发到绑定到它上面的所有队列。
(3)Topic Exchange:
主题交换机,这个交换机其实跟直连交换机流程差不多,但是它的特点就是在它的路由键和绑定键之间是有规则的。
性能排序:fanout > direct >> topic。
4、 RabbitMQ集群元数据
RabbitMQ集群会始终同步四种类型的内部元数据:
-
a. 队列元数据:队列名称和它的属性
-
b. 交换器元数据:交换器名称、类型和属性
-
c. 绑定元数据:一张简单的表格展示了如何将消息路由到队列
-
d. vhost元数据:为vhost内的队列、交换器和绑定提供命名空间和安全属性
5、RabbitMQ镜像集群
RabbitMQ 有三种模式:单机模式、普通集群模式(无高可用性)、镜像集群模式
(高可用性)。
镜像队列
将需要消费的队列变成镜像队列,存在于多个节点,实现RabbitMQ的高可用,保证 100% 数据不丢失。作用就是消息实体会主动在镜像节点之间实现同步,而不是像普通模式那样,在消费者消费数据时临时拉取,缺点就是集群内部的同步通讯
会占去大量的网络带宽。
二、RocketMQ
RocketMQ
是阿里开源的消息中间件,目前也已经孵化为Apache顶级项目。用Java语言实现,在设计时参考了Kafka,并做出了自己的一些改进,消息可靠性上比Kafka更好。RocketMQ在阿里内部被广泛应用在订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发等场景。
RocketMQ缺点:
-
单机支持1万以上持久化队列;
-
RocketMQ的所有消息都是持久化的,先写入系统PAGECACHE,然后刷盘,可以保证内存与磁盘都有一份数据,而访问时,直接从内存读取。
-
模型简单,接口易用(JMS的接口很多场合并不太实用);
-
性能非常好,可以允许大量堆积消息在Broker中;
-
支持多种消费模式,包括集群消费、广播消费等;
-
各个环节分布式扩展设计,支持主从和高可用;
-
开发度较活跃,版本更新很快。
RocketMQ缺点:
-
支持的 客户端语言不多,目前是Java及C++,其中C++还不成熟
-
维护RocketMQ需要专业的团队
-
商业版收费,有许多功能是不对外提供的。
-
没有在MQ核心里实现JMS等接口
三、kafka
1、kafka概述
kafka
是Linkedin于2010年12月份开源的消息发布订阅
系统,它主要用于处理活跃的流式数据,大数据量的数据处理上。作为hadoop生态系统的一部分,被各种商业公司广泛应用。
kafka优点:
-
高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒
-
可扩展性:kafka集群支持热扩展
-
持久性、可靠性:消息被持久化到本地磁盘,并且支持数据备份防止数据丢失
-
容错性:允许集群中节点失败(若副本数量为n,则允许n-1个节点失败)
-
高并发:支持数千个客户端同时读写
kafka缺点:
-
快速持久化:可以在O(1)的系统开销下进行消息持久化;
-
高吞吐:在一台普通的服务器上既可以达到10W/s的吞吐速率;
-
完全的分布式系统:Broker、Producer和Consumer都原生自动支持分布式,自动实现负载均衡;
-
支持同步和异步复制两种高可用机制;
-
支持数据批量发送和拉取;
-
零拷贝技术(zero-copy):减少IO操作步骤,提高系统吞吐量;
-
数据迁移、扩容对用户透明;
-
无需停机即可扩展机器;
-
其他特性:丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制
2、kafka原理图
四、总结
标签:队列,路由,RabbitMQ,Kafka,交换机,消息,RocketMQ From: https://www.cnblogs.com/zhyp/p/18049755