Kafka架构（kafka高效读写数据、zookeeper在kafka中的作用、kafka事务）

Kafka架构

4、 Kafka 高效读写数据

• 高效缘由：分区、地址索引机制

4.1 顺序写磁盘

• Kafka 的 producer 生产数据，要写入到 log 文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

4.2 应用Pagecache(页缓存)

• Kafka 数据持久化是直接持久化到 Pagecache 中，这样会产生以下几个好处：
  • I/O Scheduler 会将连续的小块写组装成大块的物理写从而提高性能
  • I/O Scheduler 会尝试将一些写操作重新按顺序排好，从而减少磁盘头的移动时间
  • 充分利用所有空闲内存（非 JVM 内存）。如果使用应用层 Cache（即 JVM 堆内存），会增加 GC 负担
  • 读操作可直接在 Page Cache 内进行。如果消费和生产速度相当，甚至不需要通过物理磁盘（直接通过 Page Cache）交换数据
  • 如果进程重启，JVM 内的 Cache 会失效，但 Page Cache 仍然可用
• 尽管持久化到 Pagecache上可能会造成宕机丢失数据的情况，但这可以被 Kafka 的 Replication 机制解决。如果为了保证这种情况下数据不丢失而强制将 Page Cache 中的数据 Flush 到磁盘，反而会降低性能。

4.3 零复制技术

5 、Zookeeper 在 Kafka 中的作用

• Kafka 集群中有一个 broker 会被选举为 Controller，负责管理集群 broker 的上下线，所有 topic 的分区副本分配和 leader 选举等工作。
• Controller 的管理工作都是依赖于 Zookeeper 的。

​ 以下为 partition 的 leader 选举过程：

6、Kafka 事务

• Kafka 从0.11版本开始引入了事务支持。事务可以保证 Kafka 在 Exactly Once 语义的基础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。

6.1 Producer 事务

• 为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer 获得的 PID 和Transaction ID 绑定。这样当 Producer 重启后就可以通过正在进行的 Transaction ID 获得原来的 PID。
• 为了管理 Transaction，Kafka 引入了一个新的组件 Transaction Coordinator。Producer 就是通过和Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。Transaction Coordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

6.2 Consumer 事务（精准一次性消费）

• 上述事务机制主要是从 Producer 方面考虑，对于 Consumer 而言，事务的保证就会相对较弱，尤其时无法保证 Commit 的信息被精确消费。这是由于 Consumer 可以通过 offset 访问任意信息，而且不同的Segment File 生命周期不同，同一事务的消息可能会出现重启后被删除的情况。
• 如果想完成 Consumer 端的精准一次性消费，那么需要 kafka 消费端将消费过程和提交offset过程做原子绑定。此时我们需要将 kafka 的 offset 保存到支持事务的自定义介质（比如mysql）。这部分知识会在后续项目部分涉及。