Kafka 消息写入延迟答案

【问题标题】：Kafka message write latencyKafka 消息写入延迟
【发布时间】：2019-07-26 03:03:25
【问题描述】：

我们正在尝试测量 Infosphere CDC-Confluent kafka 设置中消息写入的延迟。我们有虚拟表，将执行虚拟事务。

数据流- MF DB2 表 --> IIDR --> Kafka 主题

（对于 Kafka，生产者是 iidr）

在没有任何企业监控工具的情况下找出示例事务的写入延迟的正确方法是什么？我们可以检查写入日志并考虑每个事务时间戳并与 cdc 事务日志进行比较以找出写入延迟吗？

PS- 我已将 jconsole 配置为收集 kafka 指标。但是我们如何才能找到特定 CDC 流到 kafka 主题的写入延迟？

谢谢！

【问题讨论】：

样本交易的延迟是什么意思？在 Kafka 中还是在整个事务中？如果您只需要 Kafka 中的延迟，请查看 this
这意味着一旦我们在 DB2 源执行了一些事务（比如 50 个），在 Kafka 中获得写入确认需要多长时间？数据流将是 db2-->IIDR(CDC)-->Kafka。
理想情况下，我们想要整个事务的延迟。但是即使我们发现了 kafka 中的延迟，我们也可以借助 IIDR(CDC) 日志中的响应时间来估计整个事务的延迟。

【解决方案1】：

（仅供参考：我为 IBM 工作，特别是 IDR CDC 产品）

IDR 复制产品中的集成 KCOP（Kafka 自定义操作处理器）在创建 Kafka 生产者记录时不提供时间戳参数。如果您使用没有 KCOP 的默认行为，也会出现这种情况。

因此，Kafka 会在收到每个生产者记录时为其生成一个时间戳，并将其与记录相关联。读取消息时，此时间戳值包含在消费者记录中。

这可以通过减法与源生成的时间进行比较。有一个时间戳日志控制字段，可以与行数据一起复制。在某些来源（例如 Db2 LUW）上，它表示事务的提交时间。 On some 表示将特定行添加到日志中的时间。

一般来说，我认为最好从提交实际生效时考虑延迟，但这取决于您要了解的内容。

我相信在 DB2 Z 上，每一个都是操作日志条目的时间，您可以通过使用事务中最后一个操作的时间戳条目来粗略估计。这忽略了写入最后一个事务和实际提交之间的延迟量，但通常它们非常接近。

IDR 确实提供了功能增强请求，因此如果您希望看到增强功能，请随时通过支持或此联系。

问候，

【讨论】：