消息中间件特点
- 解耦
- 异步
- 削峰
消息队列通信模式
1.点对点模式
2.发布订阅模式
kafka
基本概念
从图上可以看到可以分四个部分:
- Producer:消息生产者,消息入口。
- kafka cluster:kafka集群。
- broker:broker是kafka实例,每个服务器上可以有一个或者多个broker。
- topic:消息的主题,kafka的数据就是保存在topic。每个broker上都可以创建多个topic。
- partition:topic的分区,每个topic可以有多个分区,分区的作用就是负载,提高kafka的吞吐量。同一个topic在不同的分区数据是不重复的,partition的表现形式就是一个一个文件夹。
- Replication: 每一个分区都有多个副本,副本的作用是做备胎。当主分区(Leader)故障的时候会选择一个备胎(Follower)上位,成为Leader。在kafka中默认副本的最大数量是10个,且副本的数量不能大于Broker的数量,follower和leader绝对是在不同的机器,同一机器对同一个分区也只可能存放一个副本(包括自己)。
- message:每一条消息的主体。
- consumer:消息消费者,消息出口
- consumer Group:多个消费者组成一个消费者组,在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据,也是为了提高kafka的吞吐量。
- zookeeper:kafka集群用于保存集群元数据信息,保证系统可用性。
工作流程分析
发送数据
下面看下发送流程
注意一点,消息写入leader后,follower是主动的去leader进行同步的,producer采用push的模式将数据发布到broker,每条消息追加到分区中,顺序写入磁盘,所以保证同一分区内的数据是有序的。具体如下图:
上图可以看到数据会写到不同的分区,那kafka为什么要做分区?
- 方便扩展。因为一个topic可以有多个partition,所以我们可以扩展机器去轻松的应对日益增长的数据量。
- 提高并发。以partition为读写单位,可以多个消费者同事消费数据,提高了消息的处理效率。
那么当我们向某个服务器发送请求的时候,服务端需要一个负载,把流量分发到不同的服务器上,kafka的topic有多个partition,producer如果发送数据到对应的partition呢?
有3个原则:
- partition在写入时可以指定写入patition,如果指定则写入对应patition中。
- 如果没有指定patition,但是设置了数据的key,则会根据key的值hash出一个partition。
- 如果没有指定patition,也没设置数据的key,则会轮询一个partition。
保证消息不丢失是一个消息队列中间件的基本保证,那producer在向kafka写入消息的时候,怎么保证消息不丢失呢?其实上面的写入流程图中有描述出来,那就是通过ACK应答机制!在生产者向队列写入数据的时候可以设置参数来确定是否确认kafka接收到数据,这个参数可设置的值为0、1、all。
- 0,代表producer往集群发送数据不需要等到集群的返回,不确保消息发送成功。安全性最低但是效率最高。
- 1,代表producer往集群发送数据只要leader应答就可以发送下一条,只确保leader发送成功。
- all,代表producer往集群发送数据需要所有的follower都完成从leader的同步才会发送下一条,确保leader发送成功和所有的副本都完成备份。安全性最高,但是效率最低。
如果往不存在的topic写数据,能不能写入成功呢?
kafka会自动创建topic,分区和副本的数量根据默认配置都是1。
保存数据
Producer将数据写入kafka后,集群就需要对数据进行保存,kafka将数据保存在磁盘,一般写入磁盘是比较耗时的操作,不适合这种高并发的组件。Kafka初始会单独开辟一块磁盘空间,顺序写入数据(效率比随机写入高)。
Partition 结构
前面说过了每个topic都可以分为一个或多个partition,Partition在服务器上的表现形式就是一个一个的文件夹,每个partition的文件夹下面会有多组segment文件,每组segment文件又包含.index文件、.log文件、.timeindex文件(0.8之前版本中没有)三个文件, log文件就实际是存储message的地方,而index和timeindex文件为索引文件,用于检索消息。
如上图,这个partition有三组segment文件,每个log文件的大小是一样的,但是存储的message数量是不一定相等的(每条的message大小不一致)。文件的命名是以该segment最小offset来命名的,如000.index存储offset为0~368795的消息,kafka就是利用分段+索引的方式来解决查找效率的问题。
有2个参数需要了解:
- segment.bytes:topic文件是以segment文件进行存储的,该参数控制segment文件的大小,默认值为1073741824(10G)。
- segment.index.bytes:对于segment索引文件的大小限制,默认为10M
kafka时间戳的作用
- 基于时间戳的日志切分策略
- 基于时间戳的日志清除策略
- 根据时间戳来定位消息:之前的索引文件是根据offset信息的,从逻辑语义上并不方便使用,引入了时间戳之后,Kafka支持根据时间戳来查找定位消息
segment file文件物理关系
对segment file文件为例,说明segment中index<—->data file对应关系物理结构如下:
从上图可以看到 kafka的优化:其中以索引文件中元数据3,497为例,依次在数据文件中表示第3个message(在全局partiton表示第368772个message)、以及该消息的物理偏移地址为497。
索引文件包含若干索引条目,每个条目表示数据文件中一条Meaasge的索引。
索引包含2个部分(均为4个字节的数字),分别为相对offset和position。注意索引文件中的position 不是消息的offset, 而是message在segment中的物理位置。
可以看到索引有个优化点:稀疏索引,每隔一定字节的数据建立一条索引。
Message结构
上面说到log文件就实际是存储message的地方,我们在producer往kafka写入的也是一条一条的message,那存储在log中的message是什么样子的呢?消息主要包含消息体、消息大小、offset、压缩类型……等等!我们重点需要知道的是下面三个:
- offset:offset是一个占8byte的有序id号,它可以唯一确定每条消息在parition内的位置!
- 消息大小:消息大小占用4byte,用于描述消息的大小。
- 消息体:消息体存放的是实际的消息数据(被压缩过),占用的空间根据具体的消息而不一样。
存储策略
无论消息是否被消费,kafka都会保存所有的消息,对于旧数据有什么删除策略呢?
- 基于时间,默认配置168小时(7天)
- 基于大小,默认配置1073741824 byte(128M)
因为kafka读取特定消息的时间复杂度是o(1),所以这里删除过期的文件并不会提高kafka性能。
消费数据
消息存储在log文件后,消费者就可以进行消费了,与生产消息相同,消费者在拉取消息时也是通过leader去获取。
多个消费者可以组成一个消费者组(consumer group),每个消费者组都有一个组id!同一个消费组者的消费者可以消费同一topic下不同分区的数据,但是不会组内多个消费者消费同一分区的数据。其实就是 partition 与 consumer 是 多对一的关系。
图示是消费者组内的消费者小于partition数量的情况,所以会出现某个消费者消费多个partition数据的情况,消费的速度也就不及只处理一个partition的消费者的处理速度!如果是消费者组的消费者多于partition的数量,那会不会出现多个消费者消费同一个partition的数据呢?上面已经提到过不会出现这种情况!多出来的消费者不消费任何partition的数据。所以在实际的应用中,建议消费者组的consumer的数量与partition的数量一致!
在保存数据的小节里面,partition划分为多组segment,每个segment又包含.log、.index、.timeindex文件,存放的每条message包含offset、消息大小、消息体…,上文多次提到segment和offset,查找消息的时候是怎么利用segment+offset配合查找的呢?假如现在需要查找一个offset为368801的message是什么样的过程呢?我们先看看下面的图:
- 先找到offset的368801message所在的segment文件(利用二分法查找),这里找到的就是在第二个segment文件。
- 打开找到的segment中的.index文件(也就是368796.index文件,该文件起始偏移量为368796+1,我们要查找的offset为368801的message在该index内的偏移量为368796+5=368801,所以这里要查找的相对offset为5)。由于该文件采用的是稀疏索引的方式存储着相对offset及对应message物理偏移量的关系,所以直接找相对offset为5的索引找不到,这里同样利用二分法查找相对offset小于或者等于指定的相对offset的索引条目中最大的那个相对offset,所以找到的是相对offset为4的这个索引。
- 根据找到的相对offset为4的索引确定message存储的物理偏移位置为256。打开数据文件,从位置为256的那个地方开始顺序扫描直到找到offset为368801的那条Message。
这套机制是建立在offset为有序的基础上,利用segment+有序offset+稀疏索引+二分查找+顺序查找等多种手段来高效的查找数据!至此,消费者就能拿到需要处理的数据进行处理了。那每个消费者又是怎么记录自己消费的位置呢?在早期的版本中,消费者将消费到的offset维护zookeeper中,consumer每间隔一段时间上报一次,这里容易导致重复消费,且性能不好!在新的版本中消费者消费到的offset已经直接维护在kafk集群的__consumer_offsets这个topic中!