XAUTOCLAIM

XAUTOCLAIM

XAUTOCLAIM key group consumer min-idle-time start [COUNT count]
  [JUSTID]

Доступно с версии:

6.2.0

Сложность по времени:

O(1), если COUNT небольшой.

Категории ACL:

@write, @stream, @fast,

Эта команда переносит владение ожидающим записям потока, которые соответствуют указанным критериям. Концептуально, XAUTOCLAIM эквивалентно вызову XPENDING и затем XCLAIM, но предоставляет более простой способ обработки отказов доставки сообщений с помощью семантики, похожей на SCAN.

Как и XCLAIM, команда работает с записями потока в <key> и в контексте предоставленного <group>. Она переносит владение сообщениям, ожидающим более <min-idle-time> миллисекунд и имеющим идентификатор равный или больший <start>, в <consumer>.

Необязательный аргумент <count>, который по умолчанию равен 100, является верхним пределом количества записей, которые команда пытается получить. Внутренне команда начинает сканировать список ожидающих записей группы потребителей (PEL) с <start> и отфильтровывает записи, у которых время простоя меньше или равно <min-idle-time>. Максимальное количество ожидающих записей, которые сканирует команда, равно произведению значения <count> на 10 (закодировано в коде). Поэтому возможно, что количество полученных записей будет меньше заданного значения.

Необязательный аргумент JUSTID изменяет ответ, чтобы вернуть только массив идентификаторов успешно полученных сообщений, не возвращая фактическое сообщение. Использование этого параметра означает, что счетчик повторных попыток не увеличивается.

Команда возвращает полученные записи в виде массива. Она также возвращает идентификатор потока, предназначенный для использования в стиле курсора, как аргумент <start> для последующего вызова. Когда больше нет записей в PEL, команда возвращает специальный идентификатор 0-0 для сигнализации об окончании. Однако обратите внимание, что вы можете продолжить вызывать XAUTOCLAIM даже после завершения сканирования с 0-0 как идентификатором <start>, так как прошло достаточно времени, и более старые ожидающие записи могут теперь быть доступны для получения.

Обратите внимание, что получают только сообщения, время простоя которых больше <min-idle-time>, и получение сообщения сбрасывает его время простоя. Это гарантирует, что только один потребитель может успешно получить определенное ожидающее сообщение в определенный момент времени и тривиально уменьшает вероятность обработки одного и того же сообщения несколько раз.

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

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

Возврат

Массивный ответ, а именно:

Массив из трех элементов:

1. Идентификатор потока, который должен быть использован как аргумент <start> для следующего вызова XAUTOCLAIM.
2. Массив, содержащий все успешно полученные сообщения в том же формате, что и XRANGE.
3. Массив, содержащий идентификаторы сообщений, которые больше не существуют в потоке и были удалены из PEL, в котором они были найдены.

Примеры

> XAUTOCLAIM mystream mygroup Alice 3600000 0-0 COUNT 25
1) "0-0"
2) 1) 1) "1609338752495-0"
      2) 1) "field"
         2) "value"
3) (empty array)

В приведенном выше примере мы пытаемся получить до 25 записей, которые ожидают и простаивают (не были подтверждены или получены) не менее одного часа, начиная с начала потока. Потребитель "Alice" из группы "mygroup" получает владение этими сообщениями. Обратите внимание, что возвращенный в примере идентификатор потока — это 0-0, что указывает на то, что весь поток был просканирован. Мы также видим, что XAUTOCLAIM не обнаружил удаленных сообщений (третий элемент ответа — пустой массив).

История

• Начиная с версии Redis 7.0.0: Добавление элемента в массив ответа, содержащего удаленные записи, очищенные командой из PEL