Флинк приводит здесь пример: https://www.ververica.com/blog/stream-processing-introduction-event-time-apache-flink, который описывает сценарий, когда кто-то играет в игру, теряет соединение из-за метро, а затем, когда он снова подключается к сети, все данные возвращаются и могут быть отсортированы и обработаны.
Насколько я понимаю, при наличии большего числа игроков возможны два варианта:
Все остальные будут отложены в ожидании, когда этот пользователь вернётся назад и отправит сообщение. данные, позволяющие толкать водяной знак;
Этот пользователь классифицируется как бездействующий, позволяющий водяному знаку двигаться вперед, и когда он подключится, все его данные перейдут в поздний поток данных;
Я хотел бы иметь следующую опцию: Каждый пользователь обрабатывается независимо со своим водяным знаком для своего окна сеанса. В идеале я бы даже использовал время приема (поэтому, когда он получит соединение обратно, я помещу все данные в один уникальный сеанс, который будет позже упорядочен по метке времени события после закрытия сеанса), и между текущим временем и последним будет разрыв. отметка времени (прием) окна, которое я обрабатываю (окно сеанса гарантирует это на основе промежутка времени, который завершает сеанс);Я также не хочу, чтобы водяной знак застревал, когда один пользователь теряет соединение, и я также не хочу управлять незанятыми состояниями: просто продолжайте обрабатывать все остальные события в обычном режиме, и как только этот пользователь вернется, не классифицируйте никакие данные как поздние. из-за того, что водяной знак продвигается во времени по сравнению с моментом, когда пользователь потерял соединение;
Как я могу выполнить вышеуказанное требование? Мне было трудно работать без таких сценариев, потому что водяной знак был глобальным. Есть ли простое объяснение отсутствия водяных знаков для каждой клавиши?
Заранее спасибо!