Насчет количества потоков async не могу сказать - вообще не проверял, что там и как. Была задача написать какой-то health check для консьюмеров, но вот причины зависания очень сложно было понять, локально не воспроизвести.
Зависание выглядит так, будто консьюмер перестал обрабатывать сообщения - мы об этом узнаем, когда, например, кто-то кликнул на кнопку в одном сервисе, а в нашем сервисе ничего не появляется. Более глубоких причин не удалось выяснить, разве что кроме зависаний коннекшена к кафке, но это для продьюсера.
session_timeout/heartbeat_interval_ms - вроде стояли дефолтные, тоже не могу точно сказать.
Предполагаю, что дело все-таки в кластере кафки, у нас кластер кафки достаточно нагружен в совокупости. Сами топики по отдельности - нет. А так интересно, конечно, что у вас все хорошо работает, а тут нет.
Да, тут тоже вариант, как раз другие разработчики такую схему делали с отдельной очередью.
Здесь только есть проблема -- если основная таска обработки сообщений внутри застряла, а периодичесая, которая пишет пинг, нет. Допустим, сообщение(не ping) обрабатывается реально долго, то asyncio таска будет писать ping дальше. Тут какой-то такой же механизм нужно прикрутить, чтобы понимать, прогресс обработки основного сообщения
зависание происходит не вашего кода, а где-то далее в подключении к Kafka.
Да, все так, судя по тому, что откопали - местами висело подключение к кафке, после перезапуска все ок. В добавок там могло висеть подключение к БД по какой-то причине. А еще aiokafka имел проблему с зависаниями.
> запускать consumer в отдельном приложении fastapi Тоже была мысль какой-то эндпоинт прикрутить. У нас, кажется, такое делала другая команда. Сам не использовал, так-как параллельно пришлось прикручивать свое решение.
Я пробовал реализовывать свою логику через SIGUSR1
Было предположение, что завис процесс консьюмера и проблема именно в процессе. После посылки сигнала писалось нечто в файл. Если файл появлялся, то все ок. Если нет - не ок. В итоге консьюмер зависал не только по этой причине, но и по другим, а livenessProbe думал, что все в порядке
Есть задача двух генералов и есть задача византийских генералов. Они немного отличаются. Первая скорее про ненадежность связи. Вторая скорее про консенсус, насколько я понимаю
Вы немного перемешали все понятия в одну кучу, как мне кажется.
Возможно. Но это, пожалуй, именно что размышления, основанные на разных источниках. Хотелось создать некий мысленный фреймворк, чтобы было удобно мыслить понятиями. Может быть, это получилось и не очень.
В заголовке есть слово "брокер", но где в вашей схеме сам брокер? Server явно выглядит как приложение с логикой, потому что выполняет умную логику по обработке сообщений.
Все верно, сам брокер не упоминается. Это первая часть, которая должна "подвести" читателя и дать легкий фреймворк для мышления в терминах гарантий доставки, чтобы было понятно, что имеется в виду по аналогии простого веб приложения. Брокер считай тот же самый сервер. Задумка была как-то это рассказать в серии статей.
Само понятие - Exactly-one delivery часто применяется к сообщениям, можно ли назвать сетевой вызов сообщением? я бы не сказал.
А почему нет? Сетевой вызов под капотом это отправка того же самого сообщения
При отправке сообщения у нас обычно есть паттерн - Publisher - Subscriber и промежуточный брокер - который получает и отдаёт сообщение. И тут то и начинается 3 типа гарантии как мне кажется с каждой стороны.
Да-да, все верно. Была задумка во второй статье рассказать про гарантии доставки со стороны продьюсера и про transactional outbox. В третьей статье рассказать про гарантии обработки со стороны консьюминга(показать, что меняя место commit/ack меняется и гарантия обработки).
Рассмотренный способ с Idempotancy в статье называется Application level exactly once. Но он так же может быть и на уровне Broker и на уровне Application Framework. Например - 'Умный' consumer может посылать последний считанный номер сообщения в последовательности брокеру и брать сообщение, которое ещё не успел обработать. Это не совсем Idempotancy, механизм по-другому работает.
Keynote. На ощупь подобрал себе цветовую схему и получился такой вид. Анимации там же. Для некоторых изображений еще использовал https://excalidraw.com/
1. Невыносимая жара. Ты просто выходишь из дома в середине мая в 30+ и хочешь умереть.
2. Еда дешевая? Нет, не совсем. Возможно, только во всяких ресторанах и пивных в сравнении с Москвой. В таких заведениях какой-нибудь бургер будет стоить не 700 руб минимум по сравнению с Московскими ценами, а 350, например, но самих заведений тут не так много. Продукты в условном магните такие же по цене +-. Мак/КФС/Бургер кинг — цены везде одинаковые
3. Дешевое жилье. Да, здесь действительно можно купить в муравейнике дешевое жилье, но фиг знает, инфраструктуры никакой.
4. Особо негде гулять, кроме тройки мест, которые можно посетить за пару дней.
Насчет количества потоков async не могу сказать - вообще не проверял, что там и как. Была задача написать какой-то health check для консьюмеров, но вот причины зависания очень сложно было понять, локально не воспроизвести.
Зависание выглядит так, будто консьюмер перестал обрабатывать сообщения - мы об этом узнаем, когда, например, кто-то кликнул на кнопку в одном сервисе, а в нашем сервисе ничего не появляется. Более глубоких причин не удалось выяснить, разве что кроме зависаний коннекшена к кафке, но это для продьюсера.
session_timeout/heartbeat_interval_ms - вроде стояли дефолтные, тоже не могу точно сказать.
Предполагаю, что дело все-таки в кластере кафки, у нас кластер кафки достаточно нагружен в совокупости. Сами топики по отдельности - нет. А так интересно, конечно, что у вас все хорошо работает, а тут нет.
Да, тут тоже вариант, как раз другие разработчики такую схему делали с отдельной очередью.
Здесь только есть проблема -- если основная таска обработки сообщений внутри застряла, а периодичесая, которая пишет пинг, нет. Допустим, сообщение(не ping) обрабатывается реально долго, то asyncio таска будет писать ping дальше. Тут какой-то такой же механизм нужно прикрутить, чтобы понимать, прогресс обработки основного сообщения
Да, все так, судя по тому, что откопали - местами висело подключение к кафке, после перезапуска все ок. В добавок там могло висеть подключение к БД по какой-то причине. А еще aiokafka имел проблему с зависаниями.
> запускать consumer в отдельном приложении fastapi
Тоже была мысль какой-то эндпоинт прикрутить. У нас, кажется, такое делала другая команда. Сам не использовал, так-как параллельно пришлось прикручивать свое решение.
Я пробовал реализовывать свою логику через
SIGUSR1Было предположение, что завис процесс консьюмера и проблема именно в процессе. После посылки сигнала писалось нечто в файл. Если файл появлялся, то все ок. Если нет - не ок. В итоге консьюмер зависал не только по этой причине, но и по другим, а livenessProbe думал, что все в порядке
С подсветкой синтаксиса есть проблема на темном фоне. Стоит обновить
Есть задача двух генералов и есть задача византийских генералов. Они немного отличаются. Первая скорее про ненадежность связи. Вторая скорее про консенсус, насколько я понимаю
Возможно. Но это, пожалуй, именно что размышления, основанные на разных источниках. Хотелось создать некий мысленный фреймворк, чтобы было удобно мыслить понятиями. Может быть, это получилось и не очень.
Все верно, сам брокер не упоминается. Это первая часть, которая должна "подвести" читателя и дать легкий фреймворк для мышления в терминах гарантий доставки, чтобы было понятно, что имеется в виду по аналогии простого веб приложения. Брокер считай тот же самый сервер. Задумка была как-то это рассказать в серии статей.
А почему нет? Сетевой вызов под капотом это отправка того же самого сообщения
Да-да, все верно. Была задумка во второй статье рассказать про гарантии доставки со стороны продьюсера и про transactional outbox. В третьей статье рассказать про гарантии обработки со стороны консьюминга(показать, что меняя место commit/ack меняется и гарантия обработки).
Спасибо, не знал об этом
Да, про кафку будет в другой части
Спасибо, вторая часть в процессе.
Keynote. На ощупь подобрал себе цветовую схему и получился такой вид. Анимации там же. Для некоторых изображений еще использовал https://excalidraw.com/
Для меня такое не сработало -- городские маршруты приелись сразу же. Выходить желания нет.
Недавно нашел альтернативу в виде йоги.
1. Невыносимая жара. Ты просто выходишь из дома в середине мая в 30+ и хочешь умереть.
2. Еда дешевая? Нет, не совсем. Возможно, только во всяких ресторанах и пивных в сравнении с Москвой. В таких заведениях какой-нибудь бургер будет стоить не 700 руб минимум по сравнению с Московскими ценами, а 350, например, но самих заведений тут не так много. Продукты в условном магните такие же по цене +-. Мак/КФС/Бургер кинг — цены везде одинаковые
3. Дешевое жилье. Да, здесь действительно можно купить в муравейнике дешевое жилье, но фиг знает, инфраструктуры никакой.
4. Особо негде гулять, кроме тройки мест, которые можно посетить за пару дней.