Метрики мы отдаем сами из quasar и шины данных. Для беклога мы делаем следующее
смотрим положения курсоров и оффсетов по партициям и получаем базовый беклог как partition end - cursor offset
распаковываем оффсеты, вычитаем индивидуально акнутые события.
итоговый рассчет оказывается приблизительным, но близким
И уже это пишется в метрику для пользователей
По нагрузке - сейчас около 40-50 млн rpm проходит.
В сторону ydb смотрели, но не хочется снова идти в не самую стандартную технологию. Пока предпочитаем api, которое если что можно подменить любой реализацией.
Гарантии у нас at least once, порядок и транзакционность доставки событий не гарантируем
Сам образ просто содержит признак, что он собран под другую архитектуру.
Важно не это, а то, что исполняемый файл запускается внутри. В Linux ядре есть специальный механизм - binfmt, который при запуске исполняемого файла умеет проверять его сигнатуру (первые несколько байт) и по ним определять, под какую архитектуру скомпилирован файл и запускать нужный для нее враппер. А если бы точным, то определяет не архитектуру, а просто в какой враппер нужно обернуть запуск файла с такой сигнатурой.
И дальше запускается qemu нужного вида и транслирует инструкции amd64 под arm
Ну кстати это хороший вопрос, я не имею отношения к статье и ее кейсу, но со своей стороны я бы сказал, что джетстрим по моему опыту показал себя гораздо медленнее и менее надёжным, чем кафка
Под капотом на данный момент у нас Kafka, а для внутрисервисных очередей - Apache Pulsar. Вокруг них своя обёртка на go для сокрытия топологии кластеров и валидации контрактов
Спасибо за комментарий. Да, все верно, чаще всего порядок событий реализуется на стороне клиентов, но есть варианты когда брокер предоставляет механики для соблюдения порядка, такие как шардирование по ключу для помещения событий одной сущности в одну партицию, эксклюзивный консьюминг, когда только один консьюмер читает соответствующий топик и т.п.
Статья дает общий обзор существующих гарантий и какие причины могут приводить к их нарушениям или сложности в поддержании.
Нет, пока не думаем менять, потому что основное время тратится на взаимодействие с самой кафкой, а в ней в свою очередь - на дисковые и процессорные операции.
Использование grpc даст (но не для всех клиентов) экономию процессорного времени и немного сети, что однако не является для нас узким местом.
Основной профит в том, что скрыта технология под капотом. Сегодня кафка, завтра может быть редпанда, послезавтра - федерация кластеров. А для клиентов точки входа и апи не меняются
Дело в том, что проблема не в ресурсах, Кафка нормально масштабируется горизонтально. Дело в надёжности и времени восстановления.
Схема с несколькими кафками на запись (под каждый из дц) выбрана исходя из требования гарантировать доступность записи. У такого решения минус тоже есть, в виде сложности системы, например. Поэтому сейчас мы движемся к другой схеме, где будут отдельные независимые кластера меньшего размера
Нет, ведь это очередь и основная задача - масштабирование чтения.
Гарантий порядка мы не даём даже в обычной шине данных
Привет!
Метрики мы отдаем сами из quasar и шины данных. Для беклога мы делаем следующее
смотрим положения курсоров и оффсетов по партициям и получаем базовый беклог как
partition end - cursor offsetраспаковываем оффсеты, вычитаем индивидуально акнутые события.
итоговый рассчет оказывается приблизительным, но близким
И уже это пишется в метрику для пользователей
По нагрузке - сейчас около 40-50 млн rpm проходит.
В сторону ydb смотрели, но не хочется снова идти в не самую стандартную технологию. Пока предпочитаем api, которое если что можно подменить любой реализацией.
Гарантии у нас at least once, порядок и транзакционность доставки событий не гарантируем
+= есть через
Поправьте всё-таки написание ide к единому виду
IntelliJ IDEA
Бесплатность, возможность запуска виртуалки для общих целей и задач
Ещё рекомендую рассмотреть OrbStack: быстрее Docker Desktop на порядок
Сам образ просто содержит признак, что он собран под другую архитектуру.
Важно не это, а то, что исполняемый файл запускается внутри. В Linux ядре есть специальный механизм - binfmt, который при запуске исполняемого файла умеет проверять его сигнатуру (первые несколько байт) и по ним определять, под какую архитектуру скомпилирован файл и запускать нужный для нее враппер. А если бы точным, то определяет не архитектуру, а просто в какой враппер нужно обернуть запуск файла с такой сигнатурой.
И дальше запускается qemu нужного вида и транслирует инструкции amd64 под arm
Все верно :) Но часто это лучше, чем торможение образов ненативных
Ну кстати это хороший вопрос, я не имею отношения к статье и ее кейсу, но со своей стороны я бы сказал, что джетстрим по моему опыту показал себя гораздо медленнее и менее надёжным, чем кафка
Nats из коробки как минимум не персистентный (не берём в рассмотрение Jetstream)
Да, но это выполняется только при условиях одной очереди, одного эксчейнджа, одного консьюмера и так далее.
Ничего особого, собственно
Под капотом на данный момент у нас Kafka, а для внутрисервисных очередей - Apache Pulsar. Вокруг них своя обёртка на go для сокрытия топологии кластеров и валидации контрактов
Спасибо за комментарий. Да, все верно, чаще всего порядок событий реализуется на стороне клиентов, но есть варианты когда брокер предоставляет механики для соблюдения порядка, такие как шардирование по ключу для помещения событий одной сущности в одну партицию, эксклюзивный консьюминг, когда только один консьюмер читает соответствующий топик и т.п.
Статья дает общий обзор существующих гарантий и какие причины могут приводить к их нарушениям или сложности в поддержании.
Да, похожая, хотя нагрузка меньше.
Нет, пока не думаем менять, потому что основное время тратится на взаимодействие с самой кафкой, а в ней в свою очередь - на дисковые и процессорные операции.
Использование grpc даст (но не для всех клиентов) экономию процессорного времени и немного сети, что однако не является для нас узким местом.
Нагрузка немаленькая.
А сколько реплик топиков используется и в каком режиме происходит продьюсинг (acks=0, acks=1, acks=all)?
Основной профит в том, что скрыта технология под капотом. Сегодня кафка, завтра может быть редпанда, послезавтра - федерация кластеров. А для клиентов точки входа и апи не меняются
Весьма интересная статья, спасибо!
Через OpenPolicy, все верно
Спасибо за вопрос. Мы в настоящий момент используем uReplicator, но в планах отказаться от него в пользу меньших кластеров
Спасибо!
Мы даём пользователям at least once, достигаем за счет механики ack на продьюсере и на консьюмере
Дело в том, что проблема не в ресурсах, Кафка нормально масштабируется горизонтально. Дело в надёжности и времени восстановления.
Схема с несколькими кафками на запись (под каждый из дц) выбрана исходя из требования гарантировать доступность записи. У такого решения минус тоже есть, в виде сложности системы, например. Поэтому сейчас мы движемся к другой схеме, где будут отдельные независимые кластера меньшего размера