Ну смотрите, я отталкиваюсь от указанной в статье задачи сервиса: "Его задача — агрегировать информацию непосредственно о товаре (название, описание, технические характеристики, габариты, картинки и т. п.), наложить на эту информацию определенную бизнес-логику и отдать её фронту". Понимаю, что изображения - это ссылочный тип, но учитывая 2 байта на символ Unicode там и без того за 4кб карточка переедет легко. А еще на фронт ее, небось, в JSON надо отдавать (overhead не XML, конечно, но тоже немаленький). В общем, предположение о размере у меня выше 4 кб.
Шардирование - один из вариантов решения проблемы, но в случае шардирования все данные хранятся в "горячем" хранилище с конской стоимостью и еще перед ними стоит индексный маршрутизатор, являющийся точкой отказа, который тоже надо масштабировать. Есть и у шардирования проблемы.
На самом деле команда автора реализовала CQRS и совместила с кэшированием. Попали на eventual consistency, как и в любой событийной модели и решили задачу. Я бы, правда, решал ее через хэширование объектов и сравнение хэшей, чтобы не перечитывать ровно все данные из холодного хранилища в background-потоке. Быстрее синхронизация будет. Но на суть алгоритма не виляет, это - нюансы имплементации.
Боюсь, что 4кб на карточку товара будет маловато. Тут либо пытаться запихать карточку в требуемый объем, либо таки делать масштабируемую систему. Ребята пошли по второму пути, теперь рост объемов бизнеса не потребует срочного рефакторинга. Нормальный подход.
Скорее всего, у вас недоступен координатор группы. Тут вопрос к качеству закрытия предыдущих консьюмеров и не висят ли какие-нибудь из них на точке останова? А так - параметр connection.max.idle.ms уменьшить до 2 минут, например, должно помочь.
Как показали тесты ActiveMQ Artemis не менее скорострелен, нежели кролик, зато вариаций на тему кластеризации и масштабирования у AMQ Artemis поболее будет) А для pub/sub лучше таки использовать класс систем, базирующийся на персистентном журнале , наиболее зрелой из которых является Apache Kafka.
Зависит от того паттерна, с которым используют MQ. Заменять очередь на персистентный лог стоит разве что при наличии более, чем одного потребителя из очереди сообщений. Иначе это превращается в лютый кэш транспортного уровня с большими накладными расходами (инфраструктура и управление) на его организацию.
Выжать максимум — это не совсем достичь "exactly once") При ребалансировке consumer group незакоммиченные оффсеты будут вычитаны другим назначенным потребителем группы. Это можно, в принципе, порешать кастомным ассайнором, но оно же убъет отказоустойчивость. Вся бОль распределенных систем в том, что не существует гарантированной одноразовой доставки и жесткой целостности данных. Kafka в данном случае не нарушает законов.
Могу в ответ только сообщить изустные предания от архитекторов Confluent, что stretched cluster при latency менее 7 млс между ДЦ является вполне себе решением. Просто под мультиДЦ обычно подразумевается широко географически распределённая топология, конда физика против такой latency.
Пруфов как таковых нет, но это наследуется от логики. В случае растянутого кластера переключения потребителей услуги не требуется, работаем с живыми бутстрапами. В случае же разрыва соединения между ДЦ при поставщиков в каждом из них мы получаем split-brain, т.е. в одном и том же топике разных кластеров разная информация лежит в одних и тех же оффсетах соответствующих партиций
А почему не использовали stretched-cluster с rack awareness? Если ДЦ географически близко, то это — самый простой и правильный способ обеспечить failover
Exactly once semantics на только основе транзакций Кафки сделать нельзя. Вернее, можно попробовать накостылить так, чтобы оффсеты хранились там же, где идет обработка и т.д., но это будет так себе решение. Транзакции в Кафке немного не для того сделаны.
Ну смотрите, я отталкиваюсь от указанной в статье задачи сервиса: "Его задача — агрегировать информацию непосредственно о товаре (название, описание, технические характеристики, габариты, картинки и т. п.), наложить на эту информацию определенную бизнес-логику и отдать её фронту". Понимаю, что изображения - это ссылочный тип, но учитывая 2 байта на символ Unicode там и без того за 4кб карточка переедет легко. А еще на фронт ее, небось, в JSON надо отдавать (overhead не XML, конечно, но тоже немаленький). В общем, предположение о размере у меня выше 4 кб.
Шардирование - один из вариантов решения проблемы, но в случае шардирования все данные хранятся в "горячем" хранилище с конской стоимостью и еще перед ними стоит индексный маршрутизатор, являющийся точкой отказа, который тоже надо масштабировать. Есть и у шардирования проблемы.
На самом деле команда автора реализовала CQRS и совместила с кэшированием. Попали на eventual consistency, как и в любой событийной модели и решили задачу. Я бы, правда, решал ее через хэширование объектов и сравнение хэшей, чтобы не перечитывать ровно все данные из холодного хранилища в background-потоке. Быстрее синхронизация будет. Но на суть алгоритма не виляет, это - нюансы имплементации.
Боюсь, что 4кб на карточку товара будет маловато. Тут либо пытаться запихать карточку в требуемый объем, либо таки делать масштабируемую систему. Ребята пошли по второму пути, теперь рост объемов бизнеса не потребует срочного рефакторинга. Нормальный подход.
Ошибка в примере кода: вроде говорим за ошибку продьюсера, а код приведен для консьюмера, да и тот кривоват.
Скорее всего, у вас недоступен координатор группы. Тут вопрос к качеству закрытия предыдущих консьюмеров и не висят ли какие-нибудь из них на точке останова? А так - параметр connection.max.idle.ms уменьшить до 2 минут, например, должно помочь.
Для этого проще написать оператор, который читает метаданные кластера и, при необходимости, скейлит кастомные ресурсы.
Как показали тесты ActiveMQ Artemis не менее скорострелен, нежели кролик, зато вариаций на тему кластеризации и масштабирования у AMQ Artemis поболее будет) А для pub/sub лучше таки использовать класс систем, базирующийся на персистентном журнале , наиболее зрелой из которых является Apache Kafka.
А чем кролик лучше того же ActiveMQ? Тоже open-source MQ брокер.
Зависит от того паттерна, с которым используют MQ. Заменять очередь на персистентный лог стоит разве что при наличии более, чем одного потребителя из очереди сообщений. Иначе это превращается в лютый кэш транспортного уровня с большими накладными расходами (инфраструктура и управление) на его организацию.
Выжать максимум — это не совсем достичь "exactly once") При ребалансировке consumer group незакоммиченные оффсеты будут вычитаны другим назначенным потребителем группы. Это можно, в принципе, порешать кастомным ассайнором, но оно же убъет отказоустойчивость. Вся бОль распределенных систем в том, что не существует гарантированной одноразовой доставки и жесткой целостности данных. Kafka в данном случае не нарушает законов.
Могу в ответ только сообщить изустные предания от архитекторов Confluent, что stretched cluster при latency менее 7 млс между ДЦ является вполне себе решением. Просто под мультиДЦ обычно подразумевается широко географически распределённая топология, конда физика против такой latency.
"Почти всегда будет оставаться одна последняя запись" имеется в виду? Компэкшн Кафки — такой компэкшн...
Пруфов как таковых нет, но это наследуется от логики. В случае растянутого кластера переключения потребителей услуги не требуется, работаем с живыми бутстрапами. В случае же разрыва соединения между ДЦ при поставщиков в каждом из них мы получаем split-brain, т.е. в одном и том же топике разных кластеров разная информация лежит в одних и тех же оффсетах соответствующих партиций
А почему не использовали stretched-cluster с rack awareness? Если ДЦ географически близко, то это — самый простой и правильный способ обеспечить failover
Exactly once semantics на только основе транзакций Кафки сделать нельзя. Вернее, можно попробовать накостылить так, чтобы оффсеты хранились там же, где идет обработка и т.д., но это будет так себе решение. Транзакции в Кафке немного не для того сделаны.