kafka的各种机制（存储，查询，不丢失，CAP）

kafka的log存储以及查询机制

kafka在我们指定的log.dir目录下，会创建一些文件夹；名字是【主题名字-分区名】所组成的文件夹。 在【主题名字-分区名】的目录下，会有两个文件存在，如下所示：

#索引文件
00000000000000000000.index
#日志内容
00000000000000000000.log

在目录下的文件，会根据log日志的大小进行切分，.log文件的大小为1G的时候，就会进行切分文件；

在kafka的设计中，将offset值作为了文件名的一部分
比如：topic的名字为：test，有三个分区，生成的目录如下如下所示：

test-0
test-1
test-2

kafka日志的组成
segment File组成：由两个部分组成，分别为index Fille和data File，此两个文件一一对应且成对出现； 后缀.index和.log分别表示为segment的索引文件、数据文件。

segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个全局 partion的最大offset（偏移message数）。数值最大为64位long大小，19位数字字符长度，没有数字就用0 填充。

通过索引信息可以快速定位到message。通过index元数据全部映射到memory，可以避免segment File的IO磁盘操作；
通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。 稀疏索引：为了数据创建索引，但范围并不是为每一条创建，而是为某一个区间创建；
好处：就是可以减少索引值的数量。
不好的地方：找到索引区间之后，要得进行第二次处理。
kafka的offset查找过程

比如：要查找绝对offset为7的Message：
上图的左半部分是索引文件，里面存储的是一对一对的key-value，其中key是消息在数据文件（对应的log文件）中的编号，比如“1,3,6,8……”，
分别表示在log文件中的第1条消息、第3条消息、第6条消息、第8条消息……，那么为什么在index文件中这些编号不是连续的呢？
这是因为index文件中并没有为数据文件中的每条消息都建立索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引。
这样避免了索引文件占用过多的空间，从而可以将索引文件保留在内存中。
但缺点是没有建立索引的Message也不能一次定位到其在数据文件的位置，从而需要做一次顺序扫描，但是这次顺序扫描的范围就很小了。

其中以索引文件中元数据3,4597为例，其中3代表在右边log数据文件中从上到下第3个消息(在全局partiton表示第4597个消息)，
其中4597表示该消息的物理偏移地址（位置）为4597。
kafka Message的物理结构及介绍

kafka当中的数据不丢失机制

生产者生产数据不丢失
生产者数据不丢失过程图

说明：有多少个分区，就启动多少个线程来进行同步数据
发送数据方式
可以采用同步或者异步的方式-过程图

• 同步：发送一批数据给kafka后，等待kafka返回结果
  1、生产者等待10s，如果broker没有给出ack相应，就认为失败。
  2、生产者重试3次，如果还没有响应，就报错

• 异步：发送一批数据给kafka，只是提供一个回调函数。
  1、先将数据保存在生产者端的buffer中。buffer大小是2万条
  2、满足数据阈值或者数量阈值其中的一个条件就可以发送数据。
  3、发送一批数据的大小是500条
  说明：如果broker迟迟不给ack，而buffer又满了，开发者可以设置是否直接清空buffer中的数据

ack机制（确认机制）
生产者数据发送出去，需要服务端返回一个确认码，即ack响应码；ack的响应有三个状态值
0：生产者只负责发送数据，不关心数据是否丢失，响应的状态码为0（丢失的数据，需要再次发送 ）
1：partition的leader收到数据，响应的状态码为1
-1：所有的从节点都收到数据，响应的状态码为-1
说明：如果broker端一直不给ack状态，producer永远不知道是否成功；producer可以设置一个超时时间10s，超 过时间认为失败。

kafka的broker中数据不丢失
在broker中，保证数据不丢失主要是通过副本因子（冗余），防止数据丢失
消费者消费数据不丢失
在消费者消费数据的时候，只要每个消费者记录好offset值即可，就能保证数据不丢失。

CAP理论以及kafka当中的CAP机制

1、分布式系统当中的CAP理论

分布式系统（distributed system）正变得越来越重要，大型网站几乎都是分布式的。
分布式系统的最大难点，就是各个节点的状态如何同步。
为了解决各个节点之间的状态同步问题，在1998年，由加州大学的计算机科学家 Eric Brewer 提出分布式系统的三个指标，分别是
Consistency：一致性
Availability：可用性
Partition tolerance：分区容错性

Eric Brewer 说，这三个指标不可能同时做到。最多只能同时满足其中两个条件，这个结论就叫做 CAP 定理
CAP理论是指，分布式系统中，一致性、可用性和分区容忍性最多只能同时满足两个。

一致性：Consistency
• 通过某个节点的写操作结果对后面通过其它节点的读操作可见
• 如果更新数据后，并发访问情况下后续读操作可立即感知该更新，称为强一致性
• 如果允许之后部分或者全部感知不到该更新，称为弱一致性
• 若在之后的一段时间（通常该时间不固定）后，一定可以感知到该更新，称为最终一致性
可用性：Availability
• 任何一个没有发生故障的节点必须在有限的时间内返回合理的结果
分区容忍性：Partition tolerance
• 部分节点宕机或者无法与其它节点通信时，各分区间还可保持分布式系统的功能
一般而言，都要求保证分区容忍性。所以在CAP理论下，更多的是需要在可用性和一致性之间做权衡。

2、Partition tolerance，中文叫做"分区容错"
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间可能无法通信。

上图中，G1 和 G2 是两台跨区的服务器。G1 向 G2 发送一条消息，G2 可能无法收到。系统设计的时候，必须考虑到这种情况。
一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是存在的。即永远可能存在分区容错这个问题
3、Consistency， 中文叫做"一致性"
意思是，写操作之后的读操作，必须返回该值。举例来说，某条记录是 v0，用户向 G1 发起一个写操作，将其改为 v1。

接下来，用户的读操作就会得到 v1。这就叫一致性
问题是，用户有可能向 G2 发起读操作，由于 G2 的值没有发生变化，因此返回的是 v0。G1 和 G2 读操作的结果不一致，这就不满足一致性了。

为了让 G2 也能变为 v1，就要在 G1 写操作的时候，让 G1 向 G2 发送一条消息，要求 G2 也改成 v1。

这样的话，用户向 G2 发起读操作，也能得到 v1

4、Availability
Availability 中文叫做"可用性"，意思是只要收到用户的请求，服务器就必须给出回应。
用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是 v0 还是 v1，否则就不满足可用性。

5、kafka当中的CAP应用
kafka是一个分布式的消息队列系统，既然是一个分布式的系统，那么就一定满足CAP定律，那么在kafka当中是如何遵循CAP定律的呢？kafka满足CAP定律当中的哪两个呢？
kafka满足的是CAP定律当中的CA，其中Partition tolerance通过的是一定的机制尽量的保证分区容错性。
其中C表示的是数据一致性。A表示数据可用性。

kafka首先将数据写入到不同的分区里面去，每个分区又可能有好多个副本，数据首先写入到leader分区里面去，读写的操作都是与leader分区进行通信，保证了数据的一致性原则，也就是满足了Consistency原则。然后kafka通过分区副本机制，来保证了kafka当中数据的可用性。但是也存在另外一个问题，就是副本分区当中的数据与leader当中的数据存在差别的问题如何解决，这个就是Partition tolerance的问题。

kafka为了解决Partition tolerance的问题，使用了ISR的同步策略，来尽最大可能减少
Partition tolerance的问题
每个leader会维护一个ISR（a set of in-sync replicas，基本同步）列表
ISR列表主要的作用就是决定哪些副本分区是可用的，也就是说可以将leader分区里面的数据同步到副本分区里面去，决定一个副本分区是否可用的条件有两个
• replica.lag.time.max.ms=10000 副本分区与主分区心跳时间延迟
• replica.lag.max.messages=4000 副本分区与主分区消息同步最大差