欢迎回来！如果您错过了第1部分, 您可以在这里查看。
经纪商、主题和分区
代理
从简化的意义上说, 经纪人就是卡夫卡服务器。这是一个运行卡夫卡的服务过程。
- 当代理在群集中连接时, 它允许我们访问整个集群。
- 群集中的经纪商根据 id 进行区分, id 通常是唯一的数字。
主题、分区和偏移
主题是数据管道。数据管道在一端生成消息并发布事件, 使用消息并响应管道另一端的事件。数据管道存储、路由和发送消息或事件。
本主题存储一周的默认期间内的数据。
一个主题可以划分为多个分区。
- 作为第一步, 对分区中的数据进行排序。其次, 如果某个主题只有一个分区, 请为该主题的消息进行排序。如果一个主题具有多个分区, 则不按邮件排序。
- 并行处理会随着分区的增加而增加。通常, 建议的主机数为 x2。例如, 如果群集中有三台服务器, 则可以为每个主题创建六个分区。
- 无法修改写入分区的消息。除非主题再次重复, 否则该主题的修改后的数据需要重新传输。
- 如果密钥不存在, 则数据将被发送到任何一个分区。如果密钥存在, 则同一密钥的数据将传输到各自的主题。
- 偏移量是增量 id。发送到分区的每条消息都有一个唯一的增量 id。
经纪商、主题和分区的分布
可以为不同的主题设置不同数量的分区如果群集中有多个节点, 则分区在不同的节点上随机分布2;颜色: rgb(34, 38, 53);保证金上衣: 20px;边际底部: 5px;字体大小:25 px;清楚的: 两者;字体样式: 正常;字体-变种连字: 正常;字体变量帽: 正常;字母间距: 正常;孤儿: 2;文本对齐: 开始;文本缩进: 0px;文本转换: 无;空白: 正常;寡妇: 2;字间距: 0px;-webkit-text-宽度: 0px;背景颜色: rgb(255, 255, 255);文本装饰风格: 初始;文本装饰颜色: 初始; “> 主题的份数 (复制因子)
通常, 一个主题有2或3个副本。这主要是为了在节点出现故障并脱机的情况下, 该主题将保持可用, 并且群集中的其他节点将继续提供服务。
建议将你的应用限制为少量的副本。随着副本数量的增加, 同步数据所需的时间也会增加, 同时也会降低磁盘利用率。
注意: 对于卡夫卡和 hadoop 群集, 更多节点并不意味着更高的容错能力。相关节点上的故障概率降低, 但容错能力仍然相同。假设 hadoop 群集中有100个节点, 我们已将副本数设置为两个。如果存储这些副本的节点失败, 则无法访问数据。在100个节点中, 节点的总体故障概率 (我们保存了两个副本) 与三个或五个节点相比有所下降。
分区领导和 isr
对于具有多个分区的主题, 只有一个引线分区和一个或多个同步副本 (isr)。当引线分区执行读取和写入时, isr 可确保备份。
生产者
制作人将数据写入主题
在生成器指定分区名称并连接到群集中的任何节点后, 卡夫卡将自动执行负载平衡, 并将写入操作路由到正确的分区 (群集中的不同节点上有多个分区)。
制作人 ack
生成器将通过选择以下模式来获取数据写入通知此时, 生成器不会等待导致数据丢失的写入通知。这里有最高速度。
为所有人设置 ack。此时, 速度极其缓慢。制作人等待领导的通知, 没有损失 isr。
生产者键
生成器传输数据时指定一个键。例如, 电子商务订单将传输诸如订单号、零售商和客户等数据。在这种情况下, 你会如何设置钥匙？
将密钥设置为:
- 如果数据的接收者 (使用者) 不关心订单的传输顺序, 则为订单号或空。
- 零售商, 如果数据接收者需要零售商按顺序传输订单。
- 作为客户, 如果数据接收者需要零售商按顺序发送订单。如果我们将密钥设置为零售商, 并不意味着为传输中的每个密钥指定了字符串 “零售商”。相反, 提到了零售商的特定值。让我们以下面的表为例:
对于001-007 订单, 当我们设置零售商的关键值是苹果 (001), 苹果 (007), 消密 (007), 小米 (007), 小米 (007), 小米 (007), 苹果 (007)。
在这种情况下, 所有 apple 订单都转到序列中的一个分区, 而所有小米订单都按顺序转到另一个分区。这两个分区可以是相同的, 也可以是不同的。请参见下图:
生成器密钥用于路由数据
消费者
消费者的基本概念
使用者从主题中读取数据。与生成器类似, 只要群集中的任何节点都已连接, 并且指定了主题名称, 卡夫卡就会自动从正确的代理和分区中提取数据, 并将数据发送给使用者
消费集团
卡夫卡采用群体概念将消费者和出版商用户模型结合起来。
一个主题可能有多个组, 一个组可能包括多个使用者。组中只有一个使用者可以使用一条消息。对于不同的组, 使用者处于发布者/订阅者模型中。所有组都会收到一条消息。
请注意:将一个分区仅分配给同一组中的一个使用者。如果其中一个组中有三个分区和四个使用者, 则一个使用者是冗余的, 无法接收任何数据。
消费者抵消
请注意–这里提到的消费者偏移量与上一主题中提到的偏移量不同。在上一个主题中, 偏移量与主题 (尤其是分区) 相关, 而这里我指的是使用者。以下是一些更多的考虑点。
- 偏移量记录每个组中每个使用者的读取位置。
- 卡夫卡使用了一个特定的主题, < c//>, 以节省消费者的抵消。
- 当使用者在脱机后再次联机时, 从偏移量以前记录的位置获取数据。
抵消的提交时间:
- 最多一次:只要使用者收到消息, 使用者就会提交偏移量。这确保了最高效率。但是, 当消息处理失败时, 例如, 应用程序将变得异常, 并且无法再获得消息。
- 至少一次:偏移量是在使用者处理消息后提交的。这可能会导致重复读取。当消息的处理变得异常时, 消息将再次读取。这是默认值。
- 正好一次:还在审判中
通常, 选择 “至少一次”, 并对应用程序执行操作, 以确保重复操作。但是, 结果不会受到影响。
注: cap 理论: 分布式系统最多可以同时满足一致性、可用性和分区容差两个方面。
动物园管理员
zookeeper 是分布式服务注册、发现和治理组件卡夫卡依靠动物园管理员。卡夫卡安装包直接包括其兼容的 zookeeper 版本。
卡夫卡使用动物园管理员进行以下操作:
- 管理群集中的节点并维护节点列表。
- 管理所有主题并保留主题列表。
- 选举分区的领导。
- 当在群集中检测到任何更改时通知卡夫卡。这些更改包括主题创建、联机代理和主题删除。
总结
本文件讨论卡夫卡的主要概念和机制。我相信, 看完这篇文章后, 你会对卡夫卡有初步的了解。在接下来的章节中, 我们将执行实际操作, 看看卡夫卡是如何工作的。如果你觉得卡夫卡在使用过程中是稳定和稳健的, 我希望你会喜欢它。