为了保证可用性，Kafka 的分区是多副本的，可以在创建分区时通过 replication-factor 参数指定该分区的副本数，某一副本丢失并不会造成实际数据的丢失，从其他副本获取数据即可。但同时引出了另外一个问题，各个副本之间的数据如何保证一致性?

　　首先，分区的副本根据角色的不同可分为：Leader 副本、 Follower 副本

　　- Leader 副本：Leader 负责与 Producer 和 Consumer 交互，即数据的读写。

　　- Follower 副本：被动地备份 leader 副本中的数据，不与 Client 端做任何交互。

　　另外，不得不提的是 ISR，即(in-sync Replica)副本同步队列：它包含了 Leader 副本和所有与 Leader 副本保持同步的 Follower 副本。那么如何判断 Follower 副本与 Leader 是同步的? Leader 副本和 Follower 副本有两个重要的属性值，如图 LEO 日志末端位移和 HW 水位线。

　　* LEO(log end offset)：记录日志的末端位移值，即数据写到的最新的位置。

　　* HW(high watermark)：取最小的 LEO 作为 HW，即 Committed 过的最新数据。consumer 最多只能消费到 HW 所在的位置，因为小于等于 HW 值的数据才是 Committed 备份过的。

　　我们再来看一下，LEO和HW的更新时机

　　Leader 除了 HW 和 LEO 还会有 RemoteLEO 这个属性，表示 Follwer 的 LEO。Leader 在以下情况下会更新这三个属性。

　　* LEO：Producer 端有数据写入成功时 Leader 会自动地更新 LEO 值

　　* HW：有请求的时候(Producer 或 Follower 的请求)会对比自己 LEO和Remote LEO 取小值更新HW

　　* Remote LEO：Leader 处理 Follower 的 Fetch 请求时，将 Remote LEO 更新为 Follwer 请求中附带的 LEO 值。

　　Follower 只有 HW 和 LEO 两个属性，更新时机为：

　　* LEO：同样是有数据写入成功时就会自动地更新 LEO 值。

　　* HW：Follower 更新 HW 发生在其更新 LEO 之后，一旦 Follower 向 log 写完数据，它会尝试更新它自己的 HW 值。更新的条件是比较当前 LEO 值与 Response 中 Leader 的 HW 值，取两者的小者作为新的 HW 值，如图的 HW:1 会在此时更新为 2。

　　更多关于“大数据培训”的问题，欢迎咨询千锋教育在线名师。千锋教育多年办学，课程大纲紧跟企业需求，更科学更严谨，每年培养泛IT人才近2万人。不论你是零基础还是想提升，都可以找到适合的班型，千锋教育随时欢迎你来试听。