深圳做网站的价格,大型免费网站制作,商务网站是什么,合肥做网站一般多少钱1. MQ简介
1.1 MQ的诞生背景 以前网络上的计算机#xff08;或者说不同的进程#xff09;传递数据#xff0c;通信都是点对点的#xff0c;而且要实现相同的协议#xff08;HTTP、 TCP、WebService#xff09;。1983 年的时候#xff0c;有个在 MIT 工作的印度小伙突发…1. MQ简介
1.1 MQ的诞生背景 以前网络上的计算机或者说不同的进程传递数据通信都是点对点的而且要实现相同的协议HTTP、 TCP、WebService。1983 年的时候有个在 MIT 工作的印度小伙突发奇想能不能发明一种专门用来通 信的中间件就像主板BUS一样把不同的软件集成起来呢于是他搞了一家公司Teknekron开发 了世界上第一个消息队列软件 The Information Bus(TIB)。 1.2 什么是MQ
MQ全称是Message Queue,直译过来叫消息队列在消息的传输中用于保存消息的容器主要是作为分布式应用之间实现异步通信的方式。
主要由三部分组成分别是 生产者、消息服务端和消费者 生产者 Producer 是生产消息的一端相当于消息的发起方主要负责载业务信息的消息的创建。 消息服务端 Server 是处理消息的单元本质就是用来创建和保存消息队列它主要负责消息的存储、投递以及跟消息队列相关的附加功能。消息服务端是整个消息队列最核心的组成部分。 第三个是消费者 Consumer 是消费消息的一端主要是根据消息所承载的信息去处理各种业务逻辑。 何为生产者? 何为消息队列?何为消费者? 举个例子如下图,第一阶段是爸爸点对点的把书送到儿子手中即为我们的点对点通信但后面爸爸发现这种方式即耗时又费力因此买了个书架每次只用把书放到书架上就行了儿子在规定时间内去学完就可以了后面妈妈也发现了这个好处于是她也向书架中放书小明的姐姐也可以去书架上消费。爸爸妈妈就是我们的生产者书架就是一个消息队列小明以及小明的姐姐就是消费者。 1.3 MQ的应用场景
1.3.1 应用解耦
由上图可以看出后面引入了书架后爸爸就不需要单独给小明书了因此这是一种应用的解耦。比如我们下面的例子订单系统模块直接调用库存系统模块依赖性太强当某天库存系统出问题时连带的订单系统模块就也有问题了我们引入了MQ以后订单系统只用把消息发布到MQ即可不管库存系统暂时有没有问题等它没有问题的时候再去MQ中订阅消息 1.3.2 异步提速
如下图所示没有使用MQ之前。用户注册发送邮件发送短信是同步的总耗时300ms,而引入MQ之后用户注册后只用把消息发送给MQ然后MQ异步分别发送注册邮件和发送注册短信注册成功的总耗时就只有110ms.因此MQ可以起到异步提速的作用 1.3.3 限流削峰
几个例子大家都去饭店吃过饭把当饭店特别火爆的时候店长怎么处理了肯定是不会让你滚蛋把而是给你一个票进行排队那么这些排队的方式就是一个削峰的场景排队的这些号码就是我们的MQ也就是说当没有MQ的时候我们的服务器处理能力有限当请求全部涌入进来时就会造成服务器极大的压力甚至承受不住。当我们引入MQ之后就可以先把这个请求放到MQ中服务器根据自己的处理能力去MQ中拿。 2. Kafka重要组件
kafka是MQ的一种基于TCP的二进制协议。内部是通过长度来分隔。单机吞吐量支持十万级别。时效性延迟在ms级以内高可用性kafaka是分布式的一个数据多个读本少数机器宕机不会丢失数量不会导致不可用。经过参数的优化配置消息可以做到0丢失。功能上较为简单主要支持简单的MQ功能在大数据领域的实时计算以及日志采集被大规模使用。那么kafaka由哪些组件组成的呢?
2.1 Broker 1.Broker就是Kafka的服务器用于存储和管理消息默认是9092的端口 2.生产者和Broker建立连接将消息发送到服务器上、存储起来 3.消费者跟Broker建立连接订阅和消费服务器上存储的消息 2.2 Record 1.客户端之间传输的数据叫做消息在Kafka中也叫Record记录 2.Record在客户端中是一个KV键值对ProducerRecord、ConsumerRecord 3.Record在服务端中的存储格式也是KV键值对RecordBatch 或 Record 2.3 Rroducer 1.发送消息的一方叫做生产者 2.Kafka为提升消息发送速率生产者默认采用批量发送的方式发送消息至Broker 3.Kafka为提升消息发送速率生产者默认采用批量发送的方式发送消息至Broker 2.4 Consumer 1. 订阅、接收消息的一方叫做消费者 2. 消费者端获取消息有两种模式Pull模式[拉]、Push模式[推] 3. Pull模式消费者可以自己控制一次到底获取多少条消息max.poll.records 2.5 Topic 在Broken中会采用topi主题的方式用来划分不同的业务线 1. Topic主题是一个逻辑概念可以理解为一组消息的集合 2. 生产者和消费者通过Topic进行消息的写入和读取 3. 生产者发送消息时若Topic不存在是否自动创建auto.create.topics.enable(但一般禁用因为不便于维护) 2.6 Partition
在一个topic中当数据量特别大的时候就会极大的影响我们的查询效率就好比mysql的分库分表因此在kafka中也引入了一个partition分区的这样的一个概念从而提升查询效率也实现了消息的负载均衡。 1. 所谓分区Partition就是把一个Topic分成几个不同的部分 2. 一个Topic可以在创建时划分成多个分区 3. 若没有指定分区数默认分区数为1通过参数可修改num.partitions 4. Kafka中修改分区的规则可加、不可减 可以指定以下参数进行配置 为不同的topic主题配置对应的partition分区 ./kafka-topics.sh --create --topic TopicA --bootstrap-server 192.168.61.100:9092 --replication-factor 1 --partitions 3 ./kafka-topics.sh --create --topic TopicB --bootstrap-server 192.168.61.100:9092 --replication-factor 1 --partitions 3 2.7 Replica机制(副本机制) partition虽然实现了消息的负载但还是在一台服务器上并没有实现真正意义上的负载均衡因此引入了replica副本机制实现真正的负载均衡 1. Replica副本是Partition分区的副本每个分区可以有若干个副本 2. 副本必须在不同的Broker节点上副本包括了主从节点Leader、Follower 3. 服务端可以通过参数控制默认副本数offsets.topic.replication.factor 副本的配置可以通过replication-factor参数指定 sh kafka-topics.sh --create --topic TopicA --bootstrap-server 192.168.61.100:9092 --replication-factor 3 --partitions 3 2.7 Segment
每一个partition里面都有一个log文件当这个文件越来越大的时候也会影响查询效率因此kafka又引进了一个segment段的概念来提升查询的效率。 1.Segment段的目的是将一个分区中的数据划分、存储到不同的文件中 2.每个 Segment 至少由 1 个数据文件和 2 个索引文件构成 3 个文件是成套出现的 3.引入段带来的意义: 3.1 加快查询效率 3.2 删除数据时减少逐条 IO 4. Segment 大小控制 4.1 按时间周期生成 log.roll.hours 4.2 按文件大小生成 log.segment.bytes 2.8 Consumer Group
假设生产者生产消息速度很快。势必就会造成大量的消息堆积入口快对应的出口就也很快因此需要采用一些策略来提升消息的消费速率假设我没用消费者组则来了几个消费者我们怎么直到要消费这个主题topic呢所以才有了消费者组的概念让这个组去订阅这个主题。 1. 使用消费者组提升消费效率和吞吐量 2. 同一个Group中的消费者不能消费相同的Partitiongroup id相同在一个组中 2.9 Cunsumer Offset 在kafka中消息消费完后并不会立即删除假设我们消费完前面的两个消息后服务节点挂了我们再次重启服务的时候是不是希望从第3个节点开始消费于是就引入了偏移量consumer offset。 Offset偏移量的目的在于记录消费者的消费位置 Kafka 现行版本将 Offset 保存在服务器 __consumer_offsets 主题中 3. Kafka整体架构 从第2章我们简单了解到了kafka的各个组件以及各个组件的基本作用那么kafka的一个整体架构是怎么样的呢?
生产者producer向broker中的topic发送消息消息的存储会有一个主分区叫做leader实现负载均衡消息分别保存在不同服务器的leader上面然后在另外的两个服务器上有两个副本叫做follow由leader异步同步数据到follow中保证了数据的可靠性。consumer端又分为不同的group每个group中的消费者去这些分区中订阅。
4. Kafka特性
kafa要想保证消息的可靠性就必须落到磁盘中那么既然kafka是要跟磁盘进行IO的那又是如何保证高吞吐低延迟的呢? 主要有以下4个特性
磁盘顺序IO索引批量读写和压缩算法零拷贝
4.1 磁盘顺序IO
磁盘随机IO和磁盘顺序IO 如下图磁盘交互的主要时间消耗主要在磁盘选址中。磁盘的构成如上图所示是一个个的扇区和磁道构成的随机IO的数据存储是分散性的因此选址比较浪费时间而磁盘顺序IO是几种存储追加的形式一旦确定了一个物理地址后面的存储就在这个物理地址后面追加因此寻址的时候可能只需要一次寻址就可以了。磁盘顺序IO的读写速度是不逊于内存读写的。
4.2 索引 Broker 端原理数据存储 Offset 索引、时间戳索引、稀疏索引 4.3 批量处理和压缩传递 收发消息时批量处理 压缩算法进行压缩后传递 4.4 零拷贝
在了解零拷贝前我们先来看一个传统的IO 我们直到在计算机层面是会分为用户态和内核态的这主要是为了保护操作系统防止用户空间的进程操作到内核中。有了这么的一个概念我们从用户程序中读写磁盘的数据就难免要去与内核空间进行交互那么传统的交互方式是怎么样的呢?
我们从用户空间出发会先进行read从内核空间中读取。内核空间中的磁盘数据经由DMA拷贝到内核态中然后会在经过PU拷贝到用户态中用户态在经过拷贝到网络的sockect缓冲区随后DMA拷贝到网卡中也就是我们的网络交互传输的一个IO设备中。可以看到传统的io形式经历了4次的用户态与内核态的交互会大大的降低响应速度。因此kafak引入了一个零拷贝的技术。 直接从内核态的内核缓冲区经SG-DMA拷贝到网卡中。
5. 总结 本文主要从宏观的角度上介绍了消息队列MQ的背景、原理以及应用场景。随后分析了现在主流的MQ技术的落地Kafka先是认识了kafka的各个组件整体架构设计还有kafak能够实现高吞吐低延时的一些保证特性先大概有个整体的认识随后会对每个模块进行详细的展开阐述以及原理分析。
