架构师-分布式消息队列(一)-认知提升

1.MQ的应用场景与MQ性能衡量指标

(1)分布式消息队列(MQ)应用场景

  • 服务解耦:如果使用 MQ,A系统产生一条数据,发送到 MQ 里面去,哪个系统需要数据自己去MQ里面消费。如果新系统需要数据,直接从 MQ 里消费即可;如果某个系统不需要这条数据了,就取消对MQ 消息的消费即可。这样下来,A系统压根儿不需要去考虑要给谁发送数据,不需要维护这个代码,也不需要考虑人家是否调用成功、失败超时等情况。
  • 削峰填谷:我们在生产环境中有流量很大的这么一些应用场景,比如秒杀、抢红包、双十一活动业务场景下,让你如何去对我们的应用服务做一个抗压,而这个就需要做一个削峰和填谷。MQ本质上最早期做的就是这件事,他做的事情就是说,当我的下游服务处理不过来之后,我可以把消息转存到一个地方,然后慢速去消费。
  • 顺序收发:细数日常中需要保证顺序的应用场景非常多,比如证券交易过程时间优先原则,交易系统中的订单创建、支付、退款等流程,航班中的旅客登机消息处理等等。与先进先出(First In First Out,缩写 FIFO)原理类似,消息队列 MQ 提供的顺序消息即保证消息 FIFO。
  • 分布式事务一致性:交易系统、支付红包等场景需要确保数据的最终一致性,大量引入消息队列 MQ 的分布式事务,既可以实现系统之间的解耦,又可以保证最终的数据一致性。
  • 异步:A系统接收一个请求,需要在自己本地写库,还需要在BCD三个系统写库,耗时较长。如果使用 MQ,那么A系统连续发送3条消息到MQ队列中,通知其他系统由MQ去异步处理,这样能大大提高响应速度。

(2)引入MQ有哪些缺点?

  • 系统可用性降低:系统引入MQ外部依赖,MQ可能出现故障,导致系统不可用;
  • 系统复杂度提高:需要保证消息的幂等性,可靠性投递问题;

(3)分布式消息队列(MQ)应用思考点(使用MQ会有哪些问题需要考虑?)

  • 生产端可靠性投递:如果你是金融领域相关的,那这个消息一定不能丢失,一定要做到生产端的100%把消息发送出去。核心业务需要保障消息不丢失,接下来我们看一个可靠性投递的流程图,说明可靠性投递的概念:

在这里插入图片描述

Step1:首先把消息信息(业务数据)存储到数据库中,紧接着,我们再把这个消息记录也存储到一张消息记录表里(或者另外一个同源数据库的消息记录表);
Step2:发送消息到MQ Broker节点(采用confirm方式发送,会有异步的返回结果);
Step 3、4:生产者端接受MQ Broker节点返回的Confirm确认消息结果,然后进行更新消息记录表里的消息状态。比如默认Status = 0 当收到消息确认成功后,更新为1即可;
Step 5:但是在消息确认这个过程中可能由于网络闪断、MQ Broker端异常等原因导致回送消息失败或者异常。这个时候就需要发送方(生产者)对消息进行可靠性投递了,保障消息不丢失,100%的投递成功!(有一种极限情况是闪断,Broker返回的成功确认消息,但是生产端由于网络闪断没收到,这个时候重新投递可能会造成消息重复,需要消费端去做幂等处理)所以我们需要有一个定时任务,(比如每5分钟拉取一下处于中间状态的消息,当然这个消息可以设置一个超时时间,比如超过1分钟 Status = 0 ,也就说明了1分钟这个时间窗口内,我们的消息没有被确认,那么会被定时任务拉取出来);
Step6:接下来我们把中间状态的消息进行重新投递 retry send,继续发送消息到MQ ,当然也可能有多种原因导致发送失败;
Step7:我们可以采用设置最大努力尝试次数,比如投递了3次,还是失败,那么我们可以将最终状态设置为Status = 2 ,最后交由人工解决处理此类问题(或者把消息转储到失败表中)。消费端幂等性:生产端为了做到可靠性投递,可能会重复发送消息,消费端为了确保重复发送的消息只有一个有效。

  • 高可用:MQ可以集群,做到负债均衡,以防宕机。
  • 低延迟:大流量下,延迟低,响应速度快,良好的交互体验。
  • 可靠性:保证消息不会丢失,比如磁盘损坏。解决方案类似ElasticSearch中分片和副本。
  • 堆积能力:能够接受多少消息。
  • 扩展性:横向扩容。

2.MQ的技术选型关注点

(1)业界主流的分布式消息队列有哪些?

在这里插入图片描述

(2)消息队列有哪些区别?(如何选型?)

ActiveMQ,RabbitMQ,RocketMQ,Kafka的主要区别:
在这里插入图片描述

补充: ActiveMQ不适合高并发场景,比较适合中小型项目; RabbitMQ可靠性、可用性、可维护高,但扩展性较低;
kafka和Rocket吞吐速度快,但可靠性低。

3.ActiveMQ集群架构与原理解析

(1)什么是JMS与其专业术语

小伙伴们大家好,现在我们和大家一起了解一下古者而又神秘的消息中间件"ActiveMQ"。首先,说起AtiveMQ,就必须先聊JMS(Java Message Service)规范,也就是Java消息服务,它定义了Java中访问消息中间件的接口的规范。在这里注意哦,JMS只是接口,并没有给予实现,实现JMS接口的消息中间件称为"JMS Provider",目前知名的开源MOM (Message Oriented
Middleware,也就是消息中间件)系统包括Apache的ActiveMQ、 RocketMQ、 Kafka,以及RabbitMQ,可以说他们都“基本遵循"或“参考”JMS规范,都有自己的特点和优势。

专业术语
●JMS Uava Message Service) :实现JMS接口的消息中间件;
●Provider (MessageProvider) :消息的生产者;
●Consumer (MessageConsumer) :消息的消费者:
●PTP (Point to Point) :即点对点的消息模型,这也是非常经典的模型;
●Pub/ Sub (Publish/Subscribe) :,即发布/订阅的消息模型;
●Queue: 队列目标,也就是我们常说的消息队列,一般都是 会真正的进行物理存储:
●Topic: 主题目标;
●ConnectionFactory: 连接工厂,JMS用它创建连接;
●Connection: JMS 客户端到MS Provider的连接;
●Destination: 消息的目的地;
●Session: 会话,一个发送或接收消息的线程(这里Session可以类比Mybatis的Session) ;

JMS消息格式定义:
●StreamMessage: 原始值的数据流
●MapMessage: 一套名称/值对
●TextMessage:一个字符串对象
●BytesMessage: 一个未解释字节的数据流
●ObjectMessage: 一个序列化的Java对象

(2)ActiveMQ的历史背景

ActiveMQ是一个完全支持JMS1.和J2EE 1.4规范的JMS Provider实现,尽管JMS规范出台已经是很久的事情了,但是JMS在早些年的"J2EE应用”时期扮演着特殊的地位,可以说那个年代ActiveMQ在业界应用最广泛,当然如果现在想要有更强大的性能和海量数据处理能力,ActiveMQ还需要不断的升级版本,不断的提升性能和架构设计的重构。就算现在我们80%以上的业务我们使用ActiveMQ已经足够满足需求,其丰富的API、 多种集群构建模式使得他成为业界老牌消息中间件,在中小型企业中应用广泛。当然如果你想针对大规模、高并发应用服务做消息中间件技术选型,譬如淘宝、京东这种大型的电商网站,尤其是双11这种特殊时间,ActiveMQ可能就显得力不从心了,当然我们这里后续还会和大家介绍其他非常优秀的MOM咯。

(3)关于消息的投递模式(PTP、P/S)

在这里插入图片描述
在这里插入图片描述

(4)ActiveMQ的各项指标

衡量一个MOM,我们主要从三方面考虑即呵,即服务性能、存储堆积能力,可扩展性。
●服务性能:ActiveMQ的性能一般,在早期传统行业为王的时代还是比较流行的,但现如今面对高并发、大数据的业 务场景,往往力不从心!
●数据存储:默认采用kahadb存储(索引文件形式存储),也可以使用高性能的google leveldb (内存数据库存储),或者可以使用MySql、Oracle进程消息存储(关系型数据库存储)。
●集群架构:ActiveMQ可以与zookeeper进行构建主备集群模型,并且多套的主备模型直接可以采用Network的方 式构建分布式集群。

(5)ActiveMQ的集群结构模型(Master-Slave、Network)

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

4.RabbitMQ集群架构模型与原理解析

待完善

5.RocketMQ集群架构与原理解析

(1)什么是RocketMQ

在这里插入图片描述

(2)RocketMQ有哪些优点

在这里插入图片描述

(3)RocketMQ的专业术语

在这里插入图片描述

(4)RocketMQ核心源码包及功能说明

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

(5)RocketMQ集群架构模型

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

6.Kafka介绍与高性能原因分析

(1)kafka简介

◆Kafka是LinkedIn开源的分布式消息系统,目前归属于Apache顶级项目
◆Kafka主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输
◆0.8版本开始支持复制,不支持事务,对消息的重复、丢失、错误没有严格要求,适合产生大量数据的互联网服务的数据收集业务

(2)kafka有哪些特点?

  • 高吞吐量:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒,支持数千个客户端同时读写
  • 持久性:消息被持久化到本地磁盘,并且支持数据备份防止数据丢失 可扩展性:kafka集群支持热扩展
  • 容错性:允许集群中节点失败(若副本数量为n,则允许n-1个节点失败)

7.kafka高性能的原因是什么?

(1)顺序写入

顺序写入的好处就是不需要消耗寻址时间,顺序写入磁盘顺序读写速度超过内存随机读写。为什么要写入磁盘?因为顺序写入 JVM 的 GC效率低,内存占用大,使用磁盘可以避免这一问题以及顺序写入系统冷启动后,磁盘缓存依然可用。即便是顺序写入硬盘,硬盘的访问速度还是不可能追上内存。所以Kafka 的数据并不是实时的写入硬盘 ,它充分利用了现代操作系统分页存储来利用内存提高 I/O 效率。

(2)Memory Mapped Files

Memory Mapped Files(后面简称mmap)也被翻译成内存映射文件。如果要读取数据,我们会将那些频繁使用的数据给他放入到这一个物理内存当中。当第一次读取数据从磁盘读取,第二次读取数据的时候直接从这个内存当中获取,大大减少了IO操作的次数,那么这一种方式实际上在计算机中被叫做是局部性原理。当我们要写入数据,会先判断数据存在磁盘中的那个页,将数据页加载到内存中,先修改内存中的数据,再把数据flush到磁盘中。通过mmap,进程感觉像读写硬盘一样读写内存。使用这种方式可以获取很大的I/O提升,省去了用户空间到内核空间复制的开销。但也有一个很明显的缺陷——不可靠,写到mmap中的数据并没有被真正的写到硬盘,操作系统会在程序主动调用flush的时候才把数据真正的写到硬盘。

(3)sendfile(零拷贝)

传统 read/write 方式进行网络文件传输的方式,我们可以看到,在这个过程当中,文件数据实际上是经过了四次 copy 操作:

在这里插入图片描述

而sendfile系统调用则提供了一种减少以上多次 copy,当文件数据被拷贝到内核缓冲区时,数据将由DMA模块直接发送到协议引擎。

在这里插入图片描述

(4)批量压缩

在很多情况下,系统的瓶颈不是CPU或磁盘,而是网络IO。进行数据压缩会消耗少量的 CPU资源, 不过对于kafka而言,
网络IO更应该需要考虑。如果每个消息都压缩,但是压缩率相对很低,所以Kafka 使用了批量压缩,即将多个消息一起压缩而不是单个消息压缩。

8.Kafka集群模型

在这里插入图片描述

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 深蓝海洋 设计师:CSDN官方博客 返回首页