(4)Kafka高效读写原理、选举过程和事务实现

Kafka设计原理总结

(1)Kafka设计架构综述

(2)Kafka中生产者工作机制详解

(3)Kafka 消费者工作机制详解

(4)Kafka高效读写原理、选举过程和事务实现

1.Kafka高效读取数据

---

(1)顺序写入磁盘

    kafka的broker收到producer数据时，以log文件尾部追加方式顺序写入。顺序写入大于随机写入效率在于，省去了大量磁头寻址时间。

    一 次完整的输入输出（IO）操作的时间=磁盘轴旋转时间（旋转延迟）+磁盘臂移动时间（寻道时间）+数据传输时间 。三者所需时间的平均经验值为： 0.004秒、0.008秒和0.0005秒。所以， 一次完整的IO时间的经验值是0.0125秒，即1/80秒。

     因为磁盘的盘片可分为多个扇区，顺序写只需要磁头随着磁盘顺序旋转即可，而随机 写可能需要寻道，还要旋转道跨越多个扇区。

(2)零复制技术

    Kafka利用OS内核功能，减少了数据拷贝的次数，避免了CPU进行不必要的数据拷贝。

   参考： 掘金

    

2.Zookeeper实现Kafka leader选举

---

(1)Controller作用和Controller选举

    首先Kafka集群中有一个broker会被选举为Controller， 负责管理broker的上下线，所有 topic的分区副本分配和 leader选举等工作。 在kafka集群启动的时候，会在ZK中创建一个临时节点(EPHEMERAL)/controller，在每个Broker启动的时候，都会先去访问ZK中的这个节点，如果不存在Broker就会则创建这个节点，先到先得称为Controller， 其它Broker当访问这个节点的时候，如果读取到brokerid不等于-1，那么说明Controller已经被选举出来了。

    Controller选举有三个场景

• 集群首次启动：首次启动时未选举Controller，Broker都向ZK进行注册然后由ZK 调用elect方法选举
• Controller节点宕机：ZK再次调用elect方法选举
• ZK中节点数据变更：如果当前Broker之前就是Controller，则卸任重新尝试选举。如果当前Broker不是Controller，则直接向ZK竞选。

(2)Leader选举过程

3.Kafka事务管理和实现

---

(1)事务作用

     事务可以保证 Kafka 在 Exactly Once 语义的基 础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。

    At Least Once + 幂等性<PID,Partition,SeqNumber> = Exactly Once

(2)Producer事务

     为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer 获得的PID和Transaction ID绑定。这样当Producer重启后就可以通过正在进行的TransactionID 获得原来的 PID。

    因为Producer重启后PID会重新初始化，如果在发送消息过程Producer宕机，当Producer恢复后：首先原来已发送的数据和未发送的数据都会再发送一遍 (因为Producer一般本地不会记录发送到哪条记录了)。此时如果重发，已发送的数据在Broker中将重复，而未发送的数据在Broker中是正常新消息。因此，Producer需要恢复到未发送数据部分避免重复。

    为了管理事务， Producer可以和Kafka中Transaction Coordinator进行交互，获得Transaction ID对应的任务状态。同时， Transaction Coordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

(3)Consumer事务

    Consumer事务在设计时可靠性比较弱， 只能保证消息精准发送到Consumer即可，不保证Consumer是否消费成功，因为 Consumer可能会采取先收到消息立即返回，然后再消费数据却突然宕机，这种情况是消费者自己的问题。

.。

    并且由于 Consumer 可以通过 offset 访问任意信息，而且不同的 Segment File 生命周期不同， 同一事务的消息可能会出现重启后被 删除的情况。