Я ни в чем не запуталась, я работаю datastreaming инженером больше 10 лет. Вы пишите, что "ключ используется для сегментации сообщений внутри партиции". Это в принципе неверно. Партицию, в которую отправить сообщение, определяет продюсер, и по умолчанию она определяется так: murmur2hash(key)%partition_count. То есть берется хэш от ключа, делится на число партиций в топике и остаток - это номер партиции. Это единственный смысл ключа.
Например, при отправке сообщений с данными клиента в топик, имеет смысл использовать идентификатор клиента в качестве ключа. Это обеспечит попадание всех сообщений, связанных с конкретным клиентом, в одну и ту же партицию, сохраняя их в правильном порядке.
Остальное, кому надо в документации проверит, но с ключами - это фундаментальная вещь.
Метрики Кафки выставляются через JMX, поэтому используйте стек для мониторинга, с которым вы умеете работать. Prometheus-Grafana, ELK, zabbix, что угодно. У Confluent хороший репозиторий https://github.com/confluentinc/jmx-monitoring-stacks, я его использую с минимальными изменениями.
Можете использовать статическую принадлежность к группе (static group membership), дать консьюмеру group.instance.id, тогда если перезапуск будет короткий (меньше установленного таймаута), то консьюмер получит свои партиции назад.
Нет, в Apache Kafka никакого автомасштабирования партиций нет. Количество партиций можно увеличить, запустив скрипт со специальными параметрами. При этом данные, которые в Кафке уже есть, останутся в старых партициях, и в новой конфигурации распределение по ключам будет уже другое. Уменьшить количество партиций в принципе нельзя (только пересоздать топик).
Честно говоря, у вас здесь столько неточностей, что пройдусь только по крупным.
Kafka Connect API - это не программный интерфейс к Кафке, и никакого отношения к языкам программирования он не имеет. Kafka Connect - позволяет лить данные из внешних систем в Кафку, или из Кафки во внешние системы(базы данных, эластик, даталейк) без программирования, только плагин к системе и конфигурация.
Партиции - это вовсе не подмножества топиков. Топик делится на партиции, партиция - это единица репликации и избыточности(redundancy).
Емкий небольшой формат - это не json, а Avro или protobuf.
Ключ не используется для сегментации сообщений внутри партиции. По умолчанию сообщения с одинаковым ключом попадают в одну и ту же партицию (но все можно поменять). Смысл в том, что в партиции гарантируется очередность сообщения, и если очередность важна, то сообщения должны иметь одинаковый ключ.
Если хочется указать консьюмеру, как десериализовать сообщения, надо использовать не ключ, а headers.
Сообщение не будет удалено из переполненного топика. Сообщения удаляются по времени (старше, чем Х дней) или, (если сконфигурировано), когда размер топика будет больше, чем заданный размер. Если у вас просто кончится место на диске, то Кафка упадет.
min.insync.replicas нельзя ставить больше, чем количество реплик, это в принципе невозможно. Обычно это количество реплик - 1.
Кафка никогда не удаляет отдельные сообщения, а только целые сегменты.
max.poll.interval.ms проверяется на клиенте. Не Кафка считает клиента неработоспособным, а он сам себя считает неработоспособным и посылает leave request.
Вообще-то, delivery.timeout.ms по умолчанию 2 минуты. Ничего себе, проблемы с сетью. Какой-то странный outbox, тогда уже проще писать сразу записи в базу и тащить их оттуда кафка-коннектом.
В Кафке есть индекс по timestamp, поэтому можно быстро спозиционировать консумента на самую первую запись с заданным временем. А для того, чтобы примерно посчитать количество данных, можно использовать разницу оффсетов(инструмент GetOffsetShell)
Стратегия по умолчанию не в том, чтобы разделы всегда распределялись между потребителями равномерно, а в том, чтобы разделы с одинаковыми номерами (из разных топиков) были назначены одному и тому же потребителю.
Проблема повторного использования вообще не касается ООП. В функциональном программировании при использовании чужого кода тоже надо знать, как он работает. И да, в следующей версии он может поменяться и все сломать.
Да, я имела в виду идентификационную карту, я не знала, как она называется правильно. Дайте пруф, что вы с видом на жительство можете ездить. А то вот у меня EU permanent residence, гражданство российское, а английское консульство утверждает, что мне нужна виза.
Почитала, ошиблась. Правда открытая граница тут все равно не при чем. То, о чем написано в статье, имеет отношение не к границе, а к единому европейскому рынку труда (Single labour market). Вполне возможно, что Британия там останется, так же как и, например, Норвегия, которая членом ЕС не является.
Мне интересно, а где во всех этих микросервисах находится контроль доступа к данным? Например, какие посты может пользователь видеть, а какие редактировать. Каждый сервис это по своему решает? Или у вас есть сервис, который права раздает/проверяет, а все остальные от него зависят?
Я вам отвечу, живу в Праге с 2002 года. Обязательная медицинская страховка платится как налог, размер выплат регулировать нельзя, от дохода зависит. Лечение зубов не входит, удаление и осмотр — бесплатно.
В конце февраля у меня рука начала болеть, так пришлось идти с этим сначала к терапевту, получила направление и записалась на конец апреля на консультацию к невропатологу. На консультации невропатолог решил, что нужно обследование и записал на начало июня. Вот ждем-с. Вобщем, лучше не болеть. Но бесплатно, это да. Правда, когда на скорой приезжаешь, все наверное быстро происходит..
Я ни в чем не запуталась, я работаю datastreaming инженером больше 10 лет. Вы пишите, что "ключ используется для сегментации сообщений внутри партиции". Это в принципе неверно. Партицию, в которую отправить сообщение, определяет продюсер, и по умолчанию она определяется так: murmur2hash(key)%partition_count. То есть берется хэш от ключа, делится на число партиций в топике и остаток - это номер партиции. Это единственный смысл ключа.
Например, при отправке сообщений с данными клиента в топик, имеет смысл использовать идентификатор клиента в качестве ключа. Это обеспечит попадание всех сообщений, связанных с конкретным клиентом, в одну и ту же партицию, сохраняя их в правильном порядке.
Остальное, кому надо в документации проверит, но с ключами - это фундаментальная вещь.
Метрики Кафки выставляются через JMX, поэтому используйте стек для мониторинга, с которым вы умеете работать. Prometheus-Grafana, ELK, zabbix, что угодно. У Confluent хороший репозиторий https://github.com/confluentinc/jmx-monitoring-stacks, я его использую с минимальными изменениями.
Можете использовать статическую принадлежность к группе (static group membership), дать консьюмеру group.instance.id, тогда если перезапуск будет короткий (меньше установленного таймаута), то консьюмер получит свои партиции назад.
Нет, в Apache Kafka никакого автомасштабирования партиций нет. Количество партиций можно увеличить, запустив скрипт со специальными параметрами. При этом данные, которые в Кафке уже есть, останутся в старых партициях, и в новой конфигурации распределение по ключам будет уже другое. Уменьшить количество партиций в принципе нельзя (только пересоздать топик).
Честно говоря, у вас здесь столько неточностей, что пройдусь только по крупным.
Kafka Connect API - это не программный интерфейс к Кафке, и никакого отношения к языкам программирования он не имеет. Kafka Connect - позволяет лить данные из внешних систем в Кафку, или из Кафки во внешние системы(базы данных, эластик, даталейк) без программирования, только плагин к системе и конфигурация.
Партиции - это вовсе не подмножества топиков. Топик делится на партиции, партиция - это единица репликации и избыточности(redundancy).
Емкий небольшой формат - это не json, а Avro или protobuf.
Ключ не используется для сегментации сообщений внутри партиции. По умолчанию сообщения с одинаковым ключом попадают в одну и ту же партицию (но все можно поменять). Смысл в том, что в партиции гарантируется очередность сообщения, и если очередность важна, то сообщения должны иметь одинаковый ключ.
Если хочется указать консьюмеру, как десериализовать сообщения, надо использовать не ключ, а headers.
Сообщение не будет удалено из переполненного топика. Сообщения удаляются по времени (старше, чем Х дней) или, (если сконфигурировано), когда размер топика будет больше, чем заданный размер. Если у вас просто кончится место на диске, то Кафка упадет.
min.insync.replicas нельзя ставить больше, чем количество реплик, это в принципе невозможно. Обычно это количество реплик - 1.
Кафка никогда не удаляет отдельные сообщения, а только целые сегменты.
max.poll.interval.ms проверяется на клиенте. Не Кафка считает клиента неработоспособным, а он сам себя считает неработоспособным и посылает leave request.
Вообще-то, delivery.timeout.ms по умолчанию 2 минуты. Ничего себе, проблемы с сетью. Какой-то странный outbox, тогда уже проще писать сразу записи в базу и тащить их оттуда кафка-коннектом.
А вам не наплевать на этот социум? Если, что я тоже женщина, двое детей (сын и дочь, больше не хочу), всегда была няня.
В Кафке есть индекс по timestamp, поэтому можно быстро спозиционировать консумента на самую первую запись с заданным временем. А для того, чтобы примерно посчитать количество данных, можно использовать разницу оффсетов(инструмент GetOffsetShell)
Стратегия по умолчанию не в том, чтобы разделы всегда распределялись между потребителями равномерно, а в том, чтобы разделы с одинаковыми номерами (из разных топиков) были назначены одному и тому же потребителю.
В конце февраля у меня рука начала болеть, так пришлось идти с этим сначала к терапевту, получила направление и записалась на конец апреля на консультацию к невропатологу. На консультации невропатолог решил, что нужно обследование и записал на начало июня. Вот ждем-с. Вобщем, лучше не болеть. Но бесплатно, это да. Правда, когда на скорой приезжаешь, все наверное быстро происходит..