Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
Какие ощущения от ZeroMQ?
Хотя использовался один из достаточно простых сценариев ZeroMQ, общие впечатления продукт оставил весьма и весьма позитивные. Судите сами – быстро развернуть, просто настроить и достаточно приятный результат организации системы рассылки уведомлений.
Общая производительность (скорость прихода пакета обновлений объекта) системы оказалась тоже весьма достойной. Если не сочтется за PR, то могу раскрыть ссылку на приложение.
Общая производительность (скорость прихода пакета обновлений объекта) системы оказалась тоже весьма достойной. Если не сочтется за PR, то могу раскрыть ссылку на приложение.
Покажите, пожалуйста, ссылку, можно в личку
Данное решение использовалось в системе управления списками задач
P.S. Чтобы остальным пользователям было легче я обновил пост
P.S. Чтобы остальным пользователям было легче я обновил пост
Как вы решаете такую задачу: один из пользователей потерял соединение с интернетом, в это время добавилось 20 новых задач другим пользователем. После восстановления соединения у первого пользователя новые 20 задач не появились. Появляются только если обновить страницу или произвести какое-либо действие на странице.
Здесь вы правы, что узкое место такого рода систем – это потеря связи актуальной сессии браузера определённого пользователя с сервером сообщений. В данном случае ключевым является так называемое понятие времени «клинической смерти» сессии. Для оптимизации загрузки сервера рассылки сообщений мы установили максимальное число попыток переподключений и интервалы между ними. После этого, к сожалению для пользователей с непостоянным Интернет соединением, регистрация сессии на сервере будет окончена. НО, в рамках данной версии приложения дополнительно мы пытаемся переподключится перед каждым действием пользователя.
Пока мы видим необходимость доработки этой части решения, и данная задача входит в наш roadmap.
С другой стороны, я не могу сказать, что это узкое место решаемой нами задачи, потому что наличие у приложения только лишь веб-клиента предполагает наличие достаточно устойчивого Интернет соединения. Также пользователь не сможет добавлять задачи, не имея связи с сервером
Пока мы видим необходимость доработки этой части решения, и данная задача входит в наш roadmap.
С другой стороны, я не могу сказать, что это узкое место решаемой нами задачи, потому что наличие у приложения только лишь веб-клиента предполагает наличие достаточно устойчивого Интернет соединения. Также пользователь не сможет добавлять задачи, не имея связи с сервером
Можно при получении новых данных посылать некий acknowledge, это как в tcp тройное рукопожатие.
Как горизонтально масштабироваться будете с ZeroMQ?
какое количество уведомлений в минуту рассылаете? не тестировали nginx_push_stream_module для решения данной задачи?
SockJS сервер (в виде tornado-sockjs, что являлось одной из причин, по которой мы сделали свой выбор в сторону этого продукта)
Не совсем понял причину выбора? Наличие библиотеки? Вы рассматривали альтернативы?
Сегодня как раз занимался подобным — сделал websocket «звено», для оперативного взаимодействия связки: Клиента (browser) + IP-Телефония + Веб-сервер в виде «Call» центра, tornado уже пробовал поэтому решил попробовать gevent — pypi.python.org/pypi/gevent-websocket/, некоторые из основных причин — «синхронный» стиль кода (для меня более комфортен) + позволяет напрямую вызывать API web-сервера (синхронный, многопоточный), + не плохая производительность.
Так и не понял, зачем тут ZeroMQ. Можно же у Tornado сервера сделать «секретное» HTTP API по которому принимать информацию о новых событиях.
Ну ок, решили что ZeroMQ всё-же удобнее… Но зачем вам понадобился ZeroMQ Proxy??? Какую он функцию выполняет?
Кстати, можете объяснить как интегрируется event loop ZeroMQ и event loop Tornado? Я так понял, дело в этой строчке
P.S.: шикарно
Ну ок, решили что ZeroMQ всё-же удобнее… Но зачем вам понадобился ZeroMQ Proxy??? Какую он функцию выполняет?
Кстати, можете объяснить как интегрируется event loop ZeroMQ и event loop Tornado? Я так понял, дело в этой строчке
self._connection.stream = ZMQStream(socket, self.io_loop)?P.S.: шикарно
except Exception, e:
# Handle exception
pass
Так и не понял, зачем тут ZeroMQ. Можно же у Tornado сервера сделать «секретное» HTTP API по которому принимать информацию о новых событиях.Безусловно, предложенный Вами подход имеет права на жизнь. Но в случае с “секретным” HTTP API нам бы пришлось каким-либо образом обеспечивать “секретность”. Я не думаю, что полученное решение получилось бы намного более легким, чем текущее решение с ZeroMQ.
Ну ок, решили что ZeroMQ всё-же удобнее… Но зачем вам понадобился ZeroMQ Proxy??? Какую он функцию выполняет?ZeroMQ Proxy использовался как прокси между django и tornado. Возможно, что я не совсем точно понял Ваш вопрос, не могли бы Вы уточнить, как именно в данной ситуации Вы бы использовали ZeroMQ в подобной ситуации?
Касательно примера с обработкой исключений, то, как Вы могли заметить, исходные коды, приведённые в этой статье, максимально упрощены в целях облегчения понимания кода. Я могу Вас заверить, что в данном виде Вы бы не увидели их в работающем приложении.
Обеспечить секретность можно передавая GET параметр, который знает только Django и Tornado. Если GET параметр кажется недостаточно секретным, можно использовать Basic HTTP авторизацию, но я не уверен что для неё есть готовые обработчики в Tornado.
В конце концов, ZeroMQ у вас тоже НИКАК не защищён. Просто он слушает на
Не такой спец по ZeroMQ, но по аналогии с TCP сокетами Tornado был бы сервером (сабскрайбером) а Django клиентом (паблишером).
Tornado:
Django:
Не проверял, но просто по логике должно работать.
В конце концов, ZeroMQ у вас тоже НИКАК не защищён. Просто он слушает на
localhost. Так же и секретное API можно повесть слушать только на localhost на отдельном порту.Не такой спец по ZeroMQ, но по аналогии с TCP сокетами Tornado был бы сервером (сабскрайбером) а Django клиентом (паблишером).
Tornado:
class SockJSMyRouter(SockJSRouter):
def __init__(self, *args, **kw):
super(SockJSMyRouter, self).__init__(*args, **kw)
socket = context.socket(zmq.SUB)
socket.setsockopt(zmq.SUBSCRIBE, "")
socket.bind("tcp://127.0.0.1:XXXX") # !!!!!!!!!!!!!!!
self._connection.stream = ZMQStream(socket, self.io_loop)
Django:
import zmq
context = zmq.Context()
socket = context.socket(zmq.PUB)
socket.connect("XXXX")
socket.send("your message")
socket.close()
Не проверял, но просто по логике должно работать.
Так и не понял, зачем тут ZeroMQ. Можно же у Tornado сервера сделать «секретное» HTTP API по которому принимать информацию о новых событиях.
http медленный. 1.5*rtt только на установление tcp-коннекта и большой оверхед на коротких запросах.
одним процессом на cpython я получал ~ 80-90 тысяч сообщений в секунду. если взять pypy, будет еще веселее.
Могу назвать две причины:
1. Накладные расходы на разбор HTTP запроса будут выше чем разбор пакета ZMQ
2. С ZMQ будет легче масштабироваться в будущем. Добавление ноды в кластер не требует написания кода вообще.
В принципе, это применимо к любой message bus (AMQP, redis pub/sub, etc).
Но HTTP API тоже можно, если не планируется какой либо серьезной нагрузки.
1. Накладные расходы на разбор HTTP запроса будут выше чем разбор пакета ZMQ
2. С ZMQ будет легче масштабироваться в будущем. Добавление ноды в кластер не требует написания кода вообще.
В принципе, это применимо к любой message bus (AMQP, redis pub/sub, etc).
Но HTTP API тоже можно, если не планируется какой либо серьезной нагрузки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка системы синхронизации в реальном времени с использованием SockJS, Django, Tornado и ZeroMQ