Kafka-реализация отложенной очереди с использованием потребителя высокого уровня

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

while(it.hasNext()) {
    val message = it.next().message()

    if(shouldBeDelayed(message)) {
        val delay = 24 hours
        val delayTo = getCurrentTime() + delay
        putMessageOnDelayedQueue(message, delay, delayTo)
    }
    else {
       process(message)
    }

    consumer.commitOffset()
}

все регулярные сообщения теперь будут обработаны как можно скорее, в то время как те, которые нуждаются в задержке, помещаются на другую тему.

хорошо то, что мы знаем, что сообщение во главе отложенной темы-это то, что должен быть обработан первым, так как его значение delayTo будет наименьшим. Поэтому мы можем настроить другого потребителя, который читает сообщение head, проверяет, находится ли отметка времени в прошлом, и если да, обрабатывает сообщение и фиксирует смещение. Если нет, он не фиксирует смещение и вместо этого просто спит до этого времени:

while(it.hasNext()) {
    val delayedMessage = it.peek().message()
    if(delayedMessage.delayTo < getCurrentTime()) {
        val readMessage = it.next().message
        process(readMessage.originalMessage)
        consumer.commitOffset()
    } else {
        delayProcessingUntil(delayedMessage.delayTo)
    }
}

если есть разные времена задержки, вы можете разделить тему на задержку (например, 24 часа, 12 часов, 6 часов). Если время задержки более динамично это становится немного сложнее. Вы могли бы решить его, введя две темы задержки. Прочитайте все сообщения от темы задержки A и обрабатывать все сообщения, чьи delayTo значение в прошлом. Среди других вы просто найдете тот, который с ближайшим delayTo и затем поставить их на тему B. Спите, пока ближайший не будет обработан, и делайте все наоборот, т. е. обрабатывайте сообщения из темы B и поместите один раз, который еще не должен быть обработан по теме A.

чтобы ответить на ваши конкретные вопросы (некоторые из них были рассмотрены в комментарии на ваш вопрос)

1. фиксация каждого смещения может замедлить ZK

вы можете рассмотреть возможность переключения на сохранение смещения в Кафке (функция доступна с 0.8.2, проверьте offsets.storage свойство в конфигурации потребителя)

1. может потребителя.commitOffsets создает исключение? если да я буду потреблять одно и то же сообщение дважды (может решить с идемпотентными сообщениями)

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

1. проблема долгое время ожидания без фиксации смещения, например, период задержки составляет 24 часа, будет получать следующий от итератора, спать в течение 24 часов, обрабатывать и фиксировать (тайм-аут сеанса ZK ?)

это не будет проблемой с вышеуказанным изложенным решением, если обработка самого сообщения не займет больше времени ожидания сеанса.

1. как сеанс ZK может поддерживать жизнь без фиксации новых смещений ? (установка зоопарка улья.сеанс.тайм-аут.ms может разрешать в Мертвом потребителе, не признавая его)

опять же с вышеизложенным вам не нужно устанавливать длительный тайм-аут сеанса.

1. любые другие проблемы im отсутствует?

там всегда есть ;)