Spec-Zone.ru › Redis

XCLAIM

XCLAIM
Синтаксис
XCLAIM key group consumer min-idle-time id [id ...] [IDLE ms]
  [TIME unix-time-milliseconds] [RETRYCOUNT count] [FORCE] [JUSTID]
  [LASTID lastid]
Доступно с версии:
5.0.0
Сложность по времени:
O(log N), где N — количество сообщений в списке ожидающих сообщений (PEL) группы потребителей.
Категории ACL:
@write, @stream, @fast,

В контексте группы потребителей потока эта команда меняет владение ожидающим сообщением, так что новым владельцем становится потребитель, указанный в качестве аргумента команды. Обычно происходит следующее:

  1. Существует поток с ассоциированной группой потребителей.
  2. Некоторый потребитель A считывает сообщение через XREADGROUP из потока в контексте этой группы потребителей.
  3. В качестве побочного эффекта в списке ожидающих сообщений (PEL) группы потребителей создается запись ожидающего сообщения: это означает, что сообщение было доставлено данному потребителю, но еще не подтверждено с помощью XACK.
  4. Затем этот потребитель навсегда выходит из строя.
  5. Другие потребители могут проверить список ожидающих сообщений, которые давно простаивают, используя команду XPENDING. Для продолжения обработки таких сообщений они используют XCLAIM для получения владения сообщением и продолжения. Потребители также могут использовать команду XAUTOCLAIM для автоматического сканирования и захвата устаревших ожидающих сообщений.

Эта динамика подробно описана в документации по потокам.

Обратите внимание, что сообщение захватывается только в том случае, если время простоя превышает минимальное время простоя, которое мы указываем при вызове XCLAIM. Поскольку в качестве побочного эффекта XCLAIM также сбросит время простоя (поскольку это новая попытка обработки сообщения), два потребителя, пытающиеся захватить одно и то же сообщение одновременно, никогда не смогут оба преуспеть: только один успешно захватит сообщение. Это предотвращает обработку одного и того же сообщения несколько раз тривиальным способом (хотя множественная обработка возможна и неизбежна в общем случае).

Кроме того, в качестве побочного эффекта XCLAIM увеличит счет попыток доставки сообщения, если не указан параметр JUSTID (который возвращает только идентификатор сообщения, а не само сообщение). Таким образом, сообщения, которые по какой-либо причине не могут быть обработаны, например, из-за сбоя потребителей при попытке их обработки, будут иметь больший счетчик и могут быть обнаружены в системе.

XCLAIM не захватит сообщение в следующих случаях:

  1. Сообщение не существует в PEL группы (т.е. его никогда не считывал ни один потребитель)
  2. Сообщение существует в PEL группы, но не в самом потоке (т.е. сообщение было прочитано, но не подтверждено, а затем было удалено из потока, либо путем обрезки, либо с помощью XDEL)

В обоих случаях ответ не будет содержать соответствующей записи для этого сообщения (т.е. длина массива ответа может быть меньше количества идентификаторов, предоставленных команде XCLAIM). В последнем случае сообщение также будет удалено из PEL, в котором оно было найдено. Эта функция была добавлена в Redis 7.0.

Параметры команды

Команда имеет несколько параметров, однако большинство из них предназначены в основном для внутреннего использования, чтобы передать эффекты XCLAIM или других команд в файл AOF и распространить те же эффекты на реплики, и они вряд ли будут полезны обычным пользователям:

  1. IDLE <ms>: Устанавливает время простоя (последний раз оно было доставлено) сообщения. Если IDLE не указан, предполагается IDLE равным 0, то есть счет времени сбрасывается, потому что у сообщения теперь есть новый владелец, пытающийся его обработать.
  2. TIME <ms-unix-time>: Это то же самое, что и IDLE, но вместо относительного значения в миллисекундах оно устанавливает время простоя на определенное время Unix (в миллисекундах). Это полезно для переписывания файла AOF, генерирующего XCLAIM команды.
  3. RETRYCOUNT <count>: Устанавливает счетчик повторных попыток на указанное значение. Этот счетчик увеличивается каждый раз, когда сообщение доставляется повторно. Обычно XCLAIM не изменяет этот счетчик, который просто предоставляется клиентам при вызове команды XPENDING: таким образом клиенты могут обнаруживать аномалии, такие как сообщения, которые по какой-то причине не обрабатываются после большого числа попыток доставки.
  4. FORCE: Создает запись ожидающего сообщения в PEL, даже если некоторые указанные идентификаторы еще не находятся в PEL, назначенные другому клиенту. Однако сообщение должно существовать в потоке, в противном случае идентификаторы несуществующих сообщений игнорируются.
  5. JUSTID: Возвращает только массив идентификаторов успешно захваченных сообщений, не возвращая само сообщение. Использование этого параметра означает, что счетчик повторных попыток не увеличивается.

Возврат

Ответ в виде массива, а именно:

Команда возвращает все успешно захваченные сообщения в том же формате, что и XRANGE. Однако если был указан параметр JUSTID, то сообщаются только идентификаторы сообщений, без включения самого сообщения.

Примеры

> XCLAIM mystream mygroup Alice 3600000 1526569498055-0
1) 1) 1526569498055-0
   2) 1) "message"
      2) "orange"

В приведенном выше примере мы захватываем сообщение с идентификатором 1526569498055-0, только если сообщение простаивает не менее одного часа без того, чтобы исходный потребитель или какой-либо другой потребитель делали какие-либо шаги по обработке (подтверждение или захват), и назначаем владение потребителю Alice.

© 2006–2022 Salvatore Sanfilippo
Licensed under the Creative Commons Attribution-ShareAlike License 4.0.
https://redis.io/commands/xclaim/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API