Скорее всего, у вас недоступен координатор группы. Тут вопрос к качеству закрытия предыдущих консьюмеров и не висят ли какие-нибудь из них на точке останова? А так - параметр 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 на только основе транзакций Кафки сделать нельзя. Вернее, можно попробовать накостылить так, чтобы оффсеты хранились там же, где идет обработка и т.д., но это будет так себе решение. Транзакции в Кафке немного не для того сделаны.
Скорее всего, у вас недоступен координатор группы. Тут вопрос к качеству закрытия предыдущих консьюмеров и не висят ли какие-нибудь из них на точке останова? А так - параметр 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 на только основе транзакций Кафки сделать нельзя. Вернее, можно попробовать накостылить так, чтобы оффсеты хранились там же, где идет обработка и т.д., но это будет так себе решение. Транзакции в Кафке немного не для того сделаны.