Kafka 温故(三)：Kafka的内部机制深入(持久化，分布式，通讯协议)

一.Kafka的持久化

1.数据持久化：
     发现线性的访问磁盘（即：按顺序的访问磁盘），很多时候比随机的内存访问快得多，而且有利于持久化；
     传统的使用内存做为磁盘的缓存
     Kafka直接将数据写入到日志文件中，以追加的形式写入

2.日志数据持久化特性：
   写操作：通过将数据追加到文件中实现

   读操作：读的时候从文件中读就好了

3.优势：    
             读操作不会阻塞写操作和其他操作（因为读和写都是追加的形式，都是顺序的，不会乱，所以不会发生阻塞），数据大小不对性能产生影响；
             没有容量限制（相对于内存来说）的硬盘空间建立消息系统；
             线性访问磁盘，速度快，可以保存任意一段时间！

4.持久化的具体实现：

1.一个Topic可以认为是一类消息，每个topic将被分成多partition(区),每个partition在存储层面是append log文件。任何发布到此partition的消息都会被直接追加到log文件的尾部，每条消息在文件中的位置称为offset（偏移量）,partition是以文件的形式存储在文件系统中。

2.Logs文件根据broker中的配置要求,保留一定时间后删除来释放磁盘空间。

5.索引

为数据文件建索引：

             稀疏存储，每隔一定字节的数据建立一条索引（这样的目的是为了减少索引文件的大小）。

 

  下图为一个partition的索引示意图：

 

注：

     1.现在对6.和8建立了索引，如果要查找7，则会先查找到8然后，再找到8后的一个索引6，然后两个索引之间做二分法，找到7的位置

 

     2.每一个log文件中又分为多个segment

二.Kafka的分布式实现

 

 

注:

1.当生产者将消息发送到Kafka后，就会去立刻通知ZooKeeper，会往zookeeper的节点中去挂，
   zookeeper中会watch到相关的动作，当watch到相关的数据变化后，会通知消费者去消费消息。

2.消费者是主动去Pull（拉）kafka中的消息，这样可以降低Broker的压力，因为Broker中的消息是无状态的，Broker也不知道哪个消息是可以消费的

3.当消费者消费了一条消息后，也必须要去通知ZooKeeper。zookeeper会记录下消费的数据，这样但系统出现问题后就可以还原，可以知道哪些消息已经被消费了

部署图：

 

Name Server集群即ZooKeeper集群

 

三.Kafka的通讯协议

注：

        最重要的是要理解使用CRC机制来验证数据是否传输不完整，破损。

下面的了解即可

 

 

四、数据传输的事务定义

at most once: 最多一次,这个和JMS中"非持久化"消息类似.发送一次,无论成败,将不会重发.

 

at least once: 消息至少发送一次,如果消息未能接受成功,可能会重发,直到接收成功.

 

exactly once: 消息只会发送一次.

 

◦at most once: 消费者fetch消息,然后保存offset,然后处理消息;当client保存offset之后,但是在消息处理过程中出现了异常,导致部分消息未能继续处理.那么此后"未处理"的消息将不能被fetch到,这就是"at most once".

◦

◦at least once: 消费者fetch消息,然后处理消息,然后保存offset.如果消息处理成功之后,但是在保存offset阶段zookeeper异常导致保存操作未能执行成功,这就导致接下来再次fetch时可能获得上次已经处理过的消息,这就是"at least once"，原因offset没有及时的提交给zookeeper，zookeeper恢复正常还是之前offset状态.

◦

◦exactly once: kafka中并没有严格的去实现(基于2阶段提交,事务),我们认为这种策略在kafka中是没有必要的.

 

注：通常情况下"at-least-once"是我们首选.(相比at most once而言,重复接收数据总比丢失数据要好).

 

 

参考资料：

《百知教育》apache kafka