kafka总结

kafka写入存储

kafka存储时，为了高性能，存储的数据会先存储到内核中的文件系统缓存中，并不会实时的写到磁盘文件中，所以如果出现kafka挂掉或者系统宕机等意外，则有可能出现数据丢失，因为有的数据还在文件系统缓存上，没有持久化到磁盘上。我们可以通过副本解决这种问题，后面kafka数据丢失段落会说到。

kafka分区

kafka可以为一个topic分配多个分区，各个分区可以被分配到不同的服务器节点上，从而使得多个节点可以并行的接受生产者和消费者的请求，从而提高吞吐量。

kafka副本

kafka每个分区都可以设置多个follow副本，每个follow副本及leader副本各自之间都不会在一个节点上（在一个节点上没有意义，因为follow副本不提供读写操作，只做备份）。follow会不断的向leader请求数据，使得自己处于同步状态。leader会将一定时间内（默认10秒）没有向自己请求数据的follow标记为不同步状态。我们可以通过kafka参数unclean.leader.election配置是否允许不同步的副本称为leader。

 

kafka数据丢失

broker重启之后数据截断：

kafka为每一轮leader选举都标记了一个epoch，每轮选举这个epoch都会加1，当每个副本添加第一条数据时，会记录一个[epoch,offset]，offset即这一轮生产的第一条数据的offset。假设有三个broker ABC，当AB挂了，这时候C成为leader，当AB重启后就会将自己的大于C的[epoch,offset]中的offset的偏移量的数据删除，然后继续同步C中的数据。

多个服务器节点同时宕机的概率会随着服务节点增加而降低。比如说一台节点一年只宕机3次，概率为3/365，差不多为1/100，则有三个节点同时宕机的概率为1/1000000，这种出现的概率几乎可以忽略。

所以说数据如果被同步到所有follower副本之后，即使数据还在文件系统缓存中，没有被同步到磁盘，数据也不可能丢失。但是如果数据只被部分follower节点同步，仍然会出现数据丢失情况。比如说三个节点ABC，A是leader，B一直处于同步状态，C由于网络问题没有同步最新的几条数据（我们把这几条数据称为data），那如果AB节点同时挂掉，C则会变成leader（虽然kafka可以通过参数unclean.leader.election配置不同步的副本（此处就是C节点）不能称为leader，但是leader A判断副本同步不同步仍然需要一定的时间，所以有可能在还没有判断出C不同步时，A就直接挂掉了（B同时也挂掉了），所以此时认为C是同步的。），然后AB启动。AB发现C成为了leader，此时AB就会截断刚才的data，继续同步A的数据。这时候data就丢了......；

要想数据百分百不丢，就要让所有follow副本同步了每一条数据之后，再返回给客户端写入成功（实现配置：客户端acks=all，min.insync.replicas=所有副本数），但是这样kafka的吞吐量会大大降低。但是一般不需要设置所有follow副本同步之后再返回给客户端写入成功，因为多个节点同时怠机的可能性太小了。

总得来说，我们需要在数据一致性和可用性之间进行权衡。如果想要更强的数据一致性，就需要将min.insync.replicas参数设置得更大些。当min.insync.replicas=所有副本数，则可以百分百保证数据不丢失。即min.insync.replicas越大，数据一致性越强，但是可用性也就越差，因为当有follower没有响应给leader提交成功时，leader就不会响应给生产者处理成功。这时候系统就处于不可用的状态。