Как потребитель будет читать совершенные сообщения?

Question

Итак, насколько я понимаю из транзакций в Apache Kafka , потребитель read_committed не будет возвращать сообщения, которые являются частью текущей транзакции. Поэтому, я полагаю, у потребителя будет возможность зафиксировать свое смещение за этими сообщениями о текущей транзакции (например, для чтения нетранзакционных сообщений) или возможность не продвигаться дальше, пока обнаруженная транзакция не будет зафиксирована / прервана. Я просто полагаю, что это будет разрешено (Кафкой) пропустить эти записи ожидающих транзакций, но тогда как потребитель будет читать их, когда зафиксировано, учитывая, что его смещение может быть уже далеко?

ОБНОВЛЕНИЕ

Учтите, что topi c может иметь смесь записей (известных сообщений), поступающих от нетранзакционных производителей и транзакционных. Например, рассмотрим этот раздел из топи c:

не-transact-Xmsg, от-transact -roduction1-msg, от-transact-seller2-msg, не-transact- Ymsg

Если потребитель встретит from-transact-seller1-msg , пропустит ли сообщение, затем прочитает non-transact-Ymsg или он просто зависает перед еще не совершенным from-transact-seller1-msg и при этом он не будет читать non-transact-Ymsg ?

Также рассмотрим это может быть много транзакционных производителей и столько эквивалентов from-transact-provider1-msg , некоторые совершенные, а некоторые нет. Таким образом, from-transact-provider2-msg может быть зафиксированным в тот момент, когда потребитель достиг non-transact-Xmsg .

Answer 1

Из документов о isolation.level:

Сообщения всегда будут возвращаться в порядке смещения. Следовательно, в режиме read_committed, consumer.poll() будет возвращать сообщения только до last stable offset (LSO), что меньше, чем смещение первой открытой транзакции. В частности, любые сообщения, появляющиеся после сообщений, относящихся к текущим транзакциям, будут удерживаться до тех пор, пока соответствующая транзакция не будет завершена. В результате read_committed потребители не смогут считаться до верхнего водяного знака, когда есть в полетных операциях.

Answer 2

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