Kafka：主题压缩通知？
Kafka: topic compaction notification?
我得到了以下我正在尝试改进的架构。
我收到一连串的数据库更改，这些更改最终出现在一个紧凑的主题中。流基本上是 key/value 对，密钥空间很大 (~4 GB)。
该主题由一个将数据存储在 RockDB 中的 kafka 流进程使用（每个 consumer/shard 分开）。处理器做两件不同的事情：
- 将数据加入另一个流。
- 检查来自主题的消息是新密钥还是对现有密钥的更新。如果是更新，它会将旧的 key/value 和新的 key/value 对发送到不同的主题（很少更新）。
构造有几个问题：
- 流处理器的两个不同功能属于不同的团队，不应属于同一代码库。它们被放在一起以节省内存。如果我们将它分开，我们将不得不复制 RockDB。
- 我更愿意使用普通的 KTable 连接而不是当前代码中的手工连接。
- 如果数据已经持久化在主题中，RockDB 似乎有点矫枉过正。我们目前 运行 遇到了一些性能问题，我认为如果我们将所有内容都保存在内存中会更快。
问题一：
有没有办法挂钩压缩主题的压缩过程？我想为每个实际压缩的键（包括旧值和新值）通知（到不同的主题）。
如果这在某种程度上是可能的，我可以轻松地将代码库分开并简化连接。
问题二：
关于如何更优雅地解决这个问题还有其他想法吗？
您的整体设计很有意义。
关于您的连接语义：我想您需要坚持使用处理器 API，因为常规 KTable 无法提供您想要的。也无法挂接到压缩过程。
但是，Kafka Streams 还支持 in-memory 状态存储：https://kafka.apache.org/documentation/streams/developer-guide/processor-api.html#state-stores
默认使用 RocksDB，允许状态大于可用 main-memory。使用 RocksDB 溢出到磁盘以确保可靠性——但是，它也有一个优势，如果一个实例在同一台机器上恢复在线，则可以更快地重新创建存储，因为它不需要 re-read 整个更新日志主题。
如果您想将应用一分为二，您可以自行决定要提供多少资源。
我得到了以下我正在尝试改进的架构。
我收到一连串的数据库更改，这些更改最终出现在一个紧凑的主题中。流基本上是 key/value 对，密钥空间很大 (~4 GB)。
该主题由一个将数据存储在 RockDB 中的 kafka 流进程使用（每个 consumer/shard 分开）。处理器做两件不同的事情：
- 将数据加入另一个流。
- 检查来自主题的消息是新密钥还是对现有密钥的更新。如果是更新，它会将旧的 key/value 和新的 key/value 对发送到不同的主题（很少更新）。
构造有几个问题：
- 流处理器的两个不同功能属于不同的团队，不应属于同一代码库。它们被放在一起以节省内存。如果我们将它分开，我们将不得不复制 RockDB。
- 我更愿意使用普通的 KTable 连接而不是当前代码中的手工连接。
- 如果数据已经持久化在主题中，RockDB 似乎有点矫枉过正。我们目前 运行 遇到了一些性能问题，我认为如果我们将所有内容都保存在内存中会更快。
问题一： 有没有办法挂钩压缩主题的压缩过程？我想为每个实际压缩的键（包括旧值和新值）通知（到不同的主题）。 如果这在某种程度上是可能的，我可以轻松地将代码库分开并简化连接。
问题二： 关于如何更优雅地解决这个问题还有其他想法吗？
您的整体设计很有意义。
关于您的连接语义：我想您需要坚持使用处理器 API，因为常规 KTable 无法提供您想要的。也无法挂接到压缩过程。
但是，Kafka Streams 还支持 in-memory 状态存储：https://kafka.apache.org/documentation/streams/developer-guide/processor-api.html#state-stores
默认使用 RocksDB，允许状态大于可用 main-memory。使用 RocksDB 溢出到磁盘以确保可靠性——但是，它也有一个优势，如果一个实例在同一台机器上恢复在线，则可以更快地重新创建存储，因为它不需要 re-read 整个更新日志主题。
如果您想将应用一分为二，您可以自行决定要提供多少资源。