kafka——高效读写数据、事务、Zookeeper的作用

高效读写数据

1）顺序写磁盘
kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能够到600M/s，而随机写只有100K/s。这与磁盘的机械机构有关，顺序之所以快，是因为其省去了大量磁头寻址时间。
2）应用
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到磁盘，反而会降低性能。
3）零复制技术

直接从PageCache中拷贝到NIC中

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

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

Zookeeper在kafka中的作用

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