Question

当我未设置 processing.gurantee 时，这意味着流将以其默认值（ at_least_once ）启动，此代码可以成功记录并向相关的发送消息话题。

在同一流应用程序上启用 exactly_once 配置后，某些数据将无法成功通过联接。即使第一个peek块都有日志，我也看不到一些第二个peek日志和一些我需要的消息。

我确定kstream和ktable都必须具有不为null的值。双方都定期收到消息。

流配置：

processing.guarantee = exactly_once
replication.factor = 3（这会增加内部主题的复制因子）

Kafka（有3个经纪人）详细信息：

version = 2.2.0
log.roll.ms = 3600000
offsets.topic.replication.factor = 3
transaction.state.log.replication.factor = 3
transaction.state.log.min.isr = 3
message.max.bytes = 2000024

问题是， exactly_once 处理保证设置如何导致这种情况？

final KStream<String, UserProfile> userProfileStream = builder.stream(TOPIC_USER_PROFILE);
final KTable<String, Device> deviceKTable = builder.table(TOPIC_DEVICE);

userProfileStream
.peek((genericId, userProfile) ->
    log.debug("[{}] Processing user profile: {}", openUserId, userProfile)
)
.join(
    deviceKTable,
    (userProfile, device) -> {
        userProfile.setDevice(device);

        return userProfile;
    },
    Joined.with(Serdes.String(), userProfileSerde, deviceSerde)
)
.peek((genericId, userProfile) ->
    log.debug("[{}] Updated user profile: {}", genericId, userProfile)
)
.to(TOPIC_UPDATED_USER_PROFILE, Produced.with(Serdes.String(), userProfileSerde));

Answer 1

有关此问题的更多信息，也在Confluent邮件小组中进行讨论：https://groups.google.com/d/msg/confluent-platform/MRjz8MRBDCg/XbVlJI0hBAAJ

KStream-KTable内部联接丢失的消息仅具有一次配置

1 个答案: