kafka文档阅读记录

1.1 引言

消费者

消费者组，对应一个主题，一个消费者可以对应多个分区，主题中每条记录传递到组中一个实例。组中可以动态伸缩，加入时接管其他成员的某些分区，注销时对应分区分配给其他消费者实例。
kafka仅提供一个分区中记录的整体顺序，没有在一个主题中不同分区间提供顺序。

1.2 用例

消息传递

很好代替传统邮件代理，代理原因各种各样（比如分离数据处理和生产者，缓冲未处理信息）。kafka有更好的吞吐量、内建分区、副本、容错机制，是大规模可扩展消息处理应用的良好解决方案。
经验中消息传递一般低吞吐量，可能要求端到端低延时，经常依赖于kafka强大的持久性保证。

网站活动跟踪

最初用来重建用户活动踪管道为一组实时发布订阅源。网站活动（网页浏览、搜索等）根据类型对应一个主题发布到一个中心主题。这些源用来许多用途，实时处理、实时监控、加载进Hadoop、离线到数据仓库系统中进行离线处理 和报告。

指标

用来操作监控数据，涉及汇总分布式应用的统计信息生产可操作的集中数据源。

日志汇总

典型方式是服务器上收集物理日志然后集中放到一个地方以便处理。kafka抽象文件细节，并把日志或事件数据更清晰地抽象为信息流。

流处理

用户在由多个阶段组成的处理管道中处理数据，原始数据来于kafka主题，然后汇总、丰富或以其它方式转换进新的主题，以便以后消费或者后续处理。例，推荐新闻文章的处理管道可能从RSS源检索文章，然后发布到“articles”主题，进一步处理可能对内容规范化、消除重复数据，最后处理阶段可能推荐内容给用户。这样的处理管道基于各个主题创建实时数据流图。从0.10.0.0开始，一个轻量但功能强大的流处理库称为Kafka Streams 可以在Apache Kafka中使用来执行上述数据处理。除了Kafka Streams以外，其他开源流处理工具还包括Apache Storm和 Apache Samza。

事件源

一种应用程序设计方式，状态改变被记录，作为时间排序的记录队列。kafka支持大量存储日志数据使其成为这种应用的绝佳后端。

提交日志

kafka可以作为一种分布式系统的外部提交日志。日志帮助节点间复制数据，充当故障节点恢复数据的重新同步机制。日志压缩功能帮助支持这种用法。

复制 （&nbsp（空行）; &emsp（空格）;）

kafka为每一个主题分区复制日志，通过可配置的服务器数量（你可以逐个设置每一个主题的复制因子。）这样子当集群中的服务器失败时就可以自动故障恢复，在故障面前消息仍然可用。
 
   其他消息系统提供一些与副本相关特性，但是，在我们（完全有偏见）的看来，这似乎是一件非常多余的事情，很少使用，伴随着很大缺点：副本失效时，吞吐量受到很大影响，需要手动配置等。默认情况下，kafka用于复制，实际上我们将未复制主题变为复制因子是1的复制主题。
  副本的单位是主题分区，在无故障情况下，每一个分区有一个leader和0或多个follower。包括leader在内的所有副本组成了复制因子。所有的读写操作进入到分区的leader。典型情况下，分区数量远多于broker(代理），leader们均匀地分布在代理中。follower中的日志与leader中的完全一致，都有相同的偏移量和相同顺序的消息（尽管，当然，在任何一个给定时间leader可能在日志的最后有目前为止还未被复制的消息）。
  follower们消费leader中的消息就好像一个正常的kafka消费者一样使用它们到自己的日志。让follower从leader拉取数据有一个优点， 允许follower很自然地批处理将要追加到它们日志的日志集合。
  如同大多数分布式处理系统处理故障一样，需要对存货有一个精确的定义，对于kafka节点来说有两种状态：

1. 节点必须能够维护它与ZooKeeper的会话（通过ZooKeeper的心跳机制）
2. 如果是一个follower他必须复制发生在leader上的写操作，而且没有落后太多。

  我们把 符合这两种状态的节点定义为同步，以避免模糊存活和宕机的概念。leader追踪同步状态节点集合。如果节点死亡，卡主，或者落后，leader将把它移除同步副本得列表。副本卡住和滞后的决定由replica.lag.time.max.ms 设置项控制。
  在分布式系统术语中，我们只尝试处理“失败恢复”模型,节点突然停止工作随后恢复（或许不知道它们宕机过）kafka不处理所谓拜占庭式故障，在这种故障中，节点会产生任意或者恶意的响应（可能是由于错误或者恶作剧）。
  可以更加精确定义消息被认为已经消费，当一个分区所有的同步副本都将它写进日志。只有提交的消息才会发送给消费者，这意味着如果leader失败的话，消费者不用担心潜在的消息丢失。另一方面生产者，可以选择等待消息被提交或者没有，取决于它们对延迟和耐用性折中的偏好，由生产者使用的确认机制控制。注意主题有一个同步副本的“minimum number”设置项会被检查，当生产者需要一个消息被写进所有同步副本的确认时。如果生产者需要不太严格的确认，即使同步副本数量低于最小值，消息也可以被提交、消费。
  kafka保证，只要始终有至少一个同步副本存活，一个被提交的消息就不会丢失。
  在短暂的故障转移期之后，kafka在面对节点故障时仍然可用，但出现网络分区时不可用。

复制日志：仲裁，ISRs（in-sync replicas），状态机

  kafka分区的核心是复制日志，复制日志是分布式系统中最基础的特性之一，有很多方法可以实现它。复制日志可以被其他分布式系统通过状态机风格用来作为实现其它分布式系统的基础。
  复制日志建立一个将一系列值达到一致共识的模型（一般编号日志集合0,1，2,3，）。有许多实现方式，最简单最快的方式是通过过一个leader选择提供给给它的值的顺序。只要leader有效，所有的follower仅需要拷贝这些值，遵从leader选择的顺序。
  当然leader不发生故障不会用到follower，发生故障时需要从follower中选择一个新的leader，但是follower可能会落后很多或者宕机，所以我们要选择一个最新的follower。日志副本算法的基本保证是必须提供，如果告诉客户端一个消息已经提交，leader故障，新的leader必须有这条消息。这有一个折中， 如果leader在宣布一个消息提交时等待更多地follower确认，然后就会有更多地潜在的可选举leader。
   如果你选择了确认机制的数量和选举leader必须比较的日志数量，因此这里肯定会有一个重叠，这就被称为仲裁。
   为了提交决定和leader选举这种折中的常见办法是多数投票。不是kafka特有。假如有2f+1个副本，如果f+1个副本必须收到要被提交的leader声明的之前的数据，如果我们将从至少f+1个副本中通过选举具有最完整日志的follower来选举leader，这样，不超过f个故障，leader保证拥有所有的提交信息。这是因为在f+1个副本中，肯定存在至少一个包含所有提交信息的副本。这个副本的日志是最完整的，因此会被选举为新的leader。还有一些每个算法都必须处理的细节（比如如何精确定义一个日志更加完整，在leader故障期间确定日志一致性，改变副本集合中的服务器集合）我们现在暂时忽略。
  多数投票有一个很好的优势，延迟取决于最快的服务器，而不是最慢的哪一个。
  有丰富的算法实现，包括ZooKeeper的Zab，Raft，Viewstamped Replication。我们知道的和kafka实现最相似的学术出版物是微软的PacificA。
  多数投票的一个缺点是不需要很多失败就让你没有可以你没有选举的leader。需要三个拷贝来容忍一个失败，需要五个拷贝容忍两个失败.0.我们经验中，对于一个实际系统仅仅拥有足够的冗余来容忍单个故障是不够的，但是执行么一个写操作5次，有5倍的磁盘空间要求，1/5吞吐量，是不实际的，对于大容量数据问题。这应该是为什么仲裁算法在共享的集群配置中更常见比如ZooKeeper，但是主数据存储中不太常见的原因。例如在HDFS中命名节点的高可用特点是构建在多数投票基础上，但是这个更昂贵的方法没有在数据本身使用。
  kafka采用一个略微不同的方法来选择自己的仲裁集合，不是多数投票，kafka动态维持一个同步副本集合（ISR），被leader维持。仅这个集合的成员有资格选举成为leader。kafka分区的写操作直到所有ISR收到写操作才会被人为提交成功。无论何时ZooKeeper改变ISR集合都是一致的。这对于kafka用量模型是一个关键因素，模型中有许多分区，保证领导关系平衡是重要的。通过ISR模型和f+1个副本，一个主题可以在没有丢失提交的数据情况下容忍f个故障。
  对于我们想处理的大多数使用场景，这个这中是有意义的。实际上，为了容忍f个故障，多数投票和ISR策略在提交信息之前都要等待相同数量的副本来确认（比如为了应对一个故障多数仲裁需要三个副本和一个确认，ISR策略需要一个副本和一个确认）。提交的能力在没有最慢服务器的情况下是多数投票一个优点，然而，我们认为允许客户端选择是否阻止消息提交，更低的复制因子需要的额外吞吐量金额磁盘空间是值得的.
  另一个重要的设计概念是kafka不要求故障节点恢复所有数据的完整性。在这种空间中，复制算法依赖稳定存储是常见的，稳定存储在任何故障恢复下都不会丢失，也不会有潜在的一致性风险。这里假设有两个主要问题，第一，磁盘错误是我们在一致性数据系统中观察到的常见错误，通常不会保留数据完整性。第二，即使没有错误，我么也不想每一次写操作都是用fsync来保证数据一致性，因为这会使性能降低2到3 个数量级。我们允许副本重新加入ISR时候前，他必须完全重新同步即使它在故障中丢失未刷新的数据。

非洁净leader选举：如果（所有副本）它们全部宕机

  kafka保证是基于至少有一个同步副本，如果全部宕机保证不成立。实际上如果这种情况发生会有两个可以执行的操作。

1. 等待ISR中的一个副本即可复活，然后选择它为leader（庆幸它仍然有全部数据）
2. 选择第一个复活的副本为leader（即使他不在ISR中）
   这是可用性和一致性的折中。0.11.0.0版本之后kafka默认选择第一个策略，可以通过unclean.leader.election.enable配置项设置。
   这并不是kafka特有的难题，存在于所有的仲裁机制，多数投票算法中，如果大多数服务器遭遇永久性故障，你必须选择丢失100%数据，要么违反一致性，选择现存服务器上数据作为你的真想来源。

可用性和耐用性保证

kafka写入时，生产者可以选择等待消息被0,1，或全部副本确认，全部副本确认不保证所有分配的副本收到消息。默认情况下，all意味着现有同步副本收到消息发出确认。例，一个主题两个副本，一个失败，同步副本集合中一个，指定acks=all的写将会OK。仅有一个副本也故障时候，写数据将会丢失。这保证分区最大限度的可用性，但是对于耐用性高于可用性的用户不希望看到的。

1. 禁用不纯净的leader选举，如果所有副本不可用，分区将保持不可用，直到新的leader在此可用为止，与丢失消息相比，这更倾向于不可用性。
2. 指定ISR最小值。ISR多余这个数量时分区接受写入，为了阻止消息写入单个副本，然后副本突然不可用。这个设置只有生产者设置acks=all时，消息至少被同步副本集合确认时才生效。这是两者的折中，size大一点降低消息丢失可能性，但是实际值小于时将不会写入数据。

副本管理

  上述讨论仅是在一个主题分区中的一个副本日志。kafka集群可以有成千上万个分区，我们尝试通过循环方式平衡集群分区分布，避免大容量主题的分区分布在少数几个节点上。还尝试平衡领导关系，一个节点是按比例分配的分区的leader。
一个简单地leader选举实现会为一个node节点上所有分区的每一个分区进行一个选举，当node故障时。相反，我们选择一个broker作为controller控制者，在broker级别检测故障，负责更改故障broker中受影响的分区的leader。结果就可以批处理许多要求的领导关系变更通知，对于大量分区来说选举过程更快代价更小。如果controller控制者故障了，存活的broker将选举出来一个新的controller。