При остановке и поднятии listener container происходит остановка и поднятие consumer-a, а это приведет к ребалансировке. Хотя, при временной недоступности внешней системы скорее всего будут остановлены все consumer-ы в затронутой consumer group.
Время обработки сообщения отличается от сервиса к сервису. На одном из наших контуров для приложений, которые ходят в несколько внешних источников за данными, оно не превышает 50 мс. Как я и писал, spring-retry мы не стали серьезно рассматривать. Он хранит сообщения в памяти, блокирует поток исполнения для выполнения стратегии и с ним у нас по прежнему отсутсвует DLQ. Кроме того, действительно, есть вероятность превысить max.poll.interval.ms интервал, что приведет к нежелательной ребалансировке consumer group.
Я затрудняюсь ответить на этот вопрос. Мои наблюдения показывают, что количество партиций должно соответствовать количеству consumer-ов для эффективной утилизации. Если consumer-ов будет больше, чем партиций, то они будут простаивать. Если партиций будет больше, то какой-либо consumer подключится и будет читать из нескольких партиций сразу, что может негативно отразиться на производительности.
Да, конечно. Сразу хочу отметить, что в тексте статьи я сначала описал общий случай с записью в DLQ, а затем частный с применением стратегии повторных вызовов.
Если мы могли понять, что ошибка имеет временный характер, то мы начинали применять стратегию повторных вызовов. В этом случае сообщение попадало в DLQ только если наступил конец стратегии, не раньше.
Во всех остальных случаях сообщение сразу попадало в DLQ.
Спасибо за интересные вопросы! Попробую ответить на них по порядку.
Но ведь это exactly once запись в кафку, как вы гарантируете exactly once чтение? В статье в целом мало информации о консьюмере, почему в нем нельзя было обеспечить exactly once по тому же ключу?
Мы пытались выжать максимум из средств, которые предоставляет сама Кафка, поэтому на Consumer в первую очередь настраиваем isolation.level = read_committed. Этого достаточно для внутренней коммуникации внутри нашей системы.
Если я правильно понял часть вопроса с ключем, то такое поведение можно получить используя какой-либо внешний источник для хранения данных, с которым будет работать сервис, читающий из Кафки. Этот сервис будет считывать сообщение из топика, проверять наличие полученного ключа во внешнем источнике данных и обрабатывать сообщение, если полученный ключ уникальный. Хотя, это будет больше похоже на идемпотентную обработку данных. В нашей системе мы используем похожий механизм на граничных сервисах, так как не можем управлять Producer-ами сторонних систем.
Также в случае acks = -1 кластер становится фактически недоступен при выхода из строя одной из нод, как вы с этим боретесь?
Наша команда не занимается управлением кластера Кафки, но я попробую ответить на Ваш вопрос. Сочетание количества брокеров, фактора репликации и значения параметра min.insync.replicas нашего кластера позволяют нам пережить до 3х падений узлов. Вы можете подробнее разобраться в том, как кластер переживает падение узлов прочитав отличную статью от коллег. Кроме того, у нас настроен мониторинг статусов партиций и ответственные за кластер люди смогут во время вмешаться.
Если Вы имеете ввиду другое значение для параметра retries, то да, его можно задать. Но, как и отмечено в статье, можно регулировать количество повторных отправок значением параметра delivery.timeout.ms. В некоторых случаях это будет удобнее за счет того, что Producer сделает максимальное число повторных отправок за указанный интервал времени и Вам не нужно будет подбирать значение для retries самостоятельно.
Нет, мы продолжаем работать с Кафкой. В заголовке хотелось обыграть схожесть слов бЫль и бОль, так как наш путь к гарантированной доставке был непростым.
Здравствуйте.
Нам очень приятно, что тема T-SDN интересна. Это подталкивает нас рассказать о сетях и контроллерах больше и детальней. Ниже позвольте нам ответить на Ваши вопросы по порядку.
Запросы сервисов «bandwidth on demand» осуществляется со стороны Сервисного Оркестратора (Service Orchestrator), который архитектурно относится к уровню приложений для Контроллера.
Контроллер на основании данных, получаемых от нижележащей инфраструктуры, может создавать многоуровневые виртуальные топологии, которые включают все уровни существующих транспортных сетей:
1) L0 (WDM ROADM),
2) L1 (OTN),
3) L2/L3+ (IP/MPLS).
Более детально об этом мы хотели бы рассказать в следующих статьях, равно как и о следующем вопросе.
Вся работа контроллера должна быть максимально приближена к «реальному времени». Существует понятие Active Real-Time.
В первую очередь время вычисления пути определяется размером топологии, формируемой на основании сети. Однако существенный вес имеет технологическая специфика (например, для DWDM). Опираясь на опыт, полученный нашей командой в результате внедрения, можно сказать, что расчет пути на одном сегменте сети провайдера (управляемом контроллером нижнего уровня) занимает менее чем 50 мс. Время, затрачиваемое контроллером верхнего уровня на расчет пути, может значительно отличаться. Это обусловлено тем, что он агрегирует внутри себя разные сетевые домены. Так, например, расчет пути при нагрузочном тестировании на топологии, состоящей из 10 000 элементов, занял порядка 2 секунд.
В рамках предложенной системы кластеризация может стать одним из способов ускорения прокладки пути, а также оптимизации нагрузки на контроллеры нижнего уровня.
Очень важно также отметить, что время, затрачиваемое контроллером на расчет пути, пренебрежимо мало по сравнению со временем, которое может потребоваться для прокладки или перепрокладки этого пути на уровне оптического оборудования.
Изначально контроллер верхнего уровня отвечает за обеспечение оптимальной прокладки сервиса согласно критериям, полученным со стороны Сервисного Окрестратора (Service Orchestrator). Оптимизация трафика осуществляется как на контроллерах верхнего, так и контроллерах нижнего уровней. Этот процесс затрагивает не только основные маршруты (Main), но и резервные (Protection).
Контроллеры могут осуществлять мониторинг параметров сети (таких как пропускная способность, балансировка трафика и загруженность развернутых VNF) как самостоятельно, так и посредством сторонних систем.
Хочу поделиться другой ошибкой, с которой я столкнулся на своем Macbook Air 2011 года.
Однажды обратил внимание на то, что количество свободного места в ОС не изменяется независимо от того удаляю я что-либо или устанавливаю. При этом, после удаления программ\файлов дисковая утилита всегда находила ошибки в файловой системе, которые предлагала исправить после перезагрузки в режиме восстановления.
Решение искал долго и оно оказалось довольно неожиданным — необходимо было отключить Time Machine. Хочу отметить, что бэкапы я делал регулярно, но восстанавливать Macbook из них ни разу не приходилось.
Спасибо за вопросы. Отвечу на них по порядку
Если мы могли понять, что ошибка имеет временный характер, то мы начинали применять стратегию повторных вызовов. В этом случае сообщение попадало в DLQ только если наступил конец стратегии, не раньше.
Во всех остальных случаях сообщение сразу попадало в DLQ.
Мы пытались выжать максимум из средств, которые предоставляет сама Кафка, поэтому на Consumer в первую очередь настраиваем isolation.level = read_committed. Этого достаточно для внутренней коммуникации внутри нашей системы.
Если я правильно понял часть вопроса с ключем, то такое поведение можно получить используя какой-либо внешний источник для хранения данных, с которым будет работать сервис, читающий из Кафки. Этот сервис будет считывать сообщение из топика, проверять наличие полученного ключа во внешнем источнике данных и обрабатывать сообщение, если полученный ключ уникальный. Хотя, это будет больше похоже на идемпотентную обработку данных. В нашей системе мы используем похожий механизм на граничных сервисах, так как не можем управлять Producer-ами сторонних систем.
Наша команда не занимается управлением кластера Кафки, но я попробую ответить на Ваш вопрос. Сочетание количества брокеров, фактора репликации и значения параметра min.insync.replicas нашего кластера позволяют нам пережить до 3х падений узлов. Вы можете подробнее разобраться в том, как кластер переживает падение узлов прочитав отличную статью от коллег. Кроме того, у нас настроен мониторинг статусов партиций и ответственные за кластер люди смогут во время вмешаться.
Нам очень приятно, что тема T-SDN интересна. Это подталкивает нас рассказать о сетях и контроллерах больше и детальней. Ниже позвольте нам ответить на Ваши вопросы по порядку.
Запросы сервисов «bandwidth on demand» осуществляется со стороны Сервисного Оркестратора (Service Orchestrator), который архитектурно относится к уровню приложений для Контроллера.
Контроллер на основании данных, получаемых от нижележащей инфраструктуры, может создавать многоуровневые виртуальные топологии, которые включают все уровни существующих транспортных сетей:
1) L0 (WDM ROADM),
2) L1 (OTN),
3) L2/L3+ (IP/MPLS).
Более детально об этом мы хотели бы рассказать в следующих статьях, равно как и о следующем вопросе.
Вся работа контроллера должна быть максимально приближена к «реальному времени». Существует понятие Active Real-Time.
В первую очередь время вычисления пути определяется размером топологии, формируемой на основании сети. Однако существенный вес имеет технологическая специфика (например, для DWDM). Опираясь на опыт, полученный нашей командой в результате внедрения, можно сказать, что расчет пути на одном сегменте сети провайдера (управляемом контроллером нижнего уровня) занимает менее чем 50 мс. Время, затрачиваемое контроллером верхнего уровня на расчет пути, может значительно отличаться. Это обусловлено тем, что он агрегирует внутри себя разные сетевые домены. Так, например, расчет пути при нагрузочном тестировании на топологии, состоящей из 10 000 элементов, занял порядка 2 секунд.
В рамках предложенной системы кластеризация может стать одним из способов ускорения прокладки пути, а также оптимизации нагрузки на контроллеры нижнего уровня.
Очень важно также отметить, что время, затрачиваемое контроллером на расчет пути, пренебрежимо мало по сравнению со временем, которое может потребоваться для прокладки или перепрокладки этого пути на уровне оптического оборудования.
Изначально контроллер верхнего уровня отвечает за обеспечение оптимальной прокладки сервиса согласно критериям, полученным со стороны Сервисного Окрестратора (Service Orchestrator). Оптимизация трафика осуществляется как на контроллерах верхнего, так и контроллерах нижнего уровней. Этот процесс затрагивает не только основные маршруты (Main), но и резервные (Protection).
Контроллеры могут осуществлять мониторинг параметров сети (таких как пропускная способность, балансировка трафика и загруженность развернутых VNF) как самостоятельно, так и посредством сторонних систем.
Однажды обратил внимание на то, что количество свободного места в ОС не изменяется независимо от того удаляю я что-либо или устанавливаю. При этом, после удаления программ\файлов дисковая утилита всегда находила ошибки в файловой системе, которые предлагала исправить после перезагрузки в режиме восстановления.
Решение искал долго и оно оказалось довольно неожиданным — необходимо было отключить Time Machine. Хочу отметить, что бэкапы я делал регулярно, но восстанавливать Macbook из них ни разу не приходилось.