第十章 kafka专题之ACKISRHW机制

第十章 kafka专题之ACK/ISR/HW机制 1、Kafka存储文件概述

• kafka采取了分片和索引机制，将每个partition分为多个segment，每个segment对应一个log文件+一个index文件

（1）index文件

• 稀疏索引：没有为每一条message建立索引，采用了稀疏存储的方式，每隔一定字节的数据建立一条索引。

• 缺点：没有建立索引的数据需要小范围内的顺序扫描 *** 作。

（2）log文件

• log文件分割大小：在server.properties中配置，当segment文件大于1G时，会创建一个新的segment
  

（3）实际案例

#分段1：一个segment包含一个index文件和一个log文件
00000000000000000000.index 00000000000000000000.log
#分段2：数字1234代表当前文件的最小偏移量,即上一个文件的最后一个offset+1
00000000000000001234.index 00000000000000001234.log
#分段3
00000000

2、CAP理论

• CAP：一致性（C）、可用性（A）、分区容错性（P），三者不可同时获得

（1）一致性：所有节点都可以访问到最新的数据；锁定其他节点，不一致之前不可读；

（2）可用性：每个请求都是可以得到响应，不管请求时成功还是失败；备节点锁定后，无法响应；

（3）分区容错性：除了全部整体网络故障，其他故障不能导致整个系统不可用；节点间可能通信失败，无法避免；

• 实现方案

①分布式系统必须保持可分区，即分区可用性（P）

②CP：每个请求需要在服务器之间保持一致，而分区会导致同步时间无限延长（即等待数据在各个分区同步完才能访问服务），一旦发生网络故障或消息丢失等情况，就要牺牲用户体验，等所有数据全部一致之后才能让用户访问系统。

业务场景:支付、交易类数据。要求数据强一致性，宁可牺牲用户体验，也不能出现脏数据

②AP：高可用并允许分区，一旦分区发生网络波动。节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据不一致性，即本地数据和副本数据可能会不一致

业务场景:互联网业务、信息流架构。要求服务高可用，=不要求数据强制一致

3、副本replica

• topic的partition设置多个副本，副本数最好小于broker数量，每个分区有一个leader和多个follower，即leader replica和follower replica

4、生产者发送数据的可靠性保证 - ACK机制

• 生产者向消费者发送数据流程

第一步：生产者发送到指定topic，topic的partition收到producer发送的数据

第二步：broker向producer发送ack确认收到

第三步：producer收到ack，进行下一轮的发送，如没收到则重新发送

（1）ack=0

• 生产者不会等待broker的ack，只会源源不断发送数据

broker会掉用callback返回ack

（2）ack=1

• 生产者会等待broker的ack，leader paritiion写入成功便会向消费者发送ack

（3）ack=-1/all

• 生产者会等待broker的ack，leader partition写入成功并且向所有的follower同步成功后才会向生产者发送ack

（4）ack=n

• 生产者会等待broker的ack，leader paritiion写入成功之后同步n-1个follower同步成功，便会向消费者发送ack

5、消息存储可靠性 - ISR机制

• 多副本存储：follower会周期从leader中pull数据

（1）AR（Assign Replicas）

• 分区中的所有副本。

（2）ISR

• ISR：leader维持一个与其保持同步一定成都的reolica集合，是AR的一个子集

①当ISR中的partition Follower从leader拉取数据成功之后，就会给leader发送ack

②partition leader发生故障之后，会从ISR中选举新的Partition Leader

③如果partition follower长时间未向leader同步数据，则该partition Follower会被踢出ISR

（3）OSR（out of sync replicas）

• 与leader副本同步滞后过多的副本（不包括leader）副本。

（4）同步滞后的原因

①新副本加入，每个新副本加入都需要一段时间的追赶期

②网络IO等原因，某些机器IO处理速度变慢所导致持续消费落后

③进程卡住（Kafka 是Java 写出来的，Java 进程最容易卡住的问题是不是亲切，就是Full GC，及高频次GC）

6、消费者消费数据可靠性保障 - HW机制

• HW作用：保证消费数据的一致性和副本数据的一致性

（1）HW机制概述

①LEO：表示每个partition的log最后一条Message的位置

②HW：表示partition各个replicas数据见同步且一致的offset位置

• 如上图说明LEO

  • leader的LEO为7
  • follower1的LEO为1
  • follower2的LEO为5

• 如上图说明HW，HW为1

  • 消费者消费消息最多到1，之后的数据对消费者不可见

（2）常见故障

①Follower故障

Follower发生故障会被临时提出ISR，等待恢复后**，follower会读取本地磁盘记录的上次的HW，并将该log文件高于HW的部分截掉，从HW开始向leader进行同步**，等该follower的LEO大于该partition的HW，即follower追上leader后，就可以重新加入ISR

②Leader故障

leader故障之后，会从ISR中选取一个新的leader，为了保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于hw的部分截取掉（新leader自己不会截取），然后从新的leader同步数据。