我正在研究Flink超过一个星期。我们正在使用来自Kafka的事件，我们希望事件属于需要按照事件时间顺序处理的特定对象id。到目前为止，我的研究告诉我，我应该使用keyby和timeWindows，我的理解正确吗？
另一个问题，当一个任务管理器发生故障时，只有那些属于该任务管理器的事件才会停止处理，直到任务管理器启动为止？检查点机制是否知道未处理的事件，它将如何向Kafka请求这些事件？
以下使用案例的问题
在CallCenter中，座席将接听电话并进入不同的状态。对于代理的每个操作（例如登录，空闲，忙碌等），我们都会通过Kafka获得该操作的代理事件作为状态。要求是我们必须按代理顺序处理事件，我们无法在登录事件之前处理代理空闲事件。我们需要对它们进行处理，以便在需要扩展的同时进行。
在具有并行进程的Flink集群中，我们不应最终以代理处于不良状态来处理不同分区/ TaskSlot中的代理信息。我的问题是keyBy agentId会将流划分为子流，并始终在指定的分区中对其进行处理，从而保持事件处理的顺序。
另外，另一个问题是该分区是否有异常/任务管理器正在处理特定的代理数据，Flink如何知道在恢复后仅请求那些代理事件。
答案 0 :(得分：1)
您将要使用keyBy（objectId）按对象ID对流进行分区。
如果必须按事件时间对流进行排序，则有两种选择。您可以使用Windows创建要在ProcessWindowFunction中排序（按批处理）的事件的批处理，也可以使用KeyedProcessFunction创建连续的有序流。 Here's an example。
Flink中的检查点是全局的。它们包括Kafka中的偏移量，以及分布式群集中由于摄取输入直到这些偏移量而导致的所有状态。恢复包括重新启动集群，恢复集群状态，将Kafka使用方倒退到检查点中记录的偏移量，以及从该点重播事件。请注意，如果您的接收器不是事务性的，则可能导致写入重复的结果。
更新：
如果每个密钥的所有数据仅在一个Kafka分区中，并且您的数据已经在Kafka中进行了排序（不是全局排序，而是在每个密钥中），那么Flink将保留该顺序，即使您做一个关键。之所以可行，是因为任何给定的Kafka分区仅由Flink Kafka源的一个实例使用。
对于第二个问题，只有一个任务管理器出现故障并不重要。所有任务管理器都将重新启动，并且它们都将倒退并从最新检查点中存储的偏移量恢复处理。检查点是全局的，覆盖整个群集-不支持部分恢复。