franz kafka攻略版 kafka
Kafka 简介
Kafka 基于发布和订阅模型的高吞吐、分布式、消息系统最初是由 LinkedIn 公司采用 Scala 和 java 开发的开源流处理软件平台，目前是 Apache 开源项目。
Kafka 消费离线和在线消息时，将消息数据按顺序存储在磁盘上，并以副本的形式存储在集群中，以防止数据丢失。Kafka 可以依赖 ZooKeeper 集群管理受到越来越多分布式处理系统的青睐，如 Storm、Spark、Flink 等都支持与 Kafka 实时流式计算采用集成。
Kafka 开发者 Jay Kreps 提及关于 Kafka 名称起源：
“ 因为 Kafka 系统的写作性能很强，所以找作家的名字命名似乎是个好主意。大学期间上了很多文学课，很喜欢 Franz Kafka 另外，这个名字听起来很酷~~ ”
什么是新闻队列？
学习 Kafka 我们经常提到了解消息队列，这是我们经常提到的 MQ(Message Queue)，因为 Kafka 本质上也是一个消息队列。
那么什么是消息队列呢？先看一个官方回答。
消息队列是同一过程中不同线程之间的通信方式，主要解决异步处理、应用耦合、流量峰值消除等问题，实现高性能、高可用性、可伸缩性和最终一致性结构，是大型分布式系统不可或缺的中间部件。
再说直观点，如下图所示，系统 A 发布消息 MQ，然后系统 B 再从 MQ 取消息。
那为什么系统呢？ A 不直接向系统发送信息 B ，中间要隔一个 MQ 呢？这就要看了 MQ 三个主要功能。
1）异步处理
消息队列提供异步处理机制，因为用户不需要立即响应来处理消息，所以所有的消息都可以通过这个机制放入 MQ 中。例如，系统发送的数据包含大量的图片信息。如果保存所有信息，用户可能会长时间操作。异步处理后，系统将存储所有数据 MQ 用户不需要立即处理，大大缩短了系统的响应时间。
2）应用解耦
消息队列可以解耦系统之间的依赖，减少依赖系统变化的影响。例如，订单系统A需要在用户下单后通知系统B、应对系统C等。传统做法如下图所示。
此时，系统A强烈依赖于系统B和系统C。当系统B出现故障或需要重新添加高耦合系统D时，必须更改系统A的代码。
如果这种依赖系统迭代经常发生，系统A将难以维护，依赖系统可以通过消息队列解耦（如下图所示），因此系统A不需要关心其他系统的可用性。
3）流量削峰
流量峰也有一个名字叫峰谷，实际上是指当数据激增时，可以有效隔离上下游业务，缓存上游突然增加的流量，真正填充到谷，以平稳的方式传输到下游系统，避免流量的不规则影响。
例如，通常有一个活动页面 50qps，特殊时刻访问量突然增加，可以达到 1000qps，但目前系统的处理能力最多 100qps，此时可通过消息队列切峰填谷，如下图所示。
当然，Kafka 除了以上 MQ 除此之外，这些功能还提供了信息顺序保证、回溯信息、持久存储等功能，这将在后续文章中详细说明。
MQ 两种传输方式
消息在 MQ 点对点传输模型有两种(point to point)和发布/订阅(publish/subscribe)模型。
1)点对点模型
如图所示，系统A发送的信息只能由系统B接收，任何其他系统都无法获得系统A发送的信息。在日常生活中，就像A打电话给B一样，其他人是不可能接听的。
2)发布/订阅模型
与点对点模型的区别在于发布/订阅模型多了一个模型 topic 在概念上，可以有多个出版商向同一主题发送信息，也可以有多个订阅者接收同一主题的信息。在日常生活中，它就像不同主题的报纸和期刊，也有不同群体的读者订阅。
那么 Kafka 其实属于哪一种 Kafka 这两种传输模型可以同时支持，以后再谈。
Kafka 系统架构
终于到了主角的舞台典型的Kafka 包括系统架构 Producer、broker、Cosumer 等角色，还有一个 ZooKeeper 集群，先上图。
前面提到 Kafka 同时支持两种新闻传输模型，其中点对点模型的实现是引入的 Consumer Group，主要目的是让多个消费者同时消费，加速整个消费者端的吞吐量。
需要注意的是：一个 Topic 中间的一个分区只能是同一个分区 Consumer Group 中的一个消费者消费，其他消费者不能进行消费。这里的一个消费者，指的是运行消费者应用的进程，也可以是一个线程。
在整个 Kafka 集群中 Producer 发送消息 broker，然后 broker 然后将收到的信息存储在磁盘中，然后 Consumer 再从 Broker 订阅和消费新闻。ZooKeeper 则是 Kafka 集群用于管理集群元数据和选举控制器。
Kafka 重要概念
1）Topic 与 Partition
在 Kafka 中消息是以 Topic 对单位进行分类，Topic 逻辑上可以认为是一个 Queue，Producer 生产的每一条新闻都必须指定 Topic，然后 Consumer 根据订阅 Topic 到对应的 broker 上去拉取消息。
为提高整个集群的吞吐量，Topic 在物理上，多个分区也可以细分，一个分区对应于磁盘上的文件夹。因为一个分区只属于一个主题，它通常被称为主题分区(Topic-Partition)。
2）Leader 和 Follower
一个分区会有多个副本，副本是主(Leader)多从(Follower)的关系，Leader 提供外部服务，这里的外部服务是指与客户端程序交互， Follower 只是被动同步 Leader 而且，不能与外界互动。
当然，你可能知道在许多其他系统中 Follower 可提供外部服务，如 MySQL 阅读操作可以从库处理，但在 Kafka 中 Follower 只负责新闻同步，不提供外部服务。
有趣的是，现在不提倡使用Master-Slave来指代这种主从关系，毕竟，Slave有奴隶的意思。在美国这个禁止种族歧视的国家，这种说法有点政治不正确，所以目前大部分系统都改成了Leader-Follower了。
Kafka 多副本机制
Kafka 将多副本机制引入分区，同一分区不同副本中保存的信息相同，通过多副本机制实现故障的自动转移。 broker 无效时仍能保证服务的可用性，提高容灾能力。
如图所示，Kafka 集群中有4个 broker，某个 Topic 有三个分区，假设副本因子也设置为3，那么每个分区都会有一个 Leader 和两个 Follower 副本。
副本不同 broker 生产者和消费者只和谐 Leader 互动副本，而 Follower 副本只负责新闻的同步。 Leader 当副本出现故障时，从 Follower 副本中重新选举新的 Leader 副本提供外部服务。
接下来我们来了解一下 Kafka 多副本机制中的一些重要术语。
AR(Assigned Replicas)：一个分区的所有副本统称为 AR；ISR(In-Sync Replicas)：Leader 保持一定程度同步的副本和所有副本 Follower 副本（包括 Leader 本身）组成 ISR；OSR(Out-of-Sync Raplicas)：与 ISR 相反，没有与 Leader 所有副本在一定程度上保持同步Follower 副本组成OSR；首先，生产者会发送消息 Leader 副本，然后 Follower 副本才能从 Leader 同时，所有副本中的消息都不完全相同，即同步期间，Follower 相对于 Leader 当然，这种滞后程度可以通过参数来配置。
然后，我们可以澄清三者之间的关系：AR = ISR OSR。
Leader 负责维护和跟踪 ISR 集合中所有 Follower 当 Follower 当滞后过多或失效时，Leader 将会把它从 ISR 集中去除。
当然，如果 OSR 集合中有 Follower 同步范围赶上 Leader，那么 Leader 也会把它从 OSR 集中转移 ISR 集合。
一般情况下，当 Leader 发送故障或故障时，只有 ISR 集合中的 Follower 才有资格被选为新的 Leader，而 OSR 集合中的 Follower 没有这个机会参数配置可以修改)。
原文链接：https://www.cnblogs.com/datadance/p/16292991.html?utm_source=tuicool&utm_medium=referral