kafka是一个优秀大吞吐消息队列，下面我就从实用的角度来讲讲kafka中，“kafka为何有大吞吐的机制”，“数据不丢失问题”，“精准一次消费问题”

01、kafka的架构组织和运行原理

kafka集群各个节点的名称叫broker，因为kafka是一个消息队列，所以对应着有producer和consumer。在数据组织层面来说，kafka是通过topic来区分同一类数据，但是topic是抽象的概念，具体组织数据的Partition，它是物理的文件，topic中的数据会具体落在各个Partition中，一个Partition的数据又有多个segment组成，segment也是抽象的，segment中包含了log和index文件，这才是kafka具体存储数据的文件。

02、kafka为什么能实现低延迟高吞吐

kafka通过如下的技术实现它的低延迟高吞吐

• Zero Copy（零拷贝） 技术

  • kafka的零拷贝技术在代码层面是调用Java的NIO包下的FileChannel实现，其中的transferTo()方式是具体实现零拷贝方法。

  零拷贝的具体实现需要操作系统和硬件的支持，在Linux中上述的transferTo方法最终会调用到底层的sendfile方法实现，如下图sendfile方法只需要进行2次“上下文切换”和2次的DMA数据拷贝即可完成数据的读写操作（对应kafka的数据生产和消费）（DMA：它是一种无须CPU参与就能直接把内存数据和外设数据进行交换的设备，是CPU读写大批量数据的一种替代设备）

  

• Page Cache（页缓存）+ 磁盘顺序读写

  • 当数据写入磁盘的时，数据会被先写入Page Cache，一般操作系统是按照4kb划分一个Page，根据一定机制，再把一批Page刷到磁盘中，这样就会有一批生产者产生的数据其实还是在操作系统内存中的，此时如果consumer在拉取数据，直接从Page Cache中就能拿到，如果生产者和消费者的速率差不多的情况下，kafka相当于是基于内存在读写数据
  • 而且kafka在flush到磁盘的时候，数据是按照磁盘顺序读写，这样也大大提升了刷写的速度。

• 分区分段 + 索引

  • kafka中通过Partition把topic中的数据分成若干份放入broker中，在Partition中数据其实是按照一个个小的segment存储的，这也非常符合很多分布式系统的分区分桶的思路。
  • 与此同时，kafka也给一个个segment建立了稀疏索引文件，也就是哪些xxxx.index和xxxx.timestapindex文件

• 批量读写

  • 同时kafka在读写的时候也都是按照批操作的，这样相对于单条处理来说减少了不必要的额外传输开销

• 批量压缩

  • 压缩可以通过减少message的体积，使数据在网络传输时得到很大优化

03、kafka中如何实现CAP原则

CAP 原则是指在一个分布式系统中，对于，一致性，可用性和分区容忍性，是不能同时满足的，总的来说kafka不是严格的只实现CAP原则中的某两个放弃其中一个，它是一种动态的平衡

• kafka通过多副本的ISR机制实现分区容忍性
  • kafka对于每个topic会提供多个一模一样的副本，然后在这些副本中选出一个leader来对外提供读写服务。其中这些正常的副本会在一个ISR的集合中，如果其中一个副本挂掉就会被踢出ISR，但是服务正常可用，如果是leader挂掉，此次会根据配置让ISR中的副本选举出新的leader对外提供服务，这里就牺牲了系统的可用性
• kafka通过高水位机制实现数据的一致性
  • kafka通过牺牲follow副本的可用性，只允许leader副本对外提供读写服务来提高数据的一致性，这在一致性的实现上简单很多。
  • 具体来说kafka是通过只对外提供高水位以下的数据访问，从而实现各个副本之间数据的最终一致性。

  在版本的kafka中，高水位机制会出现丢数据和数据不一致的情况，在高版本中通过epoch机制修复了这样的问题。

• kafka对于可用性来说没有做到那么严格，比如leader副本所在的机器有问题，对应的topic短暂不可用一直要到新的leader选举成功才行

04、数据不丢失的具体实现

• broker端：
  • 通过配置不能让落后太多的副本参加leader的选举（unclean.leader.election.enable = false）
  • 开启配置多个副本（replication.factor > 1）
• producer端：
  • ack设置为-1或是all（pro.put(ProducerConfig.ACKS_CONFIG,“all”)）
  • send方法中一定要用带返回值的，如果失败了可以及时的得到通知或是做出相应的策略
• consumer端
  • offset的提交设置为手动提交

05、kafka中的消费者组及相关问题

kafka的consumer在消费topic数据的时候是通过group的方式消费的
group中还有一个rebalance的过程，它是为了更好的把消费者分配到分区中消费数据存在的，rebalance机制运行起来的时候，所有的消费者都会暂停工作 ，对系统有比较大的影响

• group的作用
  • 隔离不同group中消费者的互相影响，实现kafka消息的订阅模式
• group中消费数据特点
  • 一个Partition只能让同一个group中的一个消费者来消费（为了保证分区中数据的顺序性），一般情况下一个分区分配一个消费者去消费即可，也会出现一个消费者同时消费多个分区的情况
• group的中consumer的分配和管理
  • 它是通过rebalance机制来分配和管理，rebalance机制会把group中的每个消费者分配到对应的topic的Partition中进行消费，如果其中一个消费者挂了，它会从新分配一个新的过来消费，有新的消费者加入会给它分配对应的分区消费
• rebalance机制的问题
  • 在rebalance机制运行的过程中，group中的所有消费者都会停下来不消费参加rebalance，这就会给系统带来一定时间的停摆
• rebalance机制产生的条件和应对
  • group中consumer数量发生变化时，订阅的topic发生变化时，订阅的topic的Partition发生变化时，这三种情况下都会触发rebalance机制
  • rebalance机制如果不是频繁发生的话是一种正常现象，
• 非正常情况下减少rebalance触发
  • 例如，consumer没有及时发送心跳请求导致误以为对应的consumer挂掉，还有consumer处理数据时间过长导致被踢出group，这些都是非正常情况
  • 可以根据自己业务运行时间调整调大，heartbeat.intgerval.ms，session.timeout.ms,max.poll.interval.ms等参数的数值

06、kafka集群的调优

• broker端集群优化
  • 设置num.replica.fetcher参数与CPU核数一致，提供副本同步的效率
  • 调大replica.fetch.min.bytes里避免小批量数据的同步，提供吞吐量
  • 调大replica.fetch.max.byte在一批次中尽量多的同步数据，也是为了提高吞吐量
  • 指定broker端JVM的垃圾回收器为G1
• producer端优化
  • 调大batch.size参数提供批次写入的量增大吞吐量，默认是16k
  • 调大buffer.memory参数，提高生产者端缓存的内存大小
  • retriest调大重试次数避免网络抖动带来的问题
  • 根据业务的需求调整ack的值
• consumer端优化
  • 根据具体业务调整max.poll.records的大小
  • max.poll.interval.ms调整批次拉取之间的最大延迟，避免不必要的rebalance
  • heartbeat.interval.ms调整消费者和kafka之间的心跳超时时间，一般调整为session.timeout.ms的三分之一，避免不必要的rebalance