前言

为了数据的安全性，我们在实际的工作中，不可避免的需要考虑kafka的数据备份问题，否则数据丢失了，就无法恢复了。所以数据的备份机制是很重要的。

副本介绍

正常情况下，kafka里的数据都不能只有一份。假设我们保存了N个副本，即topic每个partition都有N个副本（Replica）。并且副本的个数一定小于broker个数。（因为每份数据的副本必须保存在不同的broker，否则没有意义，因为如果一份数据的副本保存在同一个broker，那么这个broker挂了，则数据依然丢失。）所以对于每个partition而言，每个broker上最多只有一个副本，因此我们常常使用broker-id表示副本。kafka还有个机制，就是会默认将副本均匀分布到所有的broker上。

上图中的，黄色实线是数据，黄色虚线部分是副本。kafka会均匀分布到各个broker上。

kafka如何进行数据备份

假设我们设置了数据默认副本数为3。kafka会选举其中的某一个partition（备份以partition为单位）为leader，另外两个为follower。在进行数据备份时，不是leader主动将数据push给follower，而是follower去向leader pull数据过来。同时补充一个事，当kafka的consumer去消费数据的时候，并不是去follower里消费数据，依然是向leader里消费数据。follower只是起到备份数据的作用，并且follower还需要定时去leader里拿数据，如果消费数据时还向follower，这样的设置明显不合理。所以，kafka的读和写都是先通过leader的，follower只起备份作用。（网上盗个图，如下参考）

数据commit

（1）补充两个知识点：

1、producer发布数据有两种方式，分别是同步producer和异步producer。同步的意思就是，producer发布数据后，需要成功后，才能发布下一条数据（在本文中的意思就是，producer发布数据到leader之后， 需要等所有的follower拉取到该数据后，leader才能commit。这种方式耗时）。而异步的意思是，producer发布数据后，无需等待即可发送下一条（即producer发送数据到leader后，leader马上commit，之后follower自己慢慢的去pull数据。这种方式可能会造成数据丢失，因为当数据到leader时，如果follower还没来得及pull数据，leader就挂了，那么这条数据就丢失了，因为leader已经向producer commit了）。

2、commit的意义：只要leader commit了，即向producer表示这条数据已经被存储在broker了，对于producer来说就是这条数据已经被成功发布了。

（2）ISR模式

但是kafka不会选择上述的两种方式，而是巧妙的中和了这两种方式的优点。即ISR方式。leader会维护一个基本与其保持同步的副本列表，这个列表称为ISR(in-sync-Replica)。它的运行机制是，当ISR中的所有副本都pull完leader的数据后，即向leader发送ACK，此时leader再commit。并且这个ISR是动态变化的，当存在follower同步数据大步落后于leader时，则会将其从ISR中移除，以免拖垮整个进度，并且当不在ISR中的follower，与leader同步时，leader又会将其加入到ISR中。这样的机制，不像同步和异步那么绝对，即保证了速度也保证了数据的安全性。当然如果follower如果挂了，则也会将其从ISR中移除（leader也会存在于ISR列表中）。

（3）ISR配置

1、server配置：

replica.lag.time.mac.ms：超时时间，即当follower落后于leader的时间超过这个设定的时间后，则将这个follower从ISR移除。同理，如果发现不在ISR中的follower与leader的时间差小于这个值，则将其移动到ISR中。

replica.lag.max.messages：数据大小，即当follower落后leader的消息条数超过这个设置时，则将这个follower从ISR中移除。同理，如果发现不在ISR中的follower与leader相差的消息条数小于这个值，则将其移动到ISR中。

2、topic配置

min.insync.replicas：ISR中最少的follower个数。一般设置成大于1的，否则如果最后的一个broker挂了，则数据就丢失了。

3、producer配置

request.required.acks： 一般设置为 0 1 -1（0：producer发送完数据后，不等待broker确认即发送下一条数据。 1：producer发送完数据后，等到leader确认后，发送下一条数据。 -1：producer等待ISR中的follower确认后发送下一条数据）

宕机如何恢复

（1）少部分副本宕机

当leader宕机了，会从follower选择一个作为leader。当宕机的重新恢复时，会把之前commit的数据清空，重新从leader里pull数据。

（2）全部副本宕机

当全部副本宕机了有两种恢复方式

1、等待ISR中的一个恢复后，并选它作为leader。（等待时间较长，降低可用性）

2、选择第一个恢复的副本作为新的leader，无论是否在ISR中。（并未包含之前leader commit的数据，因此造成数据丢失）