Отказ от ответственности:
- этот ответ предполагает, что вы имеете в виду Redis Streams (введено в Redis 5.0).
Я не Конечно, что вы подразумеваете под «событием», я прокомментировал в ОП с просьбой дать разъяснения. Я постараюсь ответить без этих уточнений и отредактирую свой ответ, как только вы проясните понятия. См. Мое редактирование в конце.
В идентификаторах Redis Streams также используется последовательный идентификатор, как объяснено в документации по команде XADD :
Идентификаторы задаются двумя числами, разделенными символом - [...]
Обе величины являются 64-битными числами. Когда идентификатор генерируется автоматически, первая часть - это время Unix в миллисекундах для экземпляра Redis, генерирующего идентификатор. Вторая часть является просто порядковым номером и используется для различения guish идентификаторов, сгенерированных за одну и ту же миллисекунду.
Идентификаторы гарантированно всегда будут инкрементными
Поскольку сервер Redis (в основном) однопоточный , запросы обрабатываются в том же порядке, в котором их получает сервер Redis, и новый запрос не обрабатывается до тех пор, пока не будет получен последний ответ.
Однако на это могут влиять проблемы сети. Рассмотрим следующее (NETWORK - это когда сообщение находится в пути):
Time Cli1 Cli2 Redis Server
1 XADD -----------------> Processing Cli1 Request
2 NETWORK <------ Answer: ID 1
3 XADD -----> Processing Cli2 Request
4 ID 2 <----- Answer: ID 2
5 ID 1 <--NETWORK
Если Cli1 и Cli2 сравнивают свои ответы и время получения, кажется , что Сервер обработал запросы в неправильном порядке, но для сервера все в порядке.
Кроме того, если запрос Cli2 поступил, пока сервер обрабатывал запрос Cli1, он дождался бы завершения обработки Cli1, чтобы начать обработку Cli2.
Отредактируйте после того, как ОП отредактировал вопрос
В разделе Различия с разделами Kafka на странице документации Введение в Redis Streams указано, что:
Если вы используете 1 поток -> N потребителей, вы балансируете нагрузку на N потребителей, однако в этом случае сообщения об одном и том же логическом элементе могут потребляться не по порядку, поскольку данный потребитель может обрабатывать сообщение 3 быстрее, чем другой потребитель обрабатывает сообщение. 4.
Таким образом, в основном разделы Kafka больше похожи на использование N различных ключей Redis. В то время как группы потребителей Redis представляют собой систему балансировки нагрузки на стороне сервера для сообщений от данного потока к N различным потребителям.
Таким образом, функция групп потребителей в Redis не служит той же цели, что и Kafka.
Можно выполнить желаемую группировку, используя несколько клавиш Redis и пометив каждый использованный заказ, но (AFAIK) Redis не предоставляет эту функцию, поэтому вам нужно реализовать ее самостоятельно.