kafka一些知识点

一、初识kafka
1.1、Topic：
Topic好比文件夹，一个Topic可以被分为若干个分区，一个分区就是一个提交日志。在每个分区中消息以先入先出的顺序读取，由于一个主题一般包含若干个分区，因此无法在整个主题中保证消息的顺序。分区可以分布在不同的服务器上。

1.2、Producer：

1.3、Consumer：
消费者通过检查消息的偏移量来区分已经读取过的消息，偏移量是一个不断递增的整数值，在创建消息时，kafka会把它添加到消息里。在给定的分区里每个消息的偏移量都是唯一的，Consumer把每个分区最后读取的消息偏移量保存在Zookeeper或者Kafka上，如果消费者关闭或者重启，它的读取状态不会丢失。

1.4、Broker消息保留策略
保留消息是kafka的一个重要特性，kafka broker的消息保留策略是这样的：要么保留一段时间，要么保留到消息达到一定大小的字节数，当消息达到这些上限时，旧消息就会过期并被删除。

1.5、多集群
当数据类型分离或者安全需求隔离时，建议使用kafka多集群，kafka的消息复制机制只能在单集群中进行，不能在多个集群中进行。kafka提供了一个叫MirrorMaker的工具，可以用它来实现多集群的复制，MirrorMaker的核心组件包含一个生产者和消费者，两者之间通过一个队列相连

二、消费者
1、消息轮询是消费者API的核心，通过一个简单的轮询向服务器请求数据，轮询就会处理所有的细节，包括群组协调、分区再均衡、发送心跳和获取数据。

偏移量的提交分为同步、异步、组合，其中同步提交又分自动和手动。
2.1 同步提交偏移量：Consumer提供了很多的方式提交偏移量，如果enable.auto.commit被设置为了true，那么每过5s，消费者会自动把从poll()方法接收到的最大偏移量提交上去。提交的时间间隔可以配置。但是假设我们仍然使用默认的5s提交时间间隔，它最近提交之后的3s发生了再均衡，消费者从最后一次提交偏移量的地方开始读取，这个时候偏移量其实已经落后的3s，所以再这三秒内到达的消息会被重复处理，这是自动提交的一个问题。解决这个问题的方法是在必要的时候手动提交偏移量，auto.commit.offset设置为false，让应用程序去决定何时提交偏移量，使用commitSync()最可靠。

2.2、异步提交偏移量
同步提交的不足之处在于在提交的时候在broker对提交请求做出回应之前，应用程序会一直阻塞，这样会限制应用程序的吞吐量，这个时候可以使用异步提交API，我们只管发送提交请求，无需等待broker响应。consumer.commitAsyc()。在做异步提交偏移量的时候，最好检测重试异步提交，我们可以使用一个单调递增的序列号来维护异步提交的顺序，在每次提交偏移量之后或者回调里提交偏移量时递增序列号。在进行重试前先检查回调的序列号和即将提交的偏移量是否相等，如果相等说明没有新的提交，如果序列号比较大，说明已经有一个新的提交已经发送出去了，应该停止重试。

2.3、同步和异步组合

2.4、再均衡监听器
ConsumerRebalanceListener有两个需要实现的接口：
(1)public void onPartitionsRevoked(Collection partitions),这个方法会在再均衡开始之前和消费者停止读取消息之后被调用。可以在这里提交偏移量
(2)public void onPartitionsAssigned(Collection partitions),方法会在重新分配分区之后和消费者开始读取消息之前被调用。

2.5、从特定偏移量处开始处理记录
seek()跳转到指定的偏移量开始读取记录

三、深入理解kafka
3.1、复制功能
复制功能是kafka架构的核心，follower主动从leader那里复制消息。
leader：每个分区都会有一个leader。为了保证一致性，所有生产者请求和消费者请求都会经过这个leader
follower：leader以外的副本都是follower副本，follower不处理任何请求，它们唯一的任务就是从leader那里复制消息，如果leader崩溃，那么其中一个follower会晋升为一个新leader
leader还有一个任务就是搞清楚哪一个follower和自己的状态是一致的。其实就是默认在ISR中如果延迟不超过3条消息(默认值)的都算同步，超过3的就会从ISR中踢除，当然也可以根据响应时间来踢除不同步的follower。

3.2、kafka零复制功能
如果consumer请求的偏移量存在，broker将按照客户端指定的数量上限从分区里读取消息，再把消息返回给客户端。kafka使用零复制技术向客户端发送消息。也就是说kafka直接把消息从文件里发送到网络通道，而不经过中间缓冲区。这就是kafka与其他大部分数据库系统不一样的地方，其他数据库将数据发送给客户端之前会先把它们保存在本地缓存里。零复制技术避免了字节复制，也不需要管理内存缓冲区，从而获得了更好的性能。

3.3、文件管理、日志清除
(1)Log Deletion
保留数据是kafka的一个基本特性，kafka不会一直保留数据，kafka管理员为每个主题配置了数据保留期限，规定了数据被删除之前可以保留多长时间，或者清理数据之前可以保留的数据量大小。需要注意每个分区都有若干个segments，在broker往分区写入数据时，如果达到segments上限，就关闭当前文件，打开一个新的，正在写入的数据片段叫活跃片段，活跃片段永远不会删除。
(2)Log Compaction
Kafka中的Log Compaction是指在默认的日志删除（Log Deletion）规则之外提供的一种清理过时数据的方式。如下图所示：

我们怎么对日志文件中消息的key进行筛选操作呢？Kafka中的每个日志清理线程会使用一个名为“SkimpyOffsetMap”的对象来构建key与offset的映射关系的哈希表。日志清理需要遍历两次日志文件，第一次遍历把每个key的哈希值和最后出现的offset都保存在SkimpyOffsetMap中，映射模型如下图所示。第二次遍历检查每个消息是否符合保留条件，如果符合就保留下来，否则就会被清理掉。
Log Compaction会为我们保留key相应的最新value值，那么当我们需要删除一个key怎么办？Kafka中提供了一个墓碑消息（tombstone）的概念，如果一条消息的key不为null，但是其value为null，那么此消息就是墓碑消息。日志清理线程发现墓碑消息时会先进行常规的清理，并保留墓碑消息一段时间。

四、kafka数据可靠性
kafka数据的可靠性是复制机制保证的，需要注意的是kafka跨集群的复制工具叫mirrorMaker