共计 3130 个字符，预计需要花费 8 分钟才能阅读完成。
kafka 通过 topic 来分主题存放数据，主题内有分区，分区能够有多个正本，分区的外部还细分为若干个 segment。
所谓的分区其实就是在 kafka 对应存储目录下创立的文件夹，文件夹的名字是主题名加上分区编号，编号从 0 开始。
kafka 全套视频学习材料：http://www.atguigu.com/download.shtml
1、segment
所谓的 segment 其实就是在分区对应的文件夹下产生的文件。
一个分区会被划分成大小相等的若干 segment，这样一方面保障了分区的数据被划分到多个文件中保障不会产生体积过大的文件；另一方面能够基于这些 segment 文件进行历史数据的删除，提高效率。
一个 segment 又由一个.log 和一个.index 文件组成。
1．.log
.log 文件为数据文件用来存放数据分段数据。
2．.index
.index 为索引文件保留对对应的.log 文件的索引信息。
在.index 文件中，保留了对对应.log 文件的索引信息，通过查找.index 文件能够获知每个存储在以后 segment 中的 offset 在.log 文件中的开始地位，而每条日志有其固定格局，保留了包含 offset 编号、日志长度、key 的长度等相干信息，通过这个固定格局中的数据能够确定出以后 offset 的完结地位，从而对数据进行读取。
3．命名规定
这两个文件的命名规定为：
partition 全局的第一个 segment 从 0 开始，后续每个 segment 文件名为上一个 segment 文件最初一条音讯的 offset 值，数值大小为 64 位，20 位数字字符长度，没有数字用 0 填充。
2、读取数据
开始读取指定分区中某个 offset 对应的数据时，先依据 offset 和以后分区的所有 segment 的名称做比拟，确定出数据在哪个 segment 中，再查找该 segment 的索引文件，确定以后 offset 在数据文件中的开始地位，最初从该地位开始读取数据文件，在依据数据格式判断后果，获取残缺数据。
二、可靠性保障
1、AR
在 Kafka 中保护了一个 AR 列表，包含所有的分区的正本。AR 又分为 ISR 和 OSR。
AR = ISR + OSR。
AR、ISR、OSR、LEO、HW 这些信息都被保留在 Zookeeper 中。
1．ISR
ISR 中的正本都要同步 leader 中的数据，只有都同步实现了数据才认为是胜利提交了，胜利提交之后能力供外界拜访。
在这个同步的过程中，数据即便曾经写入也不能被外界拜访，这个过程是通过 LEO-HW 机制来实现的。
2．OSR
OSR 内的正本是否同步了 leader 的数据，不影响数据的提交，OSR 内的 follower 尽力的去同步 leader，可能数据版本会落后。
最开始所有的正本都在 ISR 中，在 kafka 工作的过程中，如果某个正本同步速度慢于 replica.lag.time.max.ms 指定的阈值，则被踢出 ISR 存入 OSR，如果后续速度复原能够回到 ISR 中。
3．LEO
LogEndOffset：分区的最新的数据的 offset，当数据写入 leader 后，LEO 就立刻执行该最新数据。相当于最新数据标识位。
4．HW
HighWatermark：只有写入的数据被同步到所有的 ISR 中的正本后，数据才认为已提交，HW 更新到该地位，HW 之前的数据才能够被消费者拜访，保障没有同步实现的数据不会被消费者拜访到。相当于所有正本同步数据标识位。
在 leader 宕机后，只能从 ISR 列表中选取新的 leader，无论 ISR 中哪个正本被选为新的 leader，它都晓得 HW 之前的数据，能够保障在切换了 leader 后，消费者能够持续看到 HW 之前曾经提交的数据。
所以 LEO 代表曾经写入的最新数据地位，而 HW 示意曾经同步实现的数据，只有 HW 之前的数据能力被外界拜访。
5．HW 截断机制
如果 leader 宕机，选出了新的 leader，而新的 leader 并不能保障曾经齐全同步了之前 leader 的所有数据，只能保障 HW 之前的数据是同步过的，此时所有的 follower 都要将数据截断到 HW 的地位，再和新的 leader 同步数据，来保证数据统一。
当宕机的 leader 复原，发现新的 leader 中的数据和本人持有的数据不统一，此时宕机的 leader 会将本人的数据截断到宕机之前的 hw 地位，而后同步新 leader 的数据。宕机的 leader 活过来也像 follower 一样同步数据，来保证数据的一致性。
2、生产者可靠性级别
通过以上的解说，曾经能够保障 kafka 集群外部的可靠性，然而在生产者向 kafka 集群发送时，数据通过网络传输，也是不牢靠的，可能因为网络提早、闪断等起因造成数据的失落。
kafka 为生产者提供了如下的三种可靠性级别，通过不同策略保障不同的可靠性保障。
其实此策略配置的就是 leader 将胜利接管音讯信息响应给客户端的机会。
通过 request.required.acks 参数配置：
1：生产者发送数据给 leader，leader 收到数据后发送胜利信息，生产者收到后认为发送数据胜利，如果始终收不到胜利音讯，则生产者认为发送数据失败会主动重发数据。
当 leader 宕机时，可能失落数据。
0：生产者不停向 leader 发送数据，而不须要 leader 反馈胜利音讯。
这种模式效率最高，可靠性最低。可能在发送过程中失落数据，也可能在 leader 宕机时失落数据。
-1：生产者发送数据给 leader，leader 收到数据后要等到 ISR 列表中的所有正本都同步数据实现后，才向生产者发送胜利音讯，如果一只收不到胜利音讯，则认为发送数据失败会主动重发数据。
这种模式下可靠性很高，然而当 ISR 列表中只剩下 leader 时，当 leader 宕机让然有可能丢数据。
此时能够配置 min.insync.replicas 指定要求察看 ISR 中至多要有指定数量的正本，默认该值为 1，须要改为大于等于 2 的值
这样当生产者发送数据给 leader 然而发现 ISR 中只有 leader 本人时，会收到异样表明数据写入失败，此时无奈写入数据，保障了数据相对不丢。
尽管不丢然而可能会产生冗余数据，例如生产者发送数据给 leader，leader 同步数据给 ISR 中的 follower，同步到一半 leader 宕机，此时选出新的 leader，可能具备局部此次提交的数据，而生产者收到失败音讯重发数据，新的 leader 承受数据则数据反复了。
3、leader 选举
当 leader 宕机时会抉择 ISR 中的一个 follower 成为新的 leader，如果 ISR 中的所有正本都宕机，怎么办？
有如下配置能够解决此问题：
unclean.leader.election.enable=false
策略 1：必须期待 ISR 列表中的正本活过来才抉择其成为 leader 持续工作。
unclean.leader.election.enable=true
策略 2：抉择任何一个活过来的正本，成为 leader 持续工作，此 follower 可能不在 ISR 中。
策略 1，可靠性有保障，然而可用性低，只有最初挂了 leader 活过来 kafka 能力复原。
策略 2，可用性高，可靠性没有保障，任何一个正本活过来就能够持续工作，然而有可能存在数据不统一的状况。
4、kafka 可靠性的保障
At most once：音讯可能会丢，但绝不会反复传输。
At least once：音讯绝不会丢，但可能会反复传输。
Exactly once：每条音讯必定会被传输一次且仅传输一次。
kafka 最多保障 At least once，能够保障不丢，然而可能会反复，为了解决反复须要引入惟一标识和去重机制，kafka 提供了 GUID 实现了惟一标识，然而并没有提供自带的去重机制，须要开发人员基于业务规定本人去重。
关键词：大数据培训
