kafka数据可靠传输

再说复制
Kafka 的复制机制和分区的多副本架构是Kafka 可靠性保证的核心。把消息写入多个副本可使Kafka 在发生崩愤时仍能保证消息的持久性。

Kafka 的主题被分为多个分区，分区是基本的数据块。分区存储在单个磁盘上，Kafka 能够保证分区里的事件是有序的，分区能够在线（可用），也能够离线（不可用） 。每一个分区能够有多个副本，其中一个副本是首领。全部的事件都直接发送给首领副本，或者直接从首领副本读取事件。其余副本只须要与首领保持同步，并及时复制最新的事件。当首领副本不可用时，其中一个同步副本将成为新首领。

分区首领是同步副本，而对于跟随者副原本说，它须要知足如下条件才能被认为是同步的。

• 与Zookeeper 之间有一个活跃的会话，也就是说，它在过去的6s（可配置）内向Zookeeper 发送过心跳。
• 在过去的10s 内（可配置）从首领那里获取过消息。
• 在过去的10s 内从首领那里获取过最新的消息。光从首领那里获取消息是不够的，它还必须是儿乎零延迟的。

若是跟随者副本不能知足以上任何一点，好比与Zookeeper 断开链接，或者再也不获取新消息，或者获取消息滞后了10s 以上，那么它就被认为是不一样步的。一个不一样步的副本经过与Zookeeper 从新创建链接，并从首领那里获取最新消息，能够从新变成同步的。这个过程在网络出现临时问题并很快获得修复的状况下会很快完成，但若是broker 发生崩愤就须要较长的时间。

broker的配置

broker 有3 个配置参数会影响Kafka 消息存储的可靠性。与其余配置参数同样，它们能够应用在broker 级别，用于控制全部主题的行为，也能够应用在主题级别，用于控制个别主题的行为。在主题级别控制可靠性，意味着Kafka 集群能够同时拥有可靠的主题和非可靠的主题。例如，在银行里，管理员可能把整个集群设置为可靠的，但把其中的一个主题设置为非可靠的，用于保存来自客户的投诉，由于这些消息是容许丢失的。

复制系数
主题级别的配置参数是replication.factor，而在broker 级别则能够经过default.replication.factor来配置自动建立的主题。

若是复制系数为N，那么在凡l 个broker 失效的状况下，仍然可以从主题读取数据或向主题写入数据。因此，更高的复制系数会带来更高的可用性、可靠性和更少的故障。另外一方面，复制系数N 须要至少N 个broker ，并且会有N 个数据副本，也就是说它们会占用N倍的磁盘空间。咱们通常会在可用性和存储硬件之间做出权衡。

建议在可用性的场景下，把复制系数设置为3.

不彻底的首领选举

以前提到过，当分区首领不可用时，一个同步副本会被选举为新首领。若是在选举过程当中没有丢失数据，也就是说提交的数据同时存在于全部的同步副本上，那么这个选举就是“彻底的”
    
但若是在首领不可用时其余副本都是不一样步的，咱们该怎么办呢？

#如下两种状况：

第一种： 分区有3 个副本，其中的两个跟随者副本不可用（好比有两个broker 发生崩愤）。这个时候，若是生产者继续往首领写入数据，全部消息都会获得确认井被提交（由于此时首 领是惟一的同步副本）。如今咱们假设首领也不可用了（又一个broker 发生崩愤），这个时候，若是以前的一个跟随者从新启动，它就成为了分区的惟一不一样步副本。 第二种： 分区有3 个副本，由于网络问题致使两个跟随者副本复制消息滞后，因此尽管它复制消息，但已经不一样步了。首领做为惟一的同步副本继续接收消息。这个时候，若是 首领变为不可用，另外两个副本就再也没法变成同步的了。

#上面这两种状况该如何解决？
第一种：要么等待原首领复活，可是等待过程当中服务是宕的，有可能这是一个很长的时间段；要么使用新的首领，可是确定丢失了数据。
第二种：由于两个副本已经滞后了，因此若首领不可用，那么滞后的同步副本被选为新首领，就会形成数据丢失的问题（数据不一致）。

简而言之，若是咱们容许不一样步的副本成为首领，那么就要承担丢失数据和出现数据不一致的风险。若是不容许它们成为首领，那么就要接受较低的可用性，由于咱们必须等待原先的首领恢复到可用状态。
若是把unclean.leader.election.enable 设为true ，就是容许不一样步的副本成为首领（也就是“ 不彻底的选举")，那么咱们将面临丢失消息的风险。若是把这个参数设为false ,
就要等待原先的首领从新上线，从而下降了可用性。咱们常常看到一些对数据质量和数据一致性要求较高的系统会禁用这种不彻底的首领选举（ 把这个参数设为false ） 。银行系统是这方面最好的例子，大部分银行系统宁愿选择在几分钟甚至几个小时内不处理信用卡支付事务，也不会冒险处理错误的消息。不过在对可用性要求较高的系统里，好比实时点击流分析系统， 通常会启用不彻底的首领选举。

 

最少同步副本

在主题级别和broker 级别上，这个参数都叫min.insync.replicas 。咱们知道，尽管为一个主题配置了3 个副本，仍是会出现只有一个同步副本的状况。若是这个同步副本变为不可用，咱们必须在可用性和一致性之间做出选择一一这是一个两难的选择。根据Kafka 对可靠性保证的定义，消息只有在被写入到全部同步副本以后才被认为
是已提交的。但若是这里的“全部副本”只包含一个同步副本，那么在这个副本变为不可用时，数据就会丢失。

若是要确保已提交的数据被写入不止一个副本，就须要把最少同步副本数量设置为大一点的值。对于一个包含3 个副本的主题，若是min.insync.replicas被设为2 ，那么至少要存在两个同步副本才能向分区写入数据。

若是3 个副本都是同步的，或者其中一个副本变为不可用，都不会有什么问题。不过，若是有两个副本变为不可用，那么broker 就会中止接受生产者的请求。尝试发送数据的生产者会收到NotEnoughReplicasException 异常。消费者仍然能够继续读取已有的数据。实际上，若是使用这样的配置，那么当只剩下一个同步副本时，它就变成只读了，这是为了不在发生不彻底选举时数据的写入和读取出现非预期的行为。为了从只读状态中恢复，必须让两个不可用分区中的一个从新变为可用的（好比重启broker），并等待它变为同步的。

 

配置重试参数

以下的一个实例：

为broker 配置了3 个副本，而且禁用了不彻底首领选举。 把生产者的acks 设为all 。假设如今往Kafka 发送消息，分区的首领恰好崩愤，新的首领正在选举当中， Kafka 会向生产者
返回“首领不可用”的响应。在这个时候，若是生产者没能正确处理这个错误，也没有重试发送消息直到发送成功，那么消息也有可能丢失。这算不上是broker 的可靠性问题，由于broker 
并无收到这个消息。这也不是一致性问题，由于消费者井没有读到这个消息。问题在于若是生产者没能正确处理这些错误，弄丢消息的是它们本身。

#解决这个问题，生产者再发一次消息就能够了！

 

生产者须要处理的错误包括两部分： 一部分是生产者能够自动处理的错误，还有一部分是须要开发者手动处理的错误。

若是broker 返回的错误能够经过重试来解决，那么生产者会自动处理这些错误。生产者向broker 发送消息时， broker 能够返回一个成功晌应码或者一个错误响应码。错民晌应码能够分为两种， 一种是在重试以后能够解决的，还有一种是没法经过重试解决的。例如，若是broker 返回的是LEADER_NOT_AVAILABLE 错误，生产者能够尝试从新发送消息。也许在这个时候一个新的首领被选举出来了，那么此次发送就会成功。也就是说， LEADER_NOT_AVAILABLE是一个可重试错误。另外一方面，若是broker 返回的是INVALID_CONFIG 错误，即便经过重试也无能改变配置选项，因此这样的重试是没有意义的。这种错误是不可重试错误。

 

上面提到的是生成者的一些配置，下面咱们来讲明消费者的一些配置。

消费者读取数据

下面这段着重理解一下：

只有那些被提交到Kafka 的数据，也就是那些已经被写入全部同步副本的数据，对消费者是可用的，这意味着消费者获得的消息已经具有了一致性。消费者惟一要作的是跟踪哪些消息是已经读取过的，哪些是尚未读取过的。这是在读取消息时不丢失悄息的关键。

在从分区读取数据时，消费者会获取一批事件，检查这批事件里最大的偏移量，而后从这个偏移量开始读取另一批事件。这样能够保证消费者总能以正确的顺序获取新数据， 不会错过任何事件。

若是一个悄费者退出，另外一个消费者须要知道从什么地方开始继续处理，它须要知道前一个消费者在退出前处理的最后一个偏移量是多少。所谓的“另外一个”消费者，也可能就是它本身重启以后从新回来工做。这也就是为何消费者要“提交”它们的偏移量。它们把当前读取的偏移量保存起来，在退出以后，同一个群组里的其余消费者就能够接孚它们的工做。若是消费者提交了偏移量却未能处理完消息，那么就有可能形成消息丢失，这也是消费者丢失消息的主要缘由。在这种状况下，若是其余消费者接手了工做，那些没有被处理完的消息就会被忽略，永远得不处处理。这就是为何咱们为何很是重视偏移量提交的时间点和提交的方式。

#已提交的消息与已提交的偏移量
 此处的己提交消息与以前讨论过的已提交消息是不同的，它是指已经被写入全部同步副本而且对消费者可见的消息，而己提交偏移量是指消费者发送给Kafka 的偏移量，
用于确认它已经收到并处理好的消息位置。

消费者的配置

这里仅说明四个比较重要参数的配置

• group.id:若是两个消费者具备相同的group.id，井且订阅了同一个主题，那么每一个消费者会分到主题分区的一个子集， 也就是说它们只能读到全部消息的一个子集（不过群组会读取主题全部的消息）。若是你但愿消费者能够看到主题的全部消息，那么须要为它们设置惟一的group.id 。
• auto.offset.reset:这个参数指定了在没有偏移量可提交时（好比消费者第l 次启动时）或者请求的偏移量在broker 上不存在时），消费者会作些什么。这个参数有两种配置。一种是earliest ，若是选择了这种配置，消费者会从分区的开始位置读取数据，无论偏移量是否有效，这样会致使消费者读取大量的重复数据，但能够保证最少的数据丢失。一种是latest，若是选择了这种配置， 消费者会从分区的末尾开始读取数据，这样能够减小重复处理消息，但颇有可能会错过一些消息。
• enable.auto.commit：这是一个很是重要的配置参数，你可让消费者基于任务调度自动提交偏移量，也能够在代码里手动提交偏移量。自动提交的一个最大好处是，在实现消费者逻辑时能够少考虑一些问题。若是你在消费者轮询操做里处理全部的数据，那么自动提交能够保证只提交已经处理过的偏移量。自动提交的主要缺点是，没法控制重复处理消息（好比消费者在自动提交偏移量以前中止处理悄息），并且若是把消息交给另一个后台线程去处理，自动提交机制可能会在消息尚未处理完毕就提交偏移量。
• auto.commit.interval.ms: 与第3个参数直接联系。若是选择了自动提交偏移量，能够经过该参数配置提交的频度，默认值是每5s提交一次。通常来讲，频繁提交会增长额外的开销，但也会下降重复处理消息的频率。