Сервер Vertx SockJS против sockjs-tornado

Я изучал два похожих решения для поддержки веб-сокетов через sockJS с использованием независимого сервера Python и пока нашел два решения.

Мне нужно написать сложное масштабируемое веб-приложение на основе веб-сокетов, и я боюсь, что Tornado будет трудно масштабировать, и кажется, что Vertx лучше с горизонтальным масштабированием веб-сокетов.

Я также понимаю, что Redis можно использовать в сочетании с Tornado для горизонтального масштабирования системы pub/sub и HAproxy для масштабирования запросов SockJS.

Какое решение между Vertx и Tornado является предпочтительным для написания масштабируемой системы, поддерживающей SockJS?


python vert.x tornado sockjs
person Ron Reiter    schedule 29.09.2012    source источник
comment
Оба в порядке. Не вижу проблем с масштабированием торнадо. Vertx может быть проще, не смотрел.   -  person Nikolay Fominyh    schedule 01.10.2012

Ответы (2)


arrow_upward
3
arrow_downward

Vertx имеет встроенную поддержку кластеризации. Я не пробовал это со многими узлами, но, похоже, с некоторыми он работал хорошо. Внутри он использует hazelcast для организации узлов. Vertx также работает на JVM, в которой уже есть много инструментов мониторинга/администрирования, которые могут быть полезны. Так что Vertx кажется мне решением «с батарейками в комплекте».

person Philipp Brüll    schedule 26.11.2012

arrow_upward
2
arrow_downward

Вы также можете использовать Sockjs Tornado + Rabbit MQ + Memcached для горизонтального масштабирования. Брокер RabbitMQ будет играть роль шины обмена сообщениями от физического Сервера А к физическому Серверу Б. Вся информация о серверах может храниться в memcache. Например, вам нужно отправить сообщение M из клиентского сокета C1(A) в клиентский сокет C2(B):

  • если получатель A размещен на том же сервере (проверив memcache), отправьте сообщение напрямую с помощью SockJS Router
  • в противном случае отправьте M через брокер RabbitMQ B1 (A) (используя логику маршрутизации) на B2 (A), где маршрутизатор SockJS B может напрямую отправить ваше сообщение исходному получателю C2 (B).

Поскольку протокол AMQP RabbitMQ использует Erlang, передача сообщений очень стабильна и достаточно хороша для распределенных приложений с высокой нагрузкой. Чтобы подтвердить мои слова, посмотрите здесь: http://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/

Каждый физический сервер (со следующей мощностью Xenon 4-node, MEM 4Gb, HDD-140-1000Gb) может обслуживать 3-5 экземпляров sockjs tornado. Реализация SockJS также довольно хорошо использует обратный прокси (HaProxy) через дополнительные параметры в URL-адресе.

Для распределенного тестирования вы можете использовать gemetr или tsung (на основе erlang).

Я использовал этот подход в нескольких распределенных приложениях.

Кроме того, не забудьте использовать память Tornado в качестве кеша L1.

person Rustem K    schedule 09.06.2013