大数据是一种在获取、存储、管理、分析等方面大大超出了传统数据库软件工具能力范围的数据集合。它具有大量的数据规模、快速的数据流转、多样的数据类型和价值密度低四大特征。 未来大数据相关人才缺口巨大。

大量优质岗位等你来

薪资待遇随工作年限呈阶梯式上涨

只有想不想学，没有能不能学

理论、实战双向并行，奠定入行扎实基础

一路暖心服务，不怕您货比三家

       大数据培训资料

　　让分布式系统的操作变得简单，在某种程度上是一种艺术，通常这种实现都是从大量的实践中总结得到的。ApacheKafka的受欢迎程度在很大程度上归功于其设计和操作简单性。随着社区添加更多功能，开发者们会回过头来重新思考简化复杂行为的方法。

　　ApacheKafka中一个更细微的功能是它的复制协议(replicationprotocol)。对于单个集群上不同大小的工作负载，调整Kafkareplication以让它适用不同情况在今天来看是有点棘手的。使这点特别困难的挑战之一是如何防止副本从同步副本列表(也称为ISR)加入和退出。从用户的角度来看，这意味着如果生产者(producer)发送一批“足够大”的消息，那么这可能会导致Kafkabrokers发出多个警报。这些警报表明某些主题“未被复制”(underreplicated)，这意味着数据未被复制到足够多的brokers上，从而增加数据丢失的可能性。因此，Kafkacluster密切监控“未复制的”分区总数非常重要。在这篇文章中，我将讨论导致这种行为的根本原因以及我们如何解决这个问题。

　　一分钟了解Kafka复制机制

　　Kafka主题中的每个分区都有一个预写日志(write-aheadlog)，我们写入Kafka的消息就存储在这里面。这里面的每条消息都有一个唯一的偏移量，用于标识它在当前分区日志中的位置。

　　Kafka中的每个主题分区都被复制了n次，其中的n是主题的复制因子(replicationfactor)。这允许Kafka在集群服务器发生故障时自动切换到这些副本，以便在出现故障时消息仍然可用。Kafka的复制是以分区为粒度的，分区的预写日志被复制到n个服务器。在n个副本中，一个副本作为leader，其他副本成为followers。顾名思义，producer只能往leader分区上写数据(读也只能从leader分区上进行)，followers只按顺序从leader上复制日志。

　　日志复制算法(logreplicationalgorithm)必须提供的基本保证是，如果它告诉客户端消息已被提交，而当前leader出现故障，新选出的leader也必须具有该消息。在出现故障时，Kafka会从挂掉leader的ISR里面选择一个follower作为这个分区新的leader;换句话说，是因为这个follower是跟上leader写进度的。

　　每个分区的leader会维护一个in-syncreplica(同步副本列表，又称ISR)。当producer往broker发送消息，消息先写入到对应leader分区上，然后复制到这个分区的所有副本中。只有将消息成功复制到所有同步副本(ISR)后，这条消息才算被提交。由于消息复制延迟受到最慢同步副本的限制，因此快速检测慢副本并将其从ISR中删除非常重要。Kafka复制协议的细节会有些细微差别，本博客并不打算对该主题进行详尽的讨论。感兴趣的同学可以到这里详细了解Kafka复制的工作原理。

　　副本在什么情况下才算跟上leader

　　一个副本如果它没有跟上leader的日志进度，那么它可能会被标记为不同步的副本。我通过一个例子来解释跟上(caughtup)的含义。假设我们有一个名为foo的主题，并且只有一个分区，同时复制因子为3。假设此分区的副本分别在brokers1，2和3上，并且我们已经在主题foo上提交了3条消息。brokers1上的副本是leader，副本2和3是followers，所有副本都是ISR的一部分。假设replica.lag.max.messages设置为4，这意味着只要follower落后leader的消息不超过3条，它就不会从ISR中删除。我们把replica.lag.time.max.ms设置为500毫秒，这意味着只要follower每隔500毫秒或更早地向leader发送一个fetch请求，它们就不会被标记为死亡并且不会从ISR中删除。

　　现在假设producer往leader上发送下一条消息，与此同时，broker3上发生了GC停顿，

　　由于broker3在ISR中，因此在将broker3从ISR中移除或broker3上的分区跟上leader的日志结束偏移之前，最新消息都是不认为被提交的。注意，由于border3落后leader的消息比replica.lag.max.messages=4要小，因此不符合从ISR中删除的条件。这意味着broker3上的分区需要从leader上同步offset为3的消息，如果它做到了，那么这个副本就是跟上leader的。假设broker3在100ms内GC完成了，并且跟上了leader的日志结束偏移。

　　什么情况下会导致一个副本与leader失去同步

　　一个副本与leader失去同步的原因有很多，主要包括：

　　1、慢副本(Slowreplica)：followerreplica在一段时间内一直无法赶上leader的写进度。造成这种情况的最常见原因之一是followerreplica上的I/O瓶颈，导致它持久化日志的时间比它从leader消费消息的时间要长;

　　2、卡住副本(Stuckreplica)：followerreplica在很长一段时间内停止从leader获取消息。这可能是以为GC停顿，或者副本出现故障;

　　3、刚启动副本(Bootstrappingreplica)：当用户给某个主题增加副本因子时，新的followerreplicas是不同步的，直到它跟上leader的日志。

　　当副本落后于leader分区时，这个副本被认为是不同步或滞后的。在Kafka0.8.2中，副本的滞后于leader是根据replica.lag.max.messages或replica.lag.time.max.ms来衡量的;前者用于检测慢副本(Slowreplica)，而后者用于检测卡住副本(Stuckreplica)。

　　如何确认某个副本处于滞后状态

　　通过replica.lag.time.max.ms来检测卡住副本(Stuckreplica)在所有情况下都能很好地工作。它跟踪follower副本没有向leader发送获取请求的时间，通过这个可以推断follower是否正常。另一方面，使用消息数量检测不同步慢副本(Slowreplica)的模型只有在为单个主题或具有同类流量模式的多个主题设置这些参数时才能很好地工作，但我们发现它不能扩展到生产集群中所有主题。在我之前的示例的基础上，如果主题foo以2msg/sec的速率写入数据，其中leader收到的单个批次通常永远不会超过3条消息，那么我们知道这个主题的replica.lag.max.messages参数可以设置为4。为什么？因为我们以最大速度往leader写数据并且在follower副本复制这些消息之前，follower的日志落后于leader不超过3条消息。同时，如果主题foo的follower副本始终落后于leader超过3条消息，则我们希望leader删除慢速follower副本以防止消息写入延迟增加。

　　这本质上是replica.lag.max.messages的目标-能够检测始终与leader不同步的副本。假设现在这个主题的流量由于峰值而增加，生产者最终往foo发送了一批包含4条消息，等于replica.lag.max.messages=4的配置值。此时，两个follower副本将被视为与leader不同步，并被移除ISR。