当ack =1 的时候，leader收到消息并把它写入到分区数据文件(不一定同步到磁盘上)时会返回成功，但此时follower还没有同步到最新消息，如果此时leader挂了，则消息丢失
    在Linux系统上，消息会被写到文件系统缓存里，并不保证他们何时会被刷新到磁盘上，kafka不会一直等待数据被写到磁盘上—它依赖复制功能来保证消息的持久性
    详解：
    一个 partition 中的 ISR 列表中，leader 的 HW 是所有 ISR 列表里副本中最小的那个的 LEO。类似于木桶原理，水位取决于最低那块短板。
    LEO，LogEndOffset 的缩写，表示每个 partition 的 log 最后一条 Message 的位置
    HW 俗称高水位，HighWatermark 的缩写，取一个 partition 对应的 ISR 中最小的 LEO 作为 HW，consumer 最多只能消费到 HW 所在的位置。
    Kafka之broker丢数据原因 - 图1

    如上图，某个 topic 的某 partition 有三个副本，分别为 A、B、C。A 作为 leader 肯定是 LEO 最高，B 紧随其后，C 机器由于配置比较低，网络比较差，故而同步最慢。这个时候 A 机器宕机，这时候如果 B 成为 leader，假如没有 HW，在 A 重新恢复之后会做同步 (makeFollower) 操作，在宕机时 log 文件之后直接做追加操作，而假如 B 的 LEO 已经达到了 A 的 LEO，会产生数据不一致的情况，所以使用 HW 来避免这种情况。A 在做同步操作的时候，先将 log 文件截断到之前自己的 HW 的位置，即 3，之后再从 B 中拉取消息进行同步。
    如果失败的 follower 恢复过来，它首先将自己的 log 文件截断到上次 checkpointed 时刻的 HW 的位置，之后再从 leader 中同步消息。leader 挂掉会重新选举，新的 leader 会发送“指令”让其余的 follower 截断至自身的 HW 的位置然后再拉取新的消息。
    这就解释了 为什么leader已经保存的消息 从失败中恢复过来 消息还是丢了。

    当 ISR 中的个副本的 LEO 不一致时，如果此时 leader 挂掉，选举新的 leader 时并不是按照 LEO 的高低进行选举，而是按照 ISR 中的顺序选举。