Kafka的一些知识点提醒

消费者消费位移的提交分为同步和异步，手动和自动提交

分区管理之优先副本选举、主题的分区重分配、复制限流

日志索引–稀疏索引，偏移量索引和时间戳索引，根据偏移量索引或者时间戳索引二分法查找具体的某个消息的位置

日志清理之日志删除和日志压缩，日志清理之后的小文件会进行合并

日志磁盘存储–页缓存、零拷贝

服务端–协议设计、定时任务之时间轮、延时操作、Kafka控制器是管理主题与分区的(包括Leader选举)

客户端之消费者的分区重分配策略(RangeAssignor、RoundBobinAssignor、StickyAssignor、自定义)、消费者协调器和组协调器(负责消费者组与主题分区的再均衡的，也就是消费者的分区重分配策略)、再均衡原理(消费组内的消费者或者消费主体的分区数量发生了变化)、_consumer_offsets剖析、

再均衡原理(消费者数量增加为例)：消费者确定它所属的消费组对应的GroupCoordinator所在的broker(通过消费组的groupid来确定在_consumer_offsets中的分区号，然后找到该分区副本的leader副本梭子啊的节点)，并创建与该broker相互通信的网络连接---->加入该消费组---->选举消费组的leader(如果组内没有leader，第一个加入消费组的消费者为消费组的leader，若某一时刻消费组的leader由于某些原因退出了消费组，则会重新选举一个新的leader)---->选举分区分配策略(消费组内的消费者投票选举)---->leader消费者将选举的分区分配策略传输给GroupCoordinator，GroupCoordinator转发给组内的消费者分区分配方案---->保存消费组的元数据信息到_consumer_offsets---->所有消费组内的消费者处于正常状态，间隔性的发送心跳以确保存活

事务–消息传输保障(at most once至多一次、at least once至少一次、exactly once恰好一次)、幂等性(不能跨分区)、事务(可跨分区)，通过幂等性和事务可以保证消息的恰好一次消费而不重复或丢失

Kafka源码剖析非常好的---->http://matt33.com/tags/kafka/
Consume-Transform-Producer模式的事务幂等原理：查找TransactionCoordinator(负责分配PID和管理事务)所在的broker节点(与查找GroupCoordinator类似，只是通过transactionalId的哈希值去对应_transaction_state主题中的分区)---->为当前的生产者获取PID(InitProducerIdRequest请求实现)---->保存PID，TransactionCoordinator在收到InitProducerIdRequest请求后将transactionalId和PID以键值对的形式存储在_transaction_state主题中，根据transactionalId来计算存储的分区，称做事务日志消息---->开启事务，KafkaProducer.beginTrans a ction()---->AddPartitionsToTxnRequest，生产者给新的分区发送数据前，先向TransactionCoordinator发送AddPartitionsToTxnRequest请求，让TransactionCoordinator将<transactionalId,TopicPartition>的对应关系存储在主题_transaction_state中---->生产者通过ProduceRequest请求发送消息到用户自定义的主题中---->AddOffsetsToTxnRequest，KafkaProducer的sendOffsetsToTransaction()方法可以在一个事务批次里处理消息的消费和发送，此方法有两个参数offsets和groupid。此方法会向TransactionCoordinator节点发送AddOffsetsToTxnRequest请求，收到请求后通过groupid推导出在_consumer_offsets中的分区，之后TransactionCoordinator会将这个分区保存到_transaction_state主题中---->TxnOffsetCommitRequest，这个请求也是sendOffsetsToTransaction()方法的一部分，处理完AddOffsetsToTxnRequest请求之后，生产者会发送TxnOffsetCommitRequest请求给GroupCoordinator，从而将本次事务中包含的消费位移信息offsets存储到_consumer_offsets主题中---->EndTxnRequest，无论调用commitTransaction()方法还是abortTransaction()方法，生产者都会向TransactionCoordinator发送EndTxnRequest请求，以此来通知其是提交事务还是终止事务---->WriteTxnMarkersRequest，其是由TransactionCoordinator发向事务中各个分区的leader节点，当节点收到这个请求后，会在相应的分区中写入控制消息(ControlBatch)，即将COMMIT或ABORT信息写入用户所使用的普通主题和_consumer_offsets主题中---->写入最终的COMPLETE_COMMIT或COMPLETE_ABORT，TransactionCoordinator将最终的COMPLETE_COMMIT或COMPLETE_ABORT信息写入主题_transaction_state以表明当前事务已经结束，此时可以删除主题_transaction_state中所有关于该事务的消息。此主题日志采用的是日志压缩，所以这里的删除只需要将相应的消息设置为墓碑消息即可。

可靠性研究–ISR伸缩、LEO(要写入消息的offset)和HW(所有分区副本中最小的LEO)、Leader Epoch是为leader副本和follower副本做同步保障的，防止因为出现宕机和LEO与HW不一致导致的消息丢失和消息不一致问题。

日志同步机制–Kafka使用的是动态维护一个ISR集合，此种方式可以保证在相同的确认信息的情况下，所需要的副本数更少。而另一种少数服从多数的策略则相反，在相同的确认信息的情况下，所需的副本数更多，其常用作共享集群配置。

Kafka不需要宕机节点必须从本地数据日志中进行恢复，Kafka的同步方式允许宕机副本重新加入ISR集合，但在进入ISR之前必须保证自己能够重新同步完leader中的所有数据。

重试队列和死信队列

Kafka与Spark Streaming整合：利用接收器Receiver的方式接收数据和直接从Kafka中读取数据两种。

Receiver方式通过KafkaUtils.createStream()方法创建一个DStream对象，它不关注消费位移的处理。若保证数据可靠性则可开启WAL，只有接收到的数据被持久化到WAL之后才会更新Kafka中的消费位移，WAL中的数据也可做错误恢复处理。在Receiver方式中，Spark中的RDD分区和Kafka中的分区并不是一一对应的。

Direct方式通过KafkaUtils.createDirectStream()方法创建一个DStream对象，该方式中Kafka的一个分区对应于SparkRDD中的一个分区，通过定期扫描所订阅的Kafka每个主题的每个分区的最新偏移量以确定当前批处理数据偏移范围。Direct方式不需要维护一份WAL数据，由Spark Streaming程序自己控制位移的处理，原本应该保存到kafka中的消费位移就无法提供准确的信息了，通常通过检查点机制处理消费位移，这样可以保证Kafka中的数据只会被拉取一次。Direct方式不意味着实现了精确一次(Exactly Once Semantics)，如果要达到精确一次语义标准还需要配合幂等性操作和事务操作。

Kafka+Spark Streaming如何保证exactly once语义---->https://www.jianshu.com/p/10de8f3b1be8