我有一个{@ {3}}的要求，等待直到窗口关闭为止，以便通过在窗口持续时间内对其进行缓冲来处理延迟故障事件。
据我对此功能的理解是，一旦创建了窗口，该窗口的工作就类似于壁钟处理，例如创建1小时的窗口，一旦第一个事件到来，该窗口就会开始滴答。该1小时窗口恰好在一小时后关闭，到目前为止，所有缓冲的事件都将转发到下游。但是，我需要能够将这个窗口保持更长的时间，比如说需要的时间。基于外部系统（例如数据库）中的状态/信息。
准确地说，我对事件转发的要求是（如果外部状态记录表示良好，则为1个小时的窗口）或（保持所需的时间，直到外部记录表示良好，并继续跟踪事件，直到事件发生为止）完全1小时，不考虑外部系统不好的时间） 要详细说明第二个条件，例如如果我的窗口持续时间为1 1hr，我的事件开始于00:00，如果事件在00:30降下来并在00:45返回正常，则窗口应延长到01:15。
是否可以根据我上面的要求有条件地暂停和恢复事件的转发？ 我是否必须使用转换/处理器并手动使用值存储来跟踪事件的首次处理时间并有条件地在标点符号中转发缓冲的事件？
我很高兴能为您提供各种解决方法和建议。
答案 0 :(得分：0)
窗口的工作方式类似于壁钟处理
不。 Kafka Streams在事件时间上工作，因此，从TimestampExtractor返回的时间戳（默认情况下为嵌入式记录时间戳）用于提前时间。
准确地说，我对事件转发的要求是（如果外部状态记录说很好，则为1小时的窗口）
这将需要自定义解决方案恕我直言。
或者（（在外部记录显示良好之前，保持所需的时间，并继续跟踪事件，直到事件完全变为1小时为止，而无需考虑外部系统故障的时间）
如果我理解这一部分，则不是100％。
是否可以根据我上面的要求有条件地暂停和恢复事件的转发？
否。
我是否必须使用转换/处理器并手动使用值存储来跟踪事件的首次处理时间并有条件地在标点符号中转发缓冲的事件？
我认为这可能是必需的。
请查看此博客文章，其中详细说明了suppress()的工作方式以及根据观察到的事件时间发出时间的时间：https://www.confluent.io/blog/kafka-streams-take-on-watermarks-and-triggers