Comments 24
Порядок сообщений зависит от времени приема Kafka, а не от времени генерации события.
Хотелось бы заметить, что это и в реальном мире (физическом) так. Ибо теория относительности: события, одновременные в одной системе отсчета, всегда неодновременны в другой неравной ей (в том числе вплоть до смены их порядка на противоположный, и разница тем больше, чем больше разница в скорости этих СО друг относительно друга). Т.е. если есть СО, в которой “A затем B”, то найдется такая СО, в которой это будет “B затем A”, и это не «кажется», это реально так и есть: в мире нет универсальной одновременности/порядка событий, только если между ними успеет пинг проскочить и синхронизировать порядок при помощи информации.
Если звук грома приходит позже, чем свет от молнии, значит ли это, что звук рождается уже после того, как молния погасла, и это не «кажется», это реально так и есть?
По поводу СТО и порядка вы ошибаетесь. Одновременность и интервал связанных событий может не соблюдаются в различных системах отчёта, однако порядок остаётся всегда одинаковым. В противном случае, это приводит к парадоксам, где причина случается после следствия.
Подробные парадоксы возникают в системах доставки сообщений, где не соблюдается гарантия упорядоченности. В распределенных системах это основной и самый трудноотлаживаемый тип сбоев.
"идемпотентные производители" - это про КДПВ? Ж8-()
В любой распределенной системе порядок основанной на времени разных серверов это очень условная штука. Не надо на такое закладываться. Часы ведут себя иногда очень странно. Время может идти в обратную сторону.
Порядок гарантируется номером одной последовательности или чем-то таким. Кафка вам его и гарантирует. Все работает правильно.
Я чегото может не понимаю, но почему одиночный продюсер из примера отправляет все сообщения паралельно? Возможно автор поста опустил партиции на своих рисунках? Но тогда это какойто ввод взаблуждение.
Разве порядок сообщений не должен гарантироваться транспортным уровнем, протоколом tcp/ip?
Нет конечно. Разве вы видели в tcp/ip такие гарантии?
Ну, формально tcp гарантирует очередность пакетов в рамках одного соединения. Это, правда, к содержанию статьи мало относится.
Он гарантирует, что получатель может собрать пакеты в правильном порядке (они пронумерованы), но прийти к получателю они могут вразнобой.
Возвращаясь к теме статьи, если все сообщения пронумеровать, то Кафка в теории тоже смогла бы их собрать в порядке отправителя.
С точки зрения клиента гарантия все равно сохраняется - как байты были посланы, так они и придут. Поэтому на первой картинке с разными маршрутами пакетов нарисована полная глупость. Она работает только если до одного брокера открывается несколько соединений, что помоему клиенты кафки не делают
как байты были посланы, так они и придут
Нет. Придут ≠ соберутся. Протокол гарантирует именно сборку, а не доставку. Собственно, необходимость маркировки и сборки возникает из-за доставки вразнобой.
Она работает
… всегда, потому что сериализация происходит не позже чем на уровне phy: среда у вас одна и она или занята или нет. Никакой одновременной передачи, если речь не идет об агрегации линков, быть у вас не может, и даже с агрегацией должны хеши правильно лечь.
И ради чего все эти подробности? Замечательно, что мы тут с вами прекрасно разбираемся, как все работает внутри, только это не имеет ни малейшего отношения к сабжу.
Статья про кафку, которая работает на уровне абстракции TCP сокета. Приложению абсолютно плевать что и как там на физическом уровне, хоть там голубиной почтой пакеты идут через несколько континентов. На уровне приложения все так, как я написал - как байты были посланы, так они и придут. Все, на этом можно поставить точку. И именно поэтому первый кейс в статье лютый бред, который можно натянуть только на кейс с несколькими TCP сокетами. Опять же, клиенты по-моему так не делают. Они открывают один сокет до каждого брокера.
Приложению абсолютно плевать что и как там на физическом уровне
Именно. Оно читает стрим из буфера по готовности. И передает данные дальше.
А TCP помещает данные в буфер по мере их поступления, упорядочивая пришедшие вразнобой куски — но не более.
И если бы TCP дожидался следующего пакета в нумерации, чтобы гарантировать тот же порядок байт, как вы сказали, то первый же пропуск — любой клиент на ненадежном канале, например, на сотовом, или даже просто зашумленом — подвешивал бы веб-сервер наглухо. По всему миру.
Но этого не происходит.
Приложение забирает возможно битые или неполные данные, переданные во время сессии, данные, пришедшие несвоевременно — и само уже решает, что с ними делать.
И если в буфере сервера сперва собралось сообщение 3 а потом 2 — то в именно в таком порядке их заберет читающий поток.
И если пакеты-опозданцы будут отброшены и переотправлены, то ничего не изменится: сообщение 2 будет получено позже, чем 3.
Это называется протекающие абстракции.
И именно об том тот самый первый кейс, на нем это прямо нарисовано.
Возможно, к кафке это не имеет отношения. Может, клиент нумерует сообщения, а сервер доверяет этой нумерации — каджит не эксплуатировал, ручаться не будет.
Но к TCP это уже отношения не имеет.
вы вообще понятия не имеете как работает tcp или веб-сервера. tcp именно дожидается того, что все нужные пакеты придут и более того, если пришли 1 и 3, а 2 не пришел еще и попросит отправить 2 еще раз. Есть такой механизм - selective acknowledgements.
Веб сервер не замрет от этого, потому что существуют неблокирующие операции чтения из сокетов и многопоточность.
Далее про кафку: продюсер устанавливает с брокером две tcp сессии - одну для метаданных, одну для сообщений. И если продюсер не будет принудительно у себя в недрах закрывать объект кафки (KafkaProducer.Close в python, например) после каждой отправки сообщения, то все сообщения будут ходить в рамках одной tcp-сессии и как бы там пакеты по сети не ходили петлями, если таки tcp-достижимость сохраняется (tcp-сессия не разорвалась) - то с одного продюсера сообщения попадут в топик именно в том порядке, в каком их отправлял продюсер.
Прежде, чем упрекать в некомпетентности, стоило бы вспомнить, например, что просить никто никого не будет, а наоборот, клиент повторит отправку, если не получит квиток в пределах окна переупорядочивания.
А то смищно выходит.
Прояснить, ведет ли нумерацию клиент и доверяет ли ей сервер — у вас тоже не вышло.
Чего вы тогда пришли, огрызнуться?
И если бы TCP дожидался следующего пакета в нумерации, чтобы гарантировать тот же порядок байт, как вы сказали, то первый же пропуск — любой клиент на ненадежном канале, например, на сотовом, или даже просто зашумленом — подвешивал бы веб-сервер наглухо.
Вам бы почитать как TCP работает, механизм подтверждения там и все такое
Вот именно, что он работает сильно сложнее примитивных представлений. И под гарантированием — лежит обширное пространство условий,
Кроме квитирования существует еще и механизм сегментации (не пакетов), и в рамках последовательной посылки сообщений нужно рассматривать еще и его, так как нигде не было сказано, что сообщения маленькие и идут одним упакованным банчем, вследствие чего могут попасть в один сегмент TCP.
Этот не будет спорить, TCP он знает не досконально — ровно настолько, чтобы знать, что под гарантией подразумевается кучка условий и допущений.
стек tcp/ip гарантирует, что к ПРИЛОЖЕНИЮ-получателю данные придут в том же порядке, что и отправило ПРИЛОЖЕНИЕ-отправитель. пакеты-то по сети придут как им вздумается, но вот на уровне драйвера tcp они отлежатся, пока не соберутся как надо и уже на уровень приложения попадут как надо.
Прежде чем вы, супермегапрофессонал наш, наберете в рот воздуха очередного крика гарантирует, задумайтесь вот над чем: чтобы гарантировать доставку tcp/ip придется успешно передавать данные в отсутствие канала связи.
Что, очевидно, невозможно.
Так что же гарантирует tcp/ip на самом деле? Впрочем, вопрос риторический.
Должно и гарантируется. Если рассматривать кейс с одним соединением, на первой картинке нарисован полный бред. Неважно совершенно какими маршрутами полетят пакеты. Стэк их в любом случае соберет в том порядке, в котором они были посланы.
Сначала пару раз проскочило слово "топик", а потом всё время используется перевод "тема". И "раздел" туда же. Мне кажется, не стоит переводить эти слова, это вполне себе устоявшиеся и всеми понимаемые термины - топик и партиция.
Действительно ли Apache Kafka сохраняет правильный порядок сообщений?