kakfka入门基础

一。优势：

1. 高吞吐量：单机每秒处理几十上百万的消息量。即使存储了许多TB的消息，它也保持稳定的性能。
2. 高性能：单节点支持上千个客户端，并保证零停机和零数据丢失。
3. 持久化数据存储：将消息持久化到磁盘。通过将数据持久化到硬盘以及replication防止数据丢失。
4. 零拷贝
5. 顺序读，顺序写
6. 利用Linux的页缓存
7. 分布式系统，易于向外扩展。所有的Producer、Broker和Consumer都会有多个，均为分布式的。无需停机即可扩展机器。多个Producer、Consumer可能是不同的应用。
8. 可靠性 - Kafka是分布式，分区，复制和容错的。
9. 客户端状态维护：消息被处理的状态是在Consumer端维护，而不是由server端维护。当失败时能自动平衡。
10. 支持online和offline的场景。
11. 支持多种客户端语言。Kafka支持Java、.NET、PHP、Python等多种语言

二。组成部分
1.Producer：生产者创建消息
该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的 segment 文件中。
一般情况下，一个消息会被发布到一个特定的主题上。

1.1. 默认情况下通过轮询把消息均衡地分布到主题的所有分区上。
1.2. 在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分
区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同
一个分区上。
1.3.生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。

2.Consumer：消费者读取消息。
2.1. 消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。
2.2. 消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka 会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在Zookeeper 或Kafka上，如果消费者关闭或重启，它的读取状态不会丢失。
2.3. 消费者是消费组的一部分。群组保证每个分区只能被一个消费者使用。
2.4. 如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作，再平衡，分区重新分配

3.Broker:一个独立的Kafka 服务器被称为broker。
broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。

3.1. 如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。 
3.2. 如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个
partition，剩下的M个broker不存储该topic的partition数据。
3.3. 如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个
partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。 

broker 是集群的组成部分。每个集群都有一个broker 同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。控制器负责管理工作，包括将分区分配给broker 和监控broker。在集群中，一个分区从属于一个broker，该broker 被称为分区的首领。

4.Topic

每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
物理上不同Topic的消息分开存储。
主题就好比数据库的表，尤其是分库分表之后的逻辑表。

5.Partition

5.1. 主题可以被分为若干个分区，一个分区就是一个提交日志。
5.2. 消息以追加的方式写入分区，然后以先入先出的顺序读取。
5.3. 无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。
5.4. Kafka 通过分区来实现数据冗余和伸缩性。
5.5. 在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

6.Replicas
Kafka 使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本。那些副本被保存在broker 上，每个broker 可以保存成百上千个属于不同主题和分区的副本。
副本有以下两种类型：

6.1.首领副本
每个分区都有一个首领副本。为了保证一致性，所有生产者请求和消费者请求都会经过这个副本。
6.2.跟随者副本
首领以外的副本都是跟随者副本。跟随者副本不处理来自客户端的请求，它们唯一的任务就是从首领那	
里复制消息，保持与首领一致的状态。如果首领发生崩溃，其中的一个跟随者会被提升为新首领。

7.Offset

7.1生产者Offset
消息写入的时候，每一个分区都有一个offset，这个offset就是生产者的offset，同时也是这个分区的最新最大的offset。
有些时候没有指定某一个分区的offset，这个工作kafka帮我们完成。

7.2消费者Offset
这是某一个分区的offset情况，生产者写入的offset是最新最大的值是12，而当Consumer A进行消费
时，从0开始消费，一直消费到了9，消费者的offset就记录在9，Consumer B就纪录在了11。等下一次
他们再来消费时，他们可以选择接着上一次的位置消费，当然也可以选择从头消费，或者跳到最近的记
录并从“现在”开始消费

三。过程及原理
1.消息的发送与接收
生产者主要的对象有： KafkaProducer ， ProducerRecord 。
其中 KafkaProducer 是用于发送消息的类， ProducerRecord 类用于封装Kafka的消息。
KafkaProducer 的创建需要指定的参数和含义：
bootstrap.servers：配置生产者如何与broker建立连接。该参数设置的是初始化参数。如果生产者需要连接的是Kafka集群，则这里配置集群中几个broker的地址，而不
是全部，当生产者连接上此处指定的broker之后，在通过该连接发现集群
中的其他节点。
key.serializer：要发送信息的key数据的序列化类。设置的时候可以写类名，也可以使用该
类的Class对象。
value.serializer：要发送消息的alue数据的序列化类。设置的时候可以写类名，也可以使用该类的Class对象。
acks：默认值：all。
acks=0：
生产者不等待broker对消息的确认，只要将消息放到缓冲区，就认为消息已经发送完成。
该情形不能保证broker是否真的收到了消息，retries配置也不会生效。发送的消息的返回的消息偏移量永远是-1。
acks=1
表示消息只需要写到主分区即可，然后就响应客户端，而不等待副本分区的确认。在该情形下，如果主分区收到消息确认之后就宕机了，而副本分区还没来得及同步该消息，则该消息丢失。
acks=all
首领分区会等待所有的ISR副本分区确认记录。该处理保证了只要有一个ISR副本分区存活，消息就不会丢失。这是Kafka最强的可靠性保证，等效于 acks=-1
retries：retries重试次数
当消息发送出现错误的时候，系统会重发消息。跟客户端收到错误时重发一样。如果设置了重试，还想保证消息的有序性，需要设置MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION=1
否则在重试此失败消息的时候，其他的消息可能发送成功了，其他参数可以从 org.apache.kafka.clients.producer.ProducerConfig 中找到

原理：
KafkaProducer有两个基本线程：
主线程：
负责消息创建，拦截器，序列化器，分区器等操作，并将消息追加到消息收集器
RecoderAccumulator中；消息收集器RecoderAccumulator为每个分区都维护了一个
Deque 类型的双端队列。ProducerBatch 可以理解为是 ProducerRecord 的集合，批量发送有利于提升吞吐量，降低网络影响；由于生产者客户端使用 java.io.ByteBuffer 在发送消息之前进行消息保存，并维护了一个 BufferPool 实现 ByteBuffer 的复用；该缓存池只针对特定大小（ batch.size指定）的 ByteBuffer进行管理，对于消息过大的缓存，不能做到重复利用。每次追加一条ProducerRecord消息，会寻找/新建对应的双端队列，从其尾部获取一个ProducerBatch，判断当前消息的大小是否可以写入该批次中。若可以写入则写入；若不可以写入，则新建一个ProducerBatch，判断该消息大小是否超过客户端参数配置 batch.size 的值，不超过，则以 batch.size建立新的ProducerBatch，这样方便进行缓存重复利用；若超过，则以计算的消息大小建立对应的 ProducerBatch 。缺点就是该内存不能被复用了。
Sender线程：
该线程从消息收集器获取缓存的消息，将其处理为 <Node, List 的
形式， Node 表示集群的broker节点。进一步将<Node, List转化为<Node, Request>形式，此时才可以向服务端发送数据。在发送之前，Sender线程将消息以 Map<NodeId, Deque> 的形式保存到InFlightRequests 中进行缓存，可以通过其获取 leastLoadedNode ,即当前Node中负载压力最小的一个，以实现消息的尽快发出。