Kafka内部数据管理
有人能帮我理解在以下情况下会发生什么吗：
来自主题A的流在其上执行了一些不同的操作，这些操作会导致生成多个内部Kafka主题，例如：KSTREAM-REDUCE-00000000 14 KSTREAM-JOIN-0000000 358等。
它们在拓扑中显示为“消费者组名生成的名称”
话题A加入话题B。。。B必须重新输入才能与A加入内部主题“组重新输入B”。
如果我的拓扑结构发生变化，那么除非所有这些内部主题的名称相同，否则我需要更改我的消费者组名称，或者随机生成的KSTREAM-REDUCE-00000000 14可能包含不同类型的对象。
如果我将新消费群体的补偿设置为前一消费群体的最新promise，我们就不会从头开始重播主题A或主题B。
这些内部话题会发生什么？例如，“group Re KeyB”是否拥有加入a的所有数据，还是只知道新的主题B记录？？
共有1个答案
如果更改拓扑和名称，新旧拓扑很可能不兼容，建议重置应用程序，让新拓扑从头开始重新处理所有数据（以重建所需的内部状态）：https://docs.confluent.io/current/streams/developer-guide/app-reset-tool.html
作为替代方案，您可以为所有操作符指定显式名称（从Kafka Stream 2.4开始），例如，您可以使用materialized。作为（…）以命名状态存储和相应的变更日志主题。显式命名避免了内部主题名称的更改，因此，即使您更改了拓扑，也可以在不使用新的应用程序的情况下重新启动新拓扑。id，从而保留旧拓扑的状态。
-
在我的公司，我们广泛使用Kafka，但出于容错的原因，我们一直使用关系数据库来存储几个中间转换和聚合的结果。现在我们正在探索Kafka流作为一种更自然的方法来做到这一点。通常，我们的需求很简单--其中一个例子是 监听的输入队列 对每个记录执行一些高延迟操作（调用远程服务） 如果在处理时，都已生成，那么我应该处理V3，因为V2已经过时了 为了实现这一点，我将主题作为阅读。代码如下所示 这是预期的，但
-
问题内容： 我想知道Swift如何在内部管理数组？Apple的语言指南仅处理用法，而未详细说明内部结构。 作为一名Java开发人员，我习惯于将“裸”数组视为一种非常静态和固定的数据结构。我知道这在Swift中是不正确的。除了Java之外，在Swift中，您可以更改数组的长度，还可以执行插入和删除操作。在Java中，我习惯于根据要对该结构执行的操作来决定要使用哪种数据结构（简单数组，ArrayLis
-
问题内容： 我正在尝试使用docker-compose启动kafka服务，并且应该可以在docker内部和外部进行访问。因此，应该在内部和外部设置合适的广告客户： 问题是，当我尝试从群集外部进行连接时，节点名称不是127.0.0.1，而是内部主机名： 这不是KAFKA_ADVERTISED_LISTENERS和KAFKA_LISTENERS处理这种情况的目的吗？我尝试设置KAFKA_ADVERTI
-
CInode CInode 包含某一文件的元数据，每个文件都有一个 CInode 。它存储着类似谁拥有这个文件、此文件有多大这样的信息。 CDentry CDentry 用于把索引节点和文件（或目录）名关联到一起。一个 CDentry 最多可链接到一个 CInode （也可以不链接任何 CInode ），一个 CInode 可被多个 CDentry 链接。 CDir CDir 仅存在于目录索引节点
-
固定映射地址和输入输出重映射 固定映射地址是一组特殊的编译时确定的地址，它们与物理地址不一定具有减 __START_KERNEL_map 的线性映射关系。每一个固定映射的地址都会映射到一个内存页，内核会像指针一样使用它们，但是绝不会修改它们的地址。这是这种地址的主要特点。就像注释所说的那样，“在编译期就获得一个常量地址，只有在引导阶段才会被设定上物理地址。”你在本书的前面部分可以看到，我们已经设定
-
简介 内存管理是操作系统内核中最复杂的部分之一(我认为没有之一)。在讲解内核进入点之前的准备工作时，我们在调用 start_kernel 函数前停止了讲解。start_kernel 函数在内核启动第一个 init 进程前初始化了所有的内核特性(包括那些依赖于架构的特性)。你也许还记得在引导时建立了初期页表、识别页表和固定映射页表，但是复杂的内存管理部分还没有开始工作。当 start_kernel