Kafka事务流由基础到实践
|
完成后，按CTRL + D键完成消息发布。然后切换回Kafdrop，然后单击streams-intro主题。将看到该主题的概述以及基础分区的详细分类：  我们创建了一个包含三个分区的主题。然后，我们使用两个唯一的键foo和bar发布了五条记录。Kafka使用键将记录映射到分区，这样具有相同键的所有记录将始终出现在同一分区上。很方便，也很重要，它可以使发布者指定准确的记录顺序。稍后，我们将更详细地讨论键哈希和分区分配。 查看分区表，分区#0的第一个和最后一个偏移分别为0和2。分区#2的值为零和3个，而分区#1的显示为空白。在Kafdrop网络用户界面中单击#0，会将会转到主题查看器：  可以看到在bar键下发布的两条记录。注意，它们与foo记录完全无关。 消费者和消费组 上面我们实例讲了，听过生产者发布消息，将记录发送到流中。这些记录被组织成井井有条的分区。Kafka的发布-订阅拓扑遵循灵活的多到多模型，所以，可以有任意数量的生产者和消费者同时与流进行交互。根据实际的解决方案，流拓扑也可以一对多，多对一。下面我们讲，如何消费这些记录。 消费者是通过客户端库连接到Kafka集群的进程或线程。消费者通常(但不一定)是一个整体消费组的成员。该组由group.id属性指定。消费组实际上是Kafka中的负载平衡机制，负责在组内的各个消费者实例之间大致平均地进行分区分配。当组中的第一个消费者订阅该主题时，它将收到该主题中的所有分区。当第二个消费者随后加入时，它将获得大约一半的分区，从而减轻了第一个使用者的负担。当消费者离开时(通过断开连接或超时)，该过程将反向进行，其余的使用者将可用更多数量的分区。 因此，消费者消费某个主题中的记录，从Kafka及其所属的其他消费者分配的分区中提取了份额。就负载平衡而言，这应该非常简单。但是，这里有一个关键点，使用记录的行为并不能将其删除。起初这似乎是矛盾的，特别是如果将消耗行为与消耗联系起来。(如果有的话，应该将消费者称为"阅读者"。)一个简单的事实是，消费者对主题及其分区绝对没有任何影响。主题是仅追加，只能由生产者或Kafka本身(作为压缩或清除的一部分)进行追加记录。消费者的只读操作是"便宜的"，因此，可以让许多人在不增加集群负担的情况下tail日志。这是事务流和传统消息队列之间的又一区别，这是至关重要的。 消费者在内部维护一个偏移量，该偏移量指向分区中的下一个记录，从而在每次连续读取时都增加偏移量。消费者首次订阅主题时，可以选择从主题的头端或尾端开始。通过将auto.offset.reset属性设置为latest, earliest 或者none，可以控制这个行为。在后一种情况下，如果消费者组不存在先前的偏移量，则将触发异常。 消费者在本地保留其偏移状态向量。由于不同消费组中的消费者不会互相干扰，因此可能有许多人同时阅读同一主题。消费者按照自己的偏移读取消息;缓慢的或积压的消费者对其同组其他人也不会有影响。 为了说明这个概念，我们考虑一个包含两个分区的主题为场景。两个消费者组-A和B-订阅了该主题。每个组具有三个实例，使用者被命名为A1，A2，A3，B1，B2和B3。下图说明了两组如何共享主题，以及消费者如何彼此独立地浏览记录。  仔细看上图，会发现缺少某些东西。消费者A3和B1不在上图中。这是因为Kafka保证分区只能分配给其消费组中的一个消费者。由于每个组中有三个消费者，但是只有两个分区，因此一个消费者将保持空闲状态，等待其所在组中的另一个消费者离开。以这种方式，消费组不仅是负载平衡机制，而且还是用于建立高性能管道而又不牺牲安全性的类似栅栏的排他性控制，特别是在要求只能由一个线程处理记录的情况下或在任何给定时间进行处理。 消费组也用于确保可用性。通过定期从主题中提取记录，消费者可以向集群隐式反馈集群为"健康"状态，从而将租约扩展到其分区分配上。但是，如果消费者未能在允许的期限内再次阅读，则将其视为有缺陷，并且将重新分配其分区，分配给该组中其余的"健康"消费者。该截止日期由max.poll.interval.ms在消费者客户端属性控制，默认情况下设置为五分钟。 用交通系统来做个类比，主题就像是高速公路，分区就是车道。记录就是等同于汽车，其乘客对应于记录值。只要保持行车路线，几辆车就可以安全地在同一条高速公路上行驶。共享相同线路的汽车按顺序行驶，形成队列。现在，假设每条车道通向一个匝道，将其流量转移到某个位置。如果一个匝道堆积了，其他匝道可能仍能顺畅流动。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
