我们正在使用Kafka stream的SessionWindows来聚合相关事件的到来。与聚合一起，我们使用until() API指定窗口的保留时间。流信息：
会话窗口（不活动时间）为1分钟，传递给until()的保留时间为2分钟。我们使用定制的TimestampExtractor来映射事件的时间。
例： 事件：e1; eventTime：上午10:00:00;到达时间：下午2点（当天） 事件：e2; eventTime：上午10:00:30;到达时间下午2:10（当天） 第二次活动的到达时间是e1到达后10分钟，超过了保留时间+不活动时间。但是旧的事件e1仍然是聚合的一部分，尽管保留时间为2分钟。
问题：
1）kafka如何使用until() API清理状态存储？由于指定为参数的保留值是“维持窗口多长时间的下限”。什么时候清除窗户？
2）是否有后台线程定期清理状态存储？如果是，那么有没有办法确定窗口被清除的实际时间。
3）在保留时间之后清除窗口数据的任何流配置。
在回答您的具体问题之前：请注意，保留时间不是基于系统时间，而是基于“流时间”。 “流时间”是基于TimestampExtractor返回的内部跟踪时间进度。没有太多细节：对于你的2条记录的例子，当第二条记录到达时，“流时间”将提前30秒，因此保留时间尚未过去。
另请注意，如果没有新数据到达（至少一个分区），则“流时间”不会提前。这适用于Kafka 0.11.0及更早版本，但在将来的版本中可能会有所改变。
更新：在Kafka 2.1中更改了流时间的计算，即使一个分区不提供数据，流时间也可能会提前。有关详细信息，请参阅KIP-353: Improve Kafka Streams Timestamp Synchronization
对你的问题：
（1）Kafka Streams将所有商店更新写入changelog主题和本地RocksDB商店。两者都分为具有一定大小的所谓段。如果新数据到达（即“流时间”进展），则创建新段。如果发生这种情况，如果旧段中的所有记录都早于保留时间（即，记录时间戳小于“流时间”减去保留时间），则删除旧段。
（2）因此，没有后台线程，但清理是常规处理的一部分，
（3）没有强制清除旧记录/窗口的配置。
如果所有记录都已过期，则会删除整个段，段中的旧记录（很可能是较小/较旧的时间戳）的保留时间比保留时间长。这种设计背后的动机是性能：在每个记录的基础上到期将太昂贵。