Kafka

消息队列

一、概念：

消息队列:把要传输的数据放在队列中

生产者:放入数据到队列中

消费者：从队列取出数据

二、消息队列的作用：

就拿快递驿站举例，快递小哥给你打电话要你取快递,你有事走不开，双方僵持不下，最后快递小哥把快递放在快递驿站，让你下班去取,好处如下：

1. 解耦

快递小哥有很多快递，每次都要向收货人打电话确认有没有空取快递，然后再确定送货方案，这样完全依赖收货人，一旦快递多了就来不及了，有了快递驿站，快递小哥只要把快递放在驿站，通知收货人取货就好了，这时快递小哥和收货人就实现了解耦。

2. 异步

快递小哥打电话通知后一直等在楼下，直到快递送到收货人手上才能去送其他人的，这样效率很慢，有了快递驿站，就可以直接把快递放在驿站后，又可以去干其他活，双方都可以干其他事情，提高效率。

3. 削峰

假如双11买了很多东西，取货地址很分散并且同时打电话取货，这样就很麻烦，集中放在一个位置，这样就很方便。

三、消息队列的模式

一、点对点

点对点模式通常是基于拉取或者轮询的消息传送模型，这个模型的特点是发送到队列的消息被一个且只有一个消费者进行处理。生产者将消息放入消息队列后，由消费者主动的去拉取消息进行消费。点对点模型的的优点是消费者拉取消息的频率可以由自己控制。但是消息队列是否有消息需要消费，在消费者端无法感知，所以在消费者端需要额外的线程去监控。

二、发布订阅模式

发布订阅模式是发送到队列的消息可以被多个消费者进行处理，生产者将消息放入消息队列后，队列会将消息推送给订阅过该类消息的消费者（类似微信公众号）。由于是消费者被动接收推送，所以无需感知消息队列是否有待消费的消息！但是consumer1、consumer2、consumer3由于机器性能不一样，所以处理消息的能力也会不一样，但消息队列却无法感知消费者消费的速度！所以推送的速度成了发布订阅模模式的一个问题！假设三个消费者处理速度分别是8M/s、5M/s、2M/s，如果队列推送的速度为5M/s，则consumer3无法承受！如果队列推送的速度为2M/s，则consumer1、consumer2会出现资源的极大浪费！

Kafka

一、整体的工作流程图

Producer：Producer即生产者

kafka cluster：

　　　　Broker：Broker是kafka实例，每个服务器上有一个或多个kafka的实例，我们姑且认为每个broker对应一台服务器。每个kafka集群内的broker都有一个不重复的编号，如图中的broker-0、broker-1等……

　　　　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集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。

二、发送数据

一、找leader

Producer在写入数据的时候永远的找leader，不会直接将数据写入follower,如图所示

二、传入数据到分区中

producer采用push模式将数据发布到broker，每条消息追加到分区中，顺序写入磁盘，所以保证同一分区内的数据是有序的

三、分区的作用

1. 方便扩展：因为一个topic可以有多个partition，所以我们可以通过扩展机器去轻松的应对日益增长的数据量。

2. 提高并发以partition为读写单位，可以多个消费者同时消费数据，提高了消息的处理效率。

四、确定分区（负载均衡）

kafka中，如果某个topic有多个partition，producer又怎么知道该将数据发往哪个partition呢？kafka中有几个原则：

1、partition在写入的时候可以指定需要写入的partition，如果有指定，则写入对应的partition。

2、如果没有指定partition，但是设置了数据的key，则会根据key的值hash出一个partition。

1. 如果既没指定partition，又没有设置key，则会轮询选出一个partition。

五、保证数据完整性

上面的流程图就已经说明了，ACK应答机制（tcp三次握手）,在生产者向队列写入数据的时候可以设置参数来确定是否确认kafka接收到数据，这个参数可设置的值为0、1、all

0代表producer往集群发送数据不需要等到集群的返回，不确保消息发送成功。安全性最低但是效率最高。

1代表producer往集群发送数据只要leader应答就可以发送下一条，只确保leader发送成功。

all代表producer往集群发送数据需要所有的follower都完成从leader的同步才会发送下一条，确保leader发送成功和所有的副本都完成备份。安全性最高，但是效率最低。

如果往不存在的topic写数据，kafka会自动创建topic，分区和副本的数量根据默认配置都是1。

三、存储数据

kafka将数据保存在磁盘，可能在我们的一般的认知里，写入磁盘是比较耗时的操作，不适合这种高并发的组件。Kafka初始会单独开辟一块磁盘空间，顺序写入数据（效率比随机写入高）。

四、Partition 结构

Partition在服务器上的表现形式就是一个一个的文件夹，每个partition的文件夹下面会有多组segment文件，每组segment文件又包含.index文件、.log文件、.timeindex文件（早期版本中没有）三个文件， log文件就实际是存储message的地方，而index和timeindex文件为索引文件，用于检索消息。

文件的命名是以该segment最小offset来命名的,如000.index存储offset为0~368795的消息，kafka就是利用分段+索引的方式来解决查找效率的问题。

五、Message结构

消息主要包含消息体、消息大小、offset、压缩类型……等等！

1、offset：offset是一个占8byte的有序id号，它可以唯一确定每条消息在parition内的位置！

2、消息大小：消息大小占用4byte，用于描述消息的大小。

3、消息体：消息体存放的是实际的消息数据（被压缩过），占用的空间根据具体的消息而不一样。

六、数据保存

无论消息是否被消费，kafka都会保存所有的消息。对于旧数据删除策略如下：

1、基于时间，默认配置是168小时（7天）。

2、基于大小，默认配置是1073741824。

需要注意的是，kafka读取特定消息的时间复杂度是O(1)，所以这里删除过期的文件并不会提高kafka的性能！

七、消费数据

一、找leader

与生产消息相同的是，消费者在拉取消息的时候也是找leader去拉取。

二、消费者和分区交互

多个消费者可以组成一个消费者组（consumer group），每个消费者组都有一个组id

同一个消费组者的消费者可以消费同一topic下不同分区的数据，但是组内多个消费者不能消费同一分区的数据。

消费者组内的消费者小于partition数量,会出现某个消费者消费多个partition数据的情况

消费者组的消费者多于partition的数量,不会出现多个消费者消费同一个partition的数据,多出来的消费者不消费任何partition的数据。

建议消费者组的consumer的数量与partition的数量一致

三、通过segment+offset配合查找消息

segment+有序offset+稀疏索引+二分查找+顺序查找

如找offset的368801message

1、 先找到offset的368801message所在的segment文件（利用二分法查找），这里找到的就是在第二个segment文件。

2、 打开找到的segment中的.index文件（也就是368796.index文件，该文件起始偏移量为368796+1，我们要查找的offset为368801的message在该index内的偏移量为368796+5=368801，所以这里要查找的相对offset为5）。由于该文件采用的是稀疏索引的方式存储着相对offset及对应message物理偏移量的关系，所以直接找相对offset为5的索引找不到，这里同样利用二分法查找相对offset小于或者等于指定的相对offset的索引条目中最大的那个相对offset，所以找到的是相对offset为4的这个索引。

3、 根据找到的相对offset为4的索引确定message存储的物理偏移位置为256。打开数据文件，从位置为256的那个地方开始顺序扫描直到找到offset为368801的那条Message。

 

四、消费者记录自己消费的位置：

消费者消费到的offset已经直接维护在kafk集群的__consumer_offsets这个topic中。