现在常用的MQ组件有ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ、MetaMQ。
一、MQ特点
1、先进先出
不能先进先出,都不能说是队列了。消息队列的顺序在入队的时候就基本已经确定了,一般是不需人工干预的。而且,最重要的是,数据是只有一条数据在使用中。 这也是MQ在诸多场景被使用的原因。
2、发布订阅
发布订阅是一种很高效的处理方式,如果不发生阻塞,基本可以当做是同步操作。这种处理方式能非常有效的提升服务器利用率,这样的应用场景非常广泛。
3、持久化
持久化确保MQ的使用不只是一个部分场景的辅助工具,而是让MQ能像数据库一样存储核心的数据。
4、分布式
在现在大流量、大数据的使用场景下,只支持单体应用的服务器软件基本是无法使用的,支持分布式的部署,才能被广泛使用。而且,MQ的定位就是一个高性能的
1、为什么要使用消息队列? 以下六个字:解耦、异步、削峰
(1)解耦
传统模式:
传统模式的缺点:
- 系统间耦合性太强,如上图所示,系统A在代码中直接调用系统B和系统C的代码,如果将来D系统接入,系统A还需要修改代码,过于麻烦!
中间件模式:
中间件模式的的优点:
- 将消息写入消息队列,需要消息的系统自己从消息队列中订阅,从而系统A不需要做任何修改。
(2)异步
传统模式:
传统模式的缺点:
- 一些非必要的业务逻辑以同步的方式运行,太耗费时间。
中间件模式:
中间件模式的的优点:
- 将消息写入消息队列,非必要的业务逻辑以异步的方式运行,加快响应速度
(3)削峰
传统模式
传统模式的缺点:
- 并发量大的时候,所有的请求直接怼到数据库,造成数据库连接异常
中间件模式:
中间件模式的的优点:
- 系统A慢慢的按照数据库能处理的并发量,从消息队列中慢慢拉取消息。在生产中,这个短暂的高峰期积压是允许的。
二、RabbitMQ
RabbitMQ是一个分布式系统,这里面有几个抽象概念。
1:broker:每个节点运行的服务程序,功能为维护该节点的队列的增删以及转发队列操作请求。
2:master queue:每个队列都分为一个主队列和若干个镜像队列。
3:mirror queue:镜像队列,作为master queue的备份。在master queue所在节点挂掉之后,系统把mirror queue提升为master queue,负责处理客户端队列操作请求。注意,mirror queue只做镜像,设计目的不是为了承担客户端读写压力。
如上图所示,集群中有两个节点,每个节点上有一个broker,每个broker负责本机上队列的维护,并且borker之间可以互相通信。集群中有两个队列A和B,每个队列都分为master queue和mirror queue(备份)。那么队列上的生产消费怎么实现的呢?
队列消费
如上图有两个consumer消费队列A,这两个consumer连在了集群的不同机器上。RabbitMQ集群中的任何一个节点都拥有集群上所有队列的元信息,所以连接到集群中的任何一个节点都可以,主要区别在于有的consumer连在master queue所在节点,有的连在非master queue节点上。
因为mirror queue要和master queue保持一致,故需要同步机制,正因为一致性的限制,导致所有的读写操作都必须都操作在master queue上(想想,为啥读也要从master queue中读?和数据库读写分离是不一样的。),然后由master节点同步操作到mirror queue所在的节点。即使consumer连接到了非master queue节点,该consumer的操作也会被路由到master queue所在的节点上,这样才能进行消费。
队列生产
原理和消费一样,如果连接到非 master queue 节点,则路由过去。
所以,到这里小伙伴们就可以看到 RabbitMQ的不足:由于master queue单节点,导致性能瓶颈,吞吐量受限。虽然为了提高性能,内部使用了Erlang这个语言实现,但是终究摆脱不了架构设计上的致命缺陷。
四、Kafka
13.1 kafka
1、基本组件
1、话题(Topic):是特定类型的消息流。消息是字节的有效负载(Payload),话题是消息的分类名或种子(Feed)名;
2、生产者(Producer):是能够发布消息到话题的任何对象;
3、服务代理(Broker):已发布的消息保存在一组服务器中,它们被称为代理(Broker)或Kafka集群;安装了kafka的服务器就是一个broker。
4、消费者(Consumer):可以订阅一个或多个话题,并从Broker拉数据,从而消费这些已发布的消息;
上图中可以看出,生产者将数据发送到Broker代理,Broker代理有多个话题topic,消费者从Broker获取数据。
2、基本概念介绍
- Topic主题:一组消息抽象归纳为一个topic,是对消息的一个逻辑分类;Topic相当于传统消息系统MQ中的一个队列queue,producer端发送的message必须指定是发送到哪个topic,但是不需要指定topic下的哪个partition,因为kafka会把收到的message进行load balance,均匀的分布在这个topic下的不同的partition上( hash(message) % [broker数量] )
由此可见,Kafka绝对是为了高吞吐量设计的,比如设置分片数为100,那么就有100台机器去扛一个Topic的流量,当然比RabbitMQ的单机性能好。
- message消息:kafka通信的基本单位,主要offset key value timestamp构成
- partition分区:分区是kafka消息队列组织的最小单位;物理上存储上,一个topic 可以有多个partition,一个partition 可以有多个副本;
- partition 可以有多个副本,但是只有一个leader partition处于工作状态,副本只是负责同步数据,当leader partition 死掉了,zookeeper会重新leader 选举将一个副本的partition 升级为leader。
- 在物理结构上,每个partition对应一个物理的目录(文件夹),文件夹命名是[topicname]_[partition]_[序号],一个topic可以有无数多的partition,根据业务需求和数据量来设置。在kafka配置文件中可随时更高num.partitions参数来配置更改topic的partition数量,在创建Topic时通过参数指定parittion数量。Topic创建之后通过Kafka提供的工具也可以修改partiton数量。
- 每个partiton相当于是一个FIFO( First Input First Output的缩写,先入先出队列)子队列queue,partition物理上由多个Segment file(段)组成,每个Segment存着message信息。
- replica副本:是partition的备份,一个partition可以存在1个or多个replica,分布在集群不同代理上。
- leader(领导者)副本与follower(追随者)副本:为保证一个partition的多个replica之间数据的一致性,kafka会在replica中选择一个作为leader副本,其余为follower副本,只有leader副本负责客户端的write/read请求,follower副本从leader副本同步数据,若leader副本失效,则选举其他follower副本为新的leader副本。
如下图:一个topic 可以有多个partition,每个partition有一个leader副本和多个follower副本
- broker代理(经纪人):kafka集群中的机器/服务被称为broker,一个kafka集群由一个or多个kafka代理组成,每个broker都要有 一个非负整数的唯一标识id,通过broker.id配置;Kafka集群通常由多个代理组成以保持负载平衡。 Kafka代理是无状态的,所以他们使用ZooKeeper来维护它们的集群状态。 一个Kafka代理实例可以每秒处理数十万次读取和写入,每个Broker可以处理TB的消息,而没有性能影响。 Kafka经纪人领导选举可以由ZooKeeper完成。
- producer生产者:负责将消息发送给broker,即向kafka代理发送消息的客户端
- consumer消费者:kafka中通过zookeeper,负责以pull拉取方式拉取数据的客户端,每个consumer也有一个全局唯 一的id,可通过client.id配置。
- segment:kafka将一个partiton分割成很多个segment文件;segment file由2大部分组成,分别为index file(后缀”.index”)和data file后缀(“.log”),此2个文件一一对应,成对出现,分别表示为segment索引文件、数据文件.
- offset:
对于生产者而言把数据写到每个分区时,每条消息在所在分区是有一个递增的序号的,序号从 0 开始,这个序号就是 offset,offset 既反映了每条消息在分区中的相对位置,也唯一标识了一条消息,offset越小,消息越旧,最新写入的消息的 offset在当前分区总是最大的。
对于消费者而言也有offset,消费者的 offset 就是它消费过的最后一条消息的 offset,比如上图中,消费者 A 的 offset 是 9,消费者 B 的 offset 是 11,而这个分区中消息的最大 offset 正在变成 12。我认为消费者的 offset 的最大作用是:当消费者掉线之后,消费者重启后知道从哪条消息继续消费。
3、Kafka基本原理
我们将消息的发布(publish)称作 producer,将消息的订阅(subscribe)表述为 consumer,将中间的存储阵列称作 broker(代理),这样就可以大致描绘出这样一个场面:
多个 broker 协同合作,producer 和 consumer 部署在各个业务逻辑中被频繁的调用,三者通过 zookeeper管理协调请求和转发。这样一个高性能的分布式消息发布订阅系统就完成了。
producer 到 broker 的过程是 push(推送),也就是有数据就推送到 broker,而 consumer 到 broker 的过程是 pull(拉取),是通过 consumer 主动去拉数据的,而不是 broker 把数据主懂发送到 consumer 端的。
4、Kafka的特性
1.高吞吐量、低延迟
kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒,每个topic可以分多个partition, consumer group 对partition进行consume操作。
2.可扩展性
kafka集群支持热扩展
3.持久性、可靠性
消息被持久化到本地磁盘,并且支持数据备份防止数据丢失
4.容错性
允许集群中节点失败(若副本数量为n,则允许n-1个节点失败)
5.高并发
支持数千个客户端同时读写
5、Kafka的使用场景
1.日志收集
一个公司可以用Kafka可以收集各种服务的log,通过kafka以统一接口服务的方式开放给各种consumer,例如hadoop、Hbase、Solr等。
2.消息系统
解耦和生产者和消费者、缓存消息等。
3.用户活动跟踪
Kafka经常被用来记录web用户或者app用户的各种活动,如浏览网页、搜索、点击等活动,这些活动信息被各个服务器发布到kafka的topic中,然后订阅者通过订阅这些topic来做实时的监控分析,或者装载到hadoop、数据仓库中做离线分析和挖掘。
4.运营指标
Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据,生产各种操作的集中反馈,比如报警和报告。
5.流式处理
比如spark streaming和storm
五、三类消息产品(Kafka、RabbitMQ、RocketMQ)做了性能比较
- Kafka(大数据量的数据处理上,吞吐量高达17.3w/s,常用日志采集,数据采集上)
高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒
1.应当有一个非常好的运维监控系统,不单单要监控Kafka本身,还要监控Zookeeper。(kafka强烈的依赖于zookeeper,如果zookeeper挂掉了,那么Kafka也不行了)
2.对消息顺序不依赖,且不是那么实时的系统。
3.对消息丢失并不那么敏感的系统。
4.从 A 到 B 的流传输,无需复杂的路由,最大吞吐量可达每秒 100k 以上。
Kafka是LinkedIn开源的分布式发布-订阅消息系统,目前归属于Apache顶级项目。Kafka主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输。0.8版本开始支持复制,不支持事务,对消息的重复、丢失、错误没有严格要求,适合产生大量数据的互联网服务的数据收集业务。
- RabbitMQ (用在实时的对可靠性要求比较高的消息传递上,RabbitMQ的吞吐量5.95w/s,适合企业级的消息发送)
在可用性上,稳定性上,可靠性上,RabbitMq超过kafka
1.RabbitMQ的消息应当尽可能的小,并且只用来处理实时且要高可靠性的消息。
2.消费者和生产者的能力尽量对等,否则消息堆积会严重影响RabbitMQ的性能。
3.集群部署,使用热备,保证消息的可靠性。
RabbitMQ是使用Erlang语言开发的开源消息队列系统,基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。AMQP协议更多用在企业系统内,对数据一致性、稳定性和可靠性要求很高的场景,对性能和吞吐量的要求还在其次。
- RocketMQ (吞吐量在11.6w/s)
RocketMQ是阿里开源的消息中间件,它是纯Java开发,具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka,但并不是Kafka的一个Copy,它对消息的可靠传输及事务性做了优化,目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。
- Redis 消息推送是基于分布式 pub/sub,多用于实时性较高的消息推送,并不保证可靠
是一个Key-Value的NoSQL数据库,开发维护很活跃,虽然它是一个Key-Value数据库存储系统,但它本身支持MQ功能,所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作,各执行100万次,每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明:入队时,当数据比较小时Redis的性能要高于RabbitMQ,而如果数据大小超过了10K,Redis则慢的无法忍受;出队时,无论数据大小,Redis都表现出非常好的性能,而RabbitMQ的出队性能则远低于Redis。
对比项 | kafka | rabbitmq |
单机吞吐量 | 10万级 | 万级 |
时效性 | ms级以内 | us级(微秒级) |
是否支持消息回溯 | 支持消息回溯,因为消息持久化,消息被消费后会记录offset和timstamp | 不支持,消息确认被消费后,会被删除 |
是否支持消息数据持久化 | 支持消息数据持久 | 支持消息数据持久 |
是否支持事务性消息 | 支持 | rocketmq4.3后面版本支持 |
优先级队列 | 不支持 | 支持。建议优先级大小设置在0-10之间。 |
延迟队列 | 不支持 | 支持 |
重试队列 | 不支持。 | 不支持RabbitMQ中可以参考延迟队列实现一个重试队列,二次封装比较简单。如果要在Kafka中实现重试队列,首先得实现延迟队列的功能,相对比较复杂。 |
是否支持消息堆积 | 支持消息堆积,并批量持久化到磁盘 | 支持阈值内的消息对接,无法支持较大的消息堆积 |
是否支持流量控制 | 支持控制用户和客户端流量 | 支持生产者的流量控制 |
开发语言 | scala,Java | erlang |
是否支持多租户 | 2.x.x支持多租户 | 支持多租户 |
是否支持topic优先级 | 不支持 | 支持 |
是否支持消息全局有序 | 不支持 | 支持 |
是否支持消息分区有序 | 支持 | 支持 |
是否内置监控 | 无内置监控 | 内置监控 |
是否支持多个生产者 | 一个topic支持多个生产者 |
|
是否支持多个消费者 | 一个topic支持多个消费者 |
|
是否支持一个分区多个消费者 | 不支持 | 不支持 |
是否支持JMX | 支持 | 不支持(非java语言编写) |
是否支持加密 | 支持 | 支持 |
消息队列协议支持 | 仅支持自定义协议 | 支持AMQP、MQTT、STOMP协议 |
客户端语言支持 | 支持多语言客户端 | 支持多语言客户端 |
是否支持消息追踪 | 不支持消息追踪 | 支持消息追踪 |
是否支持消费者推/拉模式 | 拉模式 | 推模式+拉模式 |
是否支持广播消息 | 支持广播消息 | 支持广播消息 |
元数据管理 | 通过zookeeper进行管理 | 支持消息数据持久 |
默认服务端口 | 9200 | 5672 |
默认监控端口 | kafka web console 9000;kafka manager 9000; | 15672 |
网络开销 | 相对较小 | 相对较大 |
内存消耗 | 相对较小 | 相对较大 |
cpu消耗 | 相对较大 | 相对较小 |
消息一般有两种传递模式:点对点(P2P,Point-to-Point)模式和发布-订阅(Publish/Subscribe)模式
六、保证消息的可靠性传输?
分析:我们在使用消息队列的过程中,应该做到消息不能多消费,也不能少消费。如果无法做到可靠性传输,可能给公司带来千万级别的财产损失。同样的,如果可靠性传输在使用过程中,没有考虑到,这不是给公司挖坑么,你可以拍拍屁股走了,公司损失的钱,谁承担。还是那句话,认真对待每一个项目,不要给公司挖坑。
回答:其实这个可靠性传输,每种MQ都要从三个角度来分析:生产者弄丢数据、消息队列弄丢数据、消费者弄丢数据
RabbitMQ
(1)生产者丢数据
从生产者弄丢数据这个角度来看,RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。
transaction机制就是说,发送消息前,开启事物(channel.txSelect()),然后发送消息,如果发送过程中出现什么异常,事物就会回滚(channel.txRollback()),如果发送成功则提交事物(channel.txCommit())。然而缺点就是吞吐量下降了
(2)消费者丢数据
RabbitMQ一般情况很少丢失,但是不能排除意外,为了保证我们自己系统高可用,我们必须作出更好完善措施,保证系统的稳定性。
下面来介绍下,如何保证消息的绝对不丢失的问题,下面分享的绝对干货,都是在知名互联网产品的产线中使用。
1.消息持久化
2.ACK确认机制
3.设置集群镜像模式
4.消息补偿机制
第一种:消息持久化
RabbitMQ 的消息默认存放在内存上面,如果不特别声明设置,消息不会持久化保存到硬盘上面的,如果节点重启或者意外crash掉,消息就会丢失。
所以就要对消息进行持久化处理。如何持久化,下面具体说明下:
要想做到消息持久化,必须满足以下三个条件,缺一不可。
1) Exchange 设置持久化
2)Queue 设置持久化
3)Message持久化发送:发送消息设置发送模式deliveryMode=2,代表持久化消息
第二种:ACK确认机制
多个消费者同时收取消息,比如消息接收到一半的时候,一个消费者死掉了(逻辑复杂时间太长,超时了或者消费被停机或者网络断开链接),如何保证消息不丢?
这个使用就要使用Message acknowledgment 机制,就是消费端消费完成要通知服务端,服务端才把消息从内存删除。
这样就解决了,及时一个消费者出了问题,没有同步消息给服务端,还有其他的消费端去消费,保证了消息不丢的case。
第三种:设置集群镜像模式
第四种:消息补偿机制
为什么还要消息补偿机制呢?难道消息还会丢失,没错,系统是在一个复杂的环境,不要想的太简单了,虽然以上的三种方案,基本可以保证消息的高可用不丢失的问题,
但是作为有追求的程序员来讲,要绝对保证我的系统的稳定性,有一种危机意识。
比如:持久化的消息,保存到硬盘过程中,当前队列节点挂了,存储节点硬盘又坏了,消息丢了,怎么办?
产线网络环境太复杂,所以不知数太多,消息补偿机制需要建立在消息要写入DB日志,发送日志,接受日志,两者的状态必须记录。
然后根据DB日志记录check 消息发送消费是否成功,不成功,进行消息补偿措施,重新发送消息处理。
参考网址:https://www.jianshu.com/p/3d15798b88d2