Как такая система, как Kafka, обеспечивает порядок внутри раздела

Question

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

Цитирование статьи:

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

Что я не понимаю, так это то, как Кафка следит за тем, чтобы он добавлялся в журнал в порядке, который пользователь намеревается .Не может ли быть состояние гонки, когда пользователь отправляет сначала объект A, а затем объект B, но сначала записывается в журнал B

ПРИМЕЧАНИЕ : Я понимаю, что порядок не может быть гарантированчерез перегородки.Это касается порядка внутри раздела.

Примечание: Согласно другой статье , commit-log только для добавления является абстракцией для множества систем, поэтому это может прояснить многоеи другие вещи.

Answer 1

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

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

Если для параметра retries задано ненулевое значение, а для max.in.flights.requests.per.session более одного означает, что возможно, что посреднику не удастся записать первый пакет сообщений, успешнозаписать вторую (которая уже находилась в полете), а затем повторить попытку первой партии и выполнить ее, тем самым изменив порядок.

Обычно установка числа повторных попыток в ноль не является надежной системой, поэтому если гарантированный порядок важен, мы рекомендуем установить in.flight.requests.per.session = 1, чтобы убедиться, что покапакет сообщений повторяется, дополнительные сообщения не будут отправлены (потому что это может изменить правильный порядок).Это сильно ограничит пропускную способность производителя, поэтому используйте его только тогда, когда важен порядок.

from: Руководство по Kafka

UPDATE-1

Итак, я немного покопался в исходном коде производителя Kafka.Очевидно, производитель добавляет записи в запись аккумулятор и затем отправляет все записи в аккумуляторе посреднику (ам) после того, как партия заполнена или прошло достаточно много времени.С каждой записью связана временная метка.Я думаю, что брокер (-ы) добавляют записи в порядке метки времени к теме и, следовательно, обеспечивают поддержание порядка в пределах раздела.Кто-то, кто лучше знает внутренности Кафки, может согласиться с тем, чтобы отвергнуть эту гипотезу.

UPDATE-2

Как указано cricket_007 в комментариях, порядок элементов, выбираемых из аккумулятора, не зависит отметка времени.Аккумулятор является очередью, поэтому порядок вставки и извлечения одинаков.

Answer 2

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

Чтобы гарантировать порядок, вы предоставляете ключ, производитель будет использовать этот ключ в алгоритме секционирования по умолчанию , это примерно так:

hash(key)%numPartitions = partition

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