Pull to refresh

Comments 16

Ребята, а нельзя было очередь перед демоном поставить? Ну повисели бы запросы в очереди пару миллисекунд, пока демон рестартует. Зачем так сложно делать то?
Могу предположить, что задержки. Но основная моя идея — было бы не так интересно!
Ну, причин несколько:
1) мы нигде не используем очереди перед демонами, и поэтому делать такое перед этим конкретным демоном тоже не стали
2) демон запускается на каждом нашем сервере, т.е. серверов очередей нужно, видимо, тоже много :)?
3) Приведенное здесь решение самодостаточно — этот подход можно применять для рестарта любого однопоточного демона, в том числе если это непосредственно сервер очередей
4) Это же просто интересный challenge :), а сервера очередей или любой другой прокси-демон — это слишком скучно
Пункты 1, 2, 3 — просто пыль в глаза, весь огород ради п.4 :)
Очереди не спасут когда есть долгоживущие соединения и не хочется из обрывать.
В модели publisher-subscriber как раз долгоживущее соединение для subscriber'a
А причем тут модель? В модели нет ничего о соединении, соединение — это физический уровень. А модель описывает логический уровень разделения ответственности между паблишерами и подписчиками, и не более. Можете делать длинное соединение и гет, можете длинное и пуш, в случае сильно распределенных сред можете получать UDP-уведомления, можете короткое и гет, вариантов море. А модель вообще ни при чём. Вы не правы, потому что пытаетесь притянуть очереди (то есть архитектурный концепт) к проблеме на физическом уровне (рестарт без потери открытых соединений).
2 — нет
3 — есть много готовых решений, как перезапустить сервис/процесс, если он умер, при этом еще и СМС админу отправить
1, 4 — без комментариев

Все-таки посмотрите на RabbitMQ, Gearman
Не знаю как там дела у RabbitMQ, но насчет Gearman'а — вы сами-то работали с ним, чтобы его советовать как средство решения проблемы обновления кода воркеров без потери соединения и с плавным переводом обработки текущих задач на новый воркер? Он же ничего из этого не умеет: там также приходится городить подобные разнообразные костыли для решения этих проблем. И то я не уверен, что вообще там получится довести всё до подобного уровня, который описан в статье.
А в чем загвозка?
Я так пониманию, схема остановили воркер, обновили код, запустили воркер вас не устроила. Но почему?

Вы статью-то читали? :) Там же написано всё.
1 — Это вопрос архитектуры. Да, есть сервера очередей. Да, с их помощью тоже можно решать описанную проблему. Но это уже просто другой подход. Кроме того, сам сервер очередей так же может упасть, его так же может потребоваться перезапустить.
2 — Если сервер очередей один на все экземпляры демона — то это, во-первых, SPoF, а, во-вторых, это означает, что он находится на каком-то отдельном сервере, что увеличивает сетевые издержки. Если серверов очередей несколько — это ставит вопрос о балансировке нагрузки между ними и обеспечении отказоустойчивости при падении нескольких из них. То есть это ещё один слой архитектуры, который нужно настраивать и поддерживать.
3 — Касательно готовых решений для перезапуска упавших демонов — да, они есть. Но в данной статье не рассматривается проблема автоматизации перезапуска демона. Рассматривается проблема сохранения открытых соединений. Кроме того, перезапускать демон нужно не обязательно тогда, когда он падает. Например, его надо перезапускать при обновлении его версии(кода), что может случаться несколько раз в день.
C web-сокетами, насколько я понимаю, такое не прокатит?
Зависит от того, как вы работаете с ними. Если это однопоточное приложение с event loop, то должно работать. Впрочем, в случае с вебсокетом лучше и проще сделать переконнект при потере соединения/таймауте на клиенте. Это поможет не только в случае перезапуска демона, но и в случаях сбойного интернета у клиента, а также в случае проблем на стороне сервера (например, демон может банально «упасть», и тогда соединения все равно пойдут лесом).
Под переконнектом вы что подразумеваете? Если такая ситуация, что при новом соединении выдается, естественно, новый ID соединения. А другие пользователи (например, из чата) ему пишут, и сервер пытается отправить в сокет со старым ID. Нового-то он не знает.
Поэтому неавторизованным пользователям нужно генерировать свой id заранее, можно наверное даже на стороне клиента, рандомом :). Ну или по нику пользователя в чате. А для авторизованных пользователей нужно пользоваться его user_id.
Sign up to leave a comment.