深入理解kafka

复制-Kafka的核心
复制功能是Kafka架构的核心。在Kafka的文档里,Kafka把自己描述成“一个分布式的、可分区的、可复制的提交日志服务”。复制之所以这么关键,
是因为它可以在个别节点失效时仍能保证Kafka的可用性和持久性。
Kafka使用主题来组织数据,每个主题被分为若干个分区,每个分区有多个副本。那些副本被保存在broker上,每个broker可以保存成百上千个属于
不同主题和分区的副本。
replication-factor
用来设置主题的副本数。每个主题可以有多个副本，副本位于集群中不同的broker上，也就是说副本的数量不能超过broker的数量，否则创建主题时会失败。

副本类型。
优先副本和首领副本的关系：

古代皇帝选太子，皇帝有三个儿子，大儿子、二儿子、三儿子，优先副本是大儿子（优先副本这个关系定下来了就不会变），首领副本就是太子，皇帝选太子时，一般也会将优先副本选为首领副本<变成太子>，但是太子是有可能变动变动的，如果大儿子犯事了，那么二儿子就会成为太子）。

首领副本

每个分区都有一个首领副本。为了保证一致性,所有生产者请求和消费者请求都会经过这个副本。

跟随者副本

首领以外的副本都是跟随者副本。跟随者副本不处理来自客户端的请求,它们唯一一的任务就是从首领那里复制消息,保持与首领一致的状态。如果首领发生崩溃,其中的一个跟随者会被提升为新首领。

优先副本

除了当前首领之外,每个分区都有一个优先副本（首选首领），创建主题时选定的首领分区就是分区的优先副本。之所以把它叫作优先副本,是因为在创建分区时,需要在broker之间均衡首领副本。因此,我们希望首选首领在成为真正的首领时,broker间的负载最终会得到均衡。默认情况下,Kafka的auto.leader.rebalance.enable被设为true,它会检査优先副本是不是当前首领,如果不是,并且该副本是同步的,那么就会触发首领选举,让优先副本成为
当前首领。

工作机制
首领的另一个任务是搞清楚哪个跟随者的状态与自己是一致的。跟随者为了保持与首领的状态一致，在有新消息到达时尝试从首领那里复制消息,不过有各种原因会导致同步失败。例如,网络拥塞导致复制变慢,broker发生崩演导致复制滞后,直到重启broker后复制才会继续。
为了与首领保持同步,跟随者向首领发送获取数据的请求,这种请求与消费者为了读取消息而发送的请求是一样的。首领将响应消息发给跟随者。请求消息里包含了跟随者想要获取消息的偏移量,而且这些偏移量总是有序的。
一个跟随者副本先请求消息1,接着请求消息2,然后请求消息3,在收到这3个请求的响应之前,它是不会发送第4个请求消息的。如果跟随者发送了请求消息4,那么首领就知道它已经收到了前面3个请求的响应。通过査看每个跟随者请求的最新偏移量,首领就会知道每个跟随者复制的进度。如果跟随者在10s内没有请求任何消息,或者虽然在请求消息,但在10s内没有请求最新的数据,那么它就会被认为是不同步的。如果一个副本无法与首领保持一致,在首领发生失效时,它就不可能成为新首领，因为它没有包含全部的消息。相反,持续请求得到的最新消息副本被称为同步副本。在首领发生失效时,只有同步副本才有可能被选为新首领。

处理请求的内部机制

broker的大部分工作是处理客户端、分区副本和控制器发送给分区首领的请求。Kafka提供了一个二进制协议(基于TCP),指定了请求消息的格式以及broker如何对请求作出响应——包括成功处理请求或在处理请求过程中遇到错误。
客户端发起连接并发送请求,broker处理请求并作出响应。broker按照请求到达的顺序来处理它们这种顺序保证让Kaka具有了消息队列的特性,同时保证保存的消息也是有序的。

 

 

 

请求消息被放到请求队列后,IO线程会负责处理它们。比较常见的请求类型有：生产请求：生产者发送的请求,它包含客户端要写入broker的消息。
获取请求：在消费者和跟随者副本需要从broker读取消息时发送的请求。

 

生产请求和获取请求都必须发送给分区的首领副本。如果broker收到一个针对特定分区的请求，而该分区的首领在另一个broker上，那么发送请求的客户端会收到一个“非分区首领”的错误响应。当针对特定分区的获取请求被发送到一个不含有该分区首领的broker上，也会出现同样的错误。Kafka客
户端要自己负责把生产请求和获取请求发送到正确的broker上。
那么客户端怎么知道该往哪里发送请求呢？客户端使用了另一种请求类型，也就是元数据请求。这种请求包含了客户端感兴趣的主题列表。服务器
端的响应消息里指明了这些主题所包含的分区、每个分区都有哪些副本，以及哪个副本是首领。元数据请求可以发送给任意一个broker，因为所有broker都缓存了这些信息。
一般情况下，客户端会把这些信息缓存起来，并直接往目标broker上发送生产请求和获取请求。它们需要时不时地通过发送元数据请求来刷新这些信息（刷新的时间间隔通过metadata.max.age.ms参数来配置,2.1.3的客户端默认参数30S），从而知道元数据是否发生了变更,比如，在新broker加入集群时，部分副本会被移动到新的broker上。另外，如果客户端收到“非首领”错误，它会在尝试重发请求之前先刷新元数据，因为这个错误说明了客户端正在使用过期的元数据信息，之前的请求被发到了错误的broker上。

生产请求

我们曾经说过，acks这个配置参数，该参数指定了需要多少个broker确认才可以认为一个消息写入是成功的。不同的配置对“写入成功”的界定是不一样的,如果acks=1,那么只要首领收到消息就认为写入成功;如果acks=all,那么需要所有同步副本收到消息才算写入成功;如果acks=0,那么生产者在把
消息发出去之后,完全不需要等待broker的响应。
包含首领副本的broker在收到生产请求时,会对请求做一些验证。
•发送数据的用户是否有主题写入权限?
请求里包含的acks值是否有效(只允许出现0、1或all)?(ack=-1等同于ack=all)
如果acks=all,是否有足够多的同步副本保证消息已经被安全写入?z
之后,消息被写入本地磁盘。在Linux系统上,消息会被写到文件系统缓存里,并不保证它们何时会被刷新到磁盘上。Kafka不会一直等待数据被写到磁盘上，它依赖复制功能来保证消息的持久性。
在消息被写入分区的首领之后,broker开始检査acks配置参数一如果acks被设为0或1,那么broker立即返回响应;如果acks被设为all,那么请求会被保存在一个叫作炼狱的缓冲区里,直到首领发现所有跟随者副本都复制了消息,响应才会被返回给客户端。

获取请求

broker处理获取请求的方式与处理生产请求的方式很相似。客户端发送请求,向broker请求主题分区里具有特定偏移量的消息,好像在说:“请把主题Test分区0偏移量从53开始的消息以及主题Test分区3偏移量从64开始的消息发给我。”客户端还可以指定broker最多可以从一个分区里返回多少数据。这个限制是非常重要的,因为客户端需要为broker返回的数据分配足够的内存。如果没有这个限制,broker返回的大量数据有可能耗尽客户端的内存。
我们之前讨论过,请求需要先到达指定的分区首领上,然后客户端通过査询元数据来确保请求的路由是正确的。首领在收到请求时,它会先检査请求是否有效，比如,指定的偏移量在分区上是否存在?如果客户端请求的是已经被删除的数据,或者请求的偏移量不存在,那么broker将返回一个错误。

如果请求的偏移量存在,broker将按照客户端指定的数量上限从分区里读取消息,再把消息返回给客户端。Kafka使用零复制技术向客户端发送消息一一也就是说,Kafka直接把消息从文件(或者更确切地说是Linux文件系统缓存)里发送到网络通道,而不需要经过任何中间缓冲区。这是Kafka与其他大部分数据库系统不一样的地方,其他数据库在将数据发送给客户端之前会先把它们保存在本地缓存里。这项技术避免了字节复制,也不需要管理内存缓冲区,从而获得更好的性能。
客户端除了可以设置broker返回数据的上限,也可以设置下限。例如,如果把下限设置为10KB,就好像是在告诉broker:“等到有10KB数据的时候再把它们发送给我。”在主题消息流量不是很大的情况下,这样可以减少CPU和网络开销。客户端发送一个请求,broker等到有足够的数据时才把它们返回给客户端,然后客户端再发出情求,而不是让客户端每隔几毫秒就发送一次请求,每次只能得到很少的数据甚至没有数据。对比这两种情况,它们最终读取的数据总量是一样的,但前者的来回传送次数更少,因此开销也更小。

当然,我们不会让客户端一直等待broker累积数据。在等待了一段时间之后,就可以把可用的数据拿回处理,而不是一直等待下去。所以,客户端可以定
义一个超时时间,告诉broker:“如果你无法在K毫秒内累积满足要求的数据量,那么就把当前这些数据返回给我。”

 

 

 ISR(In-SyncReplica)

并不是所有保存在分区首领上的数据都可以被客户端读取。大部分客户端只能读取已经被写入所有同步副本的消息。分区首领知道每个消息会被复制到哪个副本上,在消息还没有被写入所有同步副本之前,是不会发送给消费者的，尝试获取这些消息的请求会得到空的响应而不是错误。

 

因为还没有被足够多副本复制的消息被认为是“不安全”的，如果首领发生崩横,另一个副本成为新首领,那么这些消息就丢失了。如果我们允许消费者读取这些消息,可能就会破坏一致性。试想,一个消费者读取并处理了这样的一个消息,而另一个消费者发现这个消息其实并不存在。所以,我们会等到所有同步副本复制了这些消息,才允许消费者读取它们。这也意味着,如果broker间的消息复制因为某些原因变慢,那么消息到达消费者的时间也会随之变长
(因为我们会先等待消息复制完毕)。延迟时间可以通过参数replica.lag.time.max.ms来配置,它指定了副本在复制消息时可被允许的最大延迟时间。
Kafka的数据复制是以Partition为单位的。而多个备份间的数据复制，通过Follower向Leader拉取数据完成。从一这点来讲，有点像Master-Slave方
案。不同的是，Kafka既不是完全的同步复制，也不是完全的异步复制，而是基于ISR的动态复制方案。
ISR，也即In-SyncReplica。每个Partition的Leader都会维护这样一个列表，该列表中，包含了所有与之同步的Replica（包含Leader自己）。每次数
据写入时，只有ISR中的所有Replica都复制完，Leader才会将其置为Commit，它才能被Consumer所消费。
这种方案，与同步复制非常接近。但不同的是，这个ISR是由Leader动态维护的。如果Follower不能紧“跟上”Leader，它将被Leader从ISR中移除，
待它又重新“跟上”Leader后，会被Leader再次加加ISR中。每次改变ISR后，Leader都会将最新的ISR持久化到Zookeeper中。
至于如何判断某个Follower是否“跟上”Leader，不同版本的Kafka的策略稍微有些区别。
从0.9.0.0版本开始，replica.lag.max.messages被移除，故Leader不再考虑Follower落后的消息条数。另外，Leader不仅会判断Follower是否在replica.lag.time.max.ms时间内向其发送Fetch请求，同时还会考虑Follower是否在该时间内与之保持同步。

 

 

 

 

在第一步中，LeaderA总共收到3条消息，但由于ISR中的Follower只同步了第1条消息（m1），故只有m1被Commit，也即只有m1可被Consumer消费。此时FollowerB与LeaderA的差距是1，而FollowerC与LeaderA的差距是2，虽然有消息的差距，但是满足同步副本的要求保留在ISR中。
在第二步中，由于旧的LeaderA宕机，新的LeaderB在replica.lag.time.max.ms时间内未收到来自A的Fetch请求，故将A从ISR中移除，此时ISR={B，
C}。同时，由于此时新的LeaderB中只有2条消息，并未包含m3（m3从未被任何Leader所Commit），所以m3无法被Consumer消费。
(上图中就是因为acks不为all或者-1,不全部复制，就会导致单台服务器宕机时的数据丢失m3丢失了)
使用ISR方案的原因
由于Leader可移除不能及时与之同步的Follower，故与同步复制相比可避免最慢的Follower拖慢整体速度，也即ISR提高了系统可用性。
ISR中的所有Follower都包含了所有Commit过的消息，而只有Commit过的消息才会被Consumer消费，故从Consumer的角度而言，ISR中的所有Replica都始终处于同步状态，从而与异步复制方案相比提高了数据一致性。
ISR相关配置说明
Broker的min.insync.replicas参数指定了Broker所要求的ISR最小长度，默认值为1。也即极限情况下ISR可以只包含Leader。但此时如果Leader宕机，则该Partition不可用，可用性得不到保证。

 

可靠的broker

 

复制

Kafka的复制机制和分区的多副本架构是Kafka可靠性保证的核心。把消息写入多个副本可以使Kafka在发生崩愤时仍能保证消息的持久性。
回顾一下主要内容：
Kafka的主题被分为多个分区，分区是基本的数据块。分区存储在单个磁盘上，Kafka可以保证分区里的事件是有序的，分区可以在线（可用），也可以离线（不可用）。每个分区可以有多个副本，其中一个副本是首领。所有的事件都直接发送给首领副本，或者直接从首领副本读取事件。其他副
本只需要与首领保持同步，并及时复制最新的事件。当首领副本不可用时，其中一个同步副本将成为新首领。
分区首领是同步副本，而对于跟随者副本来说，它需要满足以下条件才能被认为是同步的。
•与Zookeeper之间有一个活跃的会话，也就是说，它在过去的6秒（可配置）内向Zookeeper发送过心跳。
•在过去的10s内（可配置）从首领那里获取过消息。
•在过去的10s内从首领那里获取过最新的消息。光从首领那里获取消息是不够的，它还必须是儿乎零延迟的。
如果跟随者副本不能满足以上任何一点，比如与Zookeeper断开连接，或者不再获取新消息，或者获取消息滞后了10s以上，那么它就被认为是不同步的。一个不同步的副本通过与Zookeeper重新建立连接，井从首领那里获取最新消息，可以重新变成同步的。这个过程在网络出现临时问题井很快得到修复的情况下会很快完成，但如果broker发生崩愤就需要较长的时间。
注意：如果一个或多个副本在同步和非同步状态之间快速切换，说明集群内部出现了问题，通常是Java不恰当的垃圾回收配置导致的。不恰当的垃圾回收配置会造成几秒钟的停顿，从而让broker与Zookeeper之间断开连接，最后变成不同步的，进而发生状态切换。

复制系数
主题级别的配置参数是replication.factor，而在broker级别则可以通过default.replication.factor来配置自动创建的主题。
Kafka的默认复制系数就是3，不过用户可以修改它。
如果复制系数为N，那么在凡l个broker失效的情况下，仍然能够从主题读取数据或向主题写入数据。所以，更高的复制系数会带来更高的可用性、可靠性和更少的故障。另一方面，复制系数N需要至少N个broker，而且会有N个数据副本，也就是说它们会占用N倍的磁盘空间。我们一般会在可
用性和存储硬件之间作出权衡。
那么该如何确定一个主题需要几个副本呢？这要看主题的重要程度，以及你愿意付出多少成本来换取可用性。。
如果因broker重启导致的主题不可用是可接受的（这在集群里是很正常的行为），那么把复制系数设为1就可以了。在作出这个权衡的时候，要确保这样不会对你的组织和用户造成影响，因为你在节省了硬件成本的同时也降低了可用性。复制系数为2意味着可以容忍1个broker发生失效，看起来已经足够了。不过要记住，有时候1个broker发生失效会导致集群不稳定（通常是旧版的Kafka），迫使你重启另一个broker－一集群控制器。也就是说，如果将复制系数设为2，就有可能因为重启等问题导致集群不可用。
基于以上几点原因，在要求可用性的场景里把复制系数设为3。在大多数情况下，这已经足够安全了，不过要求更可靠时，可以设为更高，比如我5个副本，以防不测。
副本的分布也很重要。默认情况下，Kafka会确保分区的每个副本被放在不同的broker上。不过，有时候这样仍然不够安全。如果这些broker处于同一个机架上，一旦机架的交换机发生故障，分区就会不可用，这时候把复制系数设为多少都不管用。为了避免机架级别的故障，我们建议把broker分布在多个不同的机架上。

不完全的首领选举
unclean.leader.election只能在broker级别（实际上是在集群范围内）进行配置，它的默认值是true。

当分区首领不可用时，一个同步副本会被选为新首领。如果在选举过程中没有丢失数据，也就是说提交的数据同时存在于所有的同步副本上，那么
这个选举就是“完全”的。
但如果在首领不可用时其他副本都是不同步的，我们该怎么办呢？
这种情况会在以下两种场景里出现。
•分区有3个副本，其中的两个跟随者副本不可用（比如有两个broker发生崩愤）。这个时候，如果生产者继续往首领写入数据，所有消息都会得到确认井被提交（因为此时首领是唯一的同步副本）。现在我们假设首领也不可用了（又一个broker发生崩愤），这个时候，如果之前的一个跟随者重
新启动，它就成为了分区的唯一不同步副本。
•分区有3个副本，因为网络问题导致两个跟随者副本复制消息滞后，所以尽管它们还在复制消息，但已经不同步了。首领作为唯一的同步副本继
续接收消息。这个时候，如果首领变为不可用，另外两个副本就再也无法变成同步的了。
对于这两种场景，我们要作出一个两难的选择。
如果不同步的副本不能被提升为新首领，那么分区在旧首领（最后一个同步副本）恢复之前是不可用的。有时候这种状态会持续数小时（比如更换
内存芯片）。
·如果不同步的副本可以被提升为新首领，那么在这个副本变为不同步之后写入旧首领的消息、会全部丢失，导致数据不一致。为什么会这样呢？
假设在副本0和副本1不可用时，偏移量100-200的消息被写入副本2（首领）。现在副本2变为不可用的，而副本0变为可用的。副本0只包含偏移量0～100的消息，不包含偏移量100～200的悄息。如果我们允许副本0成为新首领，生产者就可以继续写人数据，消费者可以继续读取数据。于是，新首领就有了偏移量100～200的新消息。这样，部分消费者会读取到偏移量100～200的旧消息，部分消费者会读取到偏移量100～200的新消息，还有部分消费者读取的是二者的混合。这样会导致非常不好的结果，比如生成不准确的报表。另外，副本2可能会重新变为可用，并成为新首领的跟随者。这个时候，它会把比当前首领旧的消息全部删除，而这些消息对于所有消费者来说都是不可用的。
简而言之，如果我们允许不同步的副本成为首领，那么就要承担丢失数据和出现数据不一致的风险。如果不允许它们成为首领，那么就要接受较低的可用性，因为我们必须等待原先的首领恢复到可用状态。

如果把unclean.leader.election设为true，就是允许不同步的副本成为首领（也就是“不完全的选举”），那么我们将面临丢失消息的风险。如果把这个参数设为false,就要等待原先的首领重新上线，从而降低了可用性。

我们经常看到一些对数据质量和数据一致性要求较高的系统会禁用这种不完全的首领选举（把这个参数设为false）。比如银行系统，大部分银行系统宁愿选择在几分钟甚至几个小时内不处理信用卡支付事务，也不会冒险处理错误的消息。不过在对可用性要求较高的系统里，比如实时点击流分析系统，一般会启用不完全的首领选举。

最少同步副本
在主题级别和broker级别上，这个参数都叫min.insync.replicas。
我们知道，尽管为一个主题配置了3个副本，还是会出现只有一个同步副本的情况（acks=0或1）。如果这个同步副本变为不可用，我们必须在可用性和一致性之间作出选择---这又是一个两难的选择。根据Kafka对可靠性保证的定义，消息只有在被写入到所有同步副本之后才被认为是已提交的。但如果这里的“所有副本”只包含一个同步副本，那么在这个副本变为不可用时，数据就会丢失。
如果要确保已提交的数据被写入不止一个副本，就需要把最少同步副本数量设置为大一点的值。对于一个包含3个副本的主题，如果
min.insync.replicas被设为2，那么至少要存在两个同步副本才能向分区写入数据。
如果3个副本都是同步的，或者其中一个副本变为不可用，都不会有什么问题。不过，如果有两个副本变为不可用，那么broker就会停止接受生产者的请求。尝试发送数据的生产者会收到NotEnoughReplicasException异常。消费者仍然可以继续读取已有的数据。实际上，如果使用这样的配置，那么当只剩下一个同步副本时，它就变成只读了，这是为了避免在发生不完全选举时数据的写入和读取出现非预期的行为。为了从只读状态中恢复，必须让
两个不可用分区中的一个重新变为可用的（比如重启broker），并等待它变为同步的。

 

可靠系统里的生产者
即使我们尽可能把broker配置得很可靠，但如果没有对生产者进行可靠性方面的配置，整个系统仍然有可能出现突发性的数据丢失。
请看以下两个例子。
为broker配置了3个副本，井且禁用了不完全首领选举，这样应该可以保证万无一失。我们把生产者发送消息的acks设为1（只要首领接收到消
息就可以认为消息写入成功）。生产者发送一个消息给首领，首领成功写入，但跟随者副本还没有接收到这个消息。首领向生产者发送了一个响应，告诉它“消息写入成功”，然后它崩溃了，而此时消息还没有被其他副本复制过去。另外两个副本此时仍然被认为是同步的（毕竟判断一个副本不同步需要一小段时间），而且其中的一个副本成了新的首领。因为消息还没有被写入这个副本，所以就丢失了，但发送消息的客户端却认为消息已成功写入。

因为消费者看不到丢失的消息，所以此时的系统仍然是一致的（因为副本没有收到这个消息，所以消息不算已提交），但从生产者角度来看，它丢失了一个消息。
•为broker配置了3个副本，并且禁用了不完全首领选举。我们接受了之前的教训，把生产者的acks设为all。假设现在往Kafka发送消息，分区的首领刚好崩愤，新的首领正在选举当中，Kafka会向生产者返回“首领不可用”的响应。在这个时候，如果生产者没能正确处理这个错误，也没有重试发送消息直到发送成功，那么消息也有可能丢失。这算不上是broker的可靠性问题，因为broker并没有收到这个消息。这也不是一致性问题，因为
消费者并没有读到这个消息。问题在于如果生产者没能正确处理这些错误，弄丢消息的是它们自己。
那么，我们该如何避免这些悲剧性的后果呢？从上面两个例子可以看出，每个使用Kafka的开发人员都要注意两件事情。
1.根据可靠性需求配置恰当的acks值。
2.在参数配置和代码里正确处理错误。

发送确认
复习一下，生产者可以选择以下3种不同的确认模式。
acks=0意味着如果生产者能够通过网络把消息发送出去，那么就认为消息已成功写入Kafka。在这种情况下还是有可能发生错误，比如发送的对象无法被序列化或者网卡发生故障，但如果是分区离线或整个集群长时间不可用，那就不会收到任何错误。即使是在发生完全首领选举的情况下，这种模
式仍然会丢失消息，因为在新首领选举过程中它并不知道首领已经不可用了。在acks=0模式下的运行速度是非常快的（这就是为什么很多基准测试都是基于这个模式），你可以得到惊人的吞吐量和带宽利用率，不过如果选择了这种模式，一定会丢失一些消息。
acks=1意味若首领在收到消息并把它写入到分区数据文件（不一定同步到磁盘上）时会返回确认或错误响应。在这个模式下，如果发生正常的首领选举，生产者会在选举时收到一个LeadeNotAvailableExcepti.on异常，如果生产者能恰当地处理这个错误，它会重试发送消息，最终消息会安全到达新的
首领那里。不过在这个模式下仍然有可能丢失数据，比如消息已经成功写入首领，但在消息被复制到跟随者副本之前首领发生崩溃。
acks=all意味着首领在返回确认或错误响应之前，会等待所有同步副本都收到悄息。如果和min.insync.replicas参数结合起来，就可以决定在返回确认
前至少有多少个副本能够收到消息。这是最保险的做法——生产者会一直重试直到消息被成功提交。不过这也是最慢的做法，生产者在继续发送其他消息之前需要等待所有副本都收到当前的消息。可以通过使用异步模式和更大的批次来加快速度，但这样做通常会降低吞吐量。

配置生产者的重试参数

生产者需要处理的错误包括两部分：一部分是生产者可以自动处理的错误，还有一部分是需要开发者手动处理的错民。
如果broker返回的错误可以通过重试来解决，那么生产者会自动处理这些错误。生产者向broker发送消息时，broker可以返回一个成功响应码或者一个错误响应码。错民响应码可以分为两种，一种是在重试之后可以解决的，还有一种是无法通过重试解决的。例如，如果broker返回的是LEADERNOTAVAILABLE错误，生产者可以尝试重新发送消息。也许在这个时候一个新的首领被选举出来了，那么这次发送就会成功。也就是说，
LEADERNOTAVAILABLE是一个可重试错误。
另一方面，如果broker返回的是INVALIDCONFIG错误，即使通过重试也无能改变配置选项，所以这样的重试是没有意义的。这种错误是不可重试错误。
一般情况下，如果你的目标是不丢失任何消息，那么最好让生产者在遇到可重试错误时能够保持重试。为什么要这样？因为像首领选举或网络连接这类问题都可以在几秒钟之内得到解决，如果让生产者保持重试，就不需要额外去处理这些问题了。
那么为生产者配置多少重试次数比较好？这个要看在生产者放弃重试并抛出异常之后想做些什么。如果你想抓住异常并再多重试几次，那么就可以把重试次数设置得多一点，让生产者继续重试；如果你想直接丢弃消息，多次重试造成的延迟已经失去发送消息的意义；如果你想把消息保存到某个地方然后回过头来再继续处理，那就可以停止重试。
Kafka的跨数据中心复制工具（MirrorMaker）默认会进行无限制的重试。作为一个具有高可靠性的复制工具，它决不会丢失消息。
要注意，重试发送一个已经失败的消息会带来一些风险，如果两个消息都写入成功，会导致消息重复。例如，生产者因为网络问题没有收到broker的确认，但实际上消息已经写入成功，生产者会认为网络出现了临时故障，就重试发送该消息（因为它不知道消息已经写入成功）。

在这种情况下，broker会收到两个相同的消息。重试和恰当的错误处理可以保证每个消息“至少被保存一次”，但无法保证每个消息“只被保存一次”。现实中的很多应用程序在消息里加入唯一标识符，用于检测重复消息，消费者在读取消息时可以对它们进行清理。还要一些应用程序可以做到消息的“幕等”，也就是说，即使出现了重复消息，也不会对处理结果的正确性造成负面影响。

可靠系统里的消费者

消费者的可靠性配置
为了保证消费者行为的可靠性，需要注意以下4个非常重要的配置参数。
第1个是group.id。如果两个消费者具有相同的group.id，并且订阅了同一个主题，那么每个消费者会分到主题分区的一个子集，也就是说它们只能读到所有消息的一个子集（不过群组会读取主题所有的消息）。如果你希望消费者可以看到主题的所有消息，那么需要为它们设置唯一的group.id。
第2个是auto.offset.reset。这个参数指定了在没有偏移量可提交时（比如消费者第1次启动时）或者请求的偏移量在broker上不存在时，消费者会做些什么。这个参数有两种配置。一种是earliest，如果选择了这种配置，消费者会从分区的开始位置读取数据，不管偏移量是否有效，这样会导致消费者读取大量的重复数据，但可以保证最少的数据丢失。一种是latest，如果选择了这种配置，消费者会从分区的末尾开始读取数据，这样可以减少重复处理消息，但很有可能会错过一些消息。

第3个是enable.auto.commit。这是一个非常重要的配置参数，你可以让消费者基于任务调度自动提交偏移量，也可以在代码里手动提交偏移量。自动提交的一个最大好处是，在实现消费者逻辑时可以少考虑一些问题。如果你在消费者轮询操作里处理所有的数据，那么自动提交可以保证只提交已经处理过的偏移量。自动提交的主要缺点是，无法控制重复处理消息（比如消费者在自动提交偏移量之前停止处理消息），而且如果把消息交给另外一个后台线程去处理，自动提交机制可能会在消息还没有处理完毕就提交偏移量。
第4个配置参数auto.commit.interval.ms与第3个参数有直接的联系。如果选择了自动提交偏移盘，可以通过该参数配置提交的频度，默认值是每5秒钟提交一次。一般来说，频繁提交会增加额外的开销，但也会降低重复处理消息的概率。

消费者阻塞

有时候处理数据需要很长时间：你可能会从发生阻塞的外部系统获取信息，或者把数据写到外部系统，或者进行一个非常复杂的计算，但是我们要尽量保持轮询。在这种情况下，一种常见的做法是使用一个线程地来处理数据，因为使用多个线程可以进行并行处理，从而加快处理速度。在把数据移交给线程地去处理之后，你就可以暂停消费者，然后保持轮询，但不获取新数据，直到工作线程处理完成。在工作线程处理完成之后，可以让消费者继续获取新数据。有些应用程序不仅仅需要“至少一次”（意味着没有数据丢失），还需要“仅一次”语义。Kafka现在还不能完全支持仅一次语义，消费者还是有一些办法可以保证Kafka里的每个消息只被写到外部系统一次（但不会处理向Kafka写入数据时可能出现的重复数据）。

数据防重复

实现仅一次处理最简单且最常用的办能是把结果写到一个支持唯一键的系统里，比如键值存储引擎、关系型数据库、ElasticSearch或其他数据存储引擎。在这种情况下，要么消息本身包含一个唯一键（通常都是这样），要么使用主题、分区和偏移量的组合来创建唯一键一一－它们的组合可以唯一标识一个Kafka记录。如果你把消息和一个唯一键写入系统，然后碰巧又读到一个相同的消息，只要把原先的键值覆盖掉即可。数据存储引擎会覆盖已经存在的键值对，就像没有出现过重复数据一样。这个模式被叫作幂等性写入，它是一种很常见也很有用的模式。如果写入消息的系统支持事务，那么就可以使用另一种方法。最简单的是使用关系型数据库。我们把消息和偏移量放在同一个事务里，这样它们就能保持同步。在消费者启动时，它会获取最近处理过的消息偏移量，然后调用seek（）方也从该偏移量位置继续读取数据。简言之，mvcc，幂等性，唯一键。