저는 독립적 인 Python 서버를 사용하여 sockJS를 통해 웹 소켓을 지원하는 두 가지 유사한 솔루션을 검사했으며 지금까지 두 가지 해결책을 찾았습니다.Vertx SockJS 서버 vs Sockjs-Torornado
복잡하고 확장 가능한 웹 소켓 기반의 웹 응용 프로그램을 작성해야하는데 토네이도를 확장하는 것이 어려워서 Vertx가 웹 소켓의 수평 확장에 유리한 것으로 보입니다.
또한 Redis는 pub/sub 시스템을 수평으로 확장하기 위해 Tornado와 함께 사용될 수 있고 SockJS 요청을 확장하기 위해 HAproxy를 사용할 수 있음을 알고 있습니다.
Vertx와 Tornado 사이에서 SockJS를 지원하는 확장 가능한 시스템을 작성하기 위해 선호되는 솔루션은 무엇입니까?
Vertx에는 빌트인 클러스터링 지원이 있습니다. 나는 많은 노드로 시도하지는 않았지만 몇 가지 노드와 잘 작동하는 것처럼 보였다. 내부적으로는 hazelcast를 사용하여 노드를 구성합니다. Vertx는 유용 할 수도있는 이미 많은 모니터링/관리 도구가있는 JVM에서 실행됩니다. 그래서 Vertx는 "배터리가 포함 된"솔루션을 좋아합니다.
또한 수평 확장을 위해 Sockjs Tornado + Rabbit MQ + Memcached를 사용할 수도 있습니다. RabbitMQ 브로커는 물리적 서버 A에서 물리적 서버 B로 메시징 버스 역할을 수행합니다. 서버에 대한 모든 정보가 memcache에 저장 될 수 있습니다. (memcache를 확인하여) 동일한 서버에서 호스팅의 수신기, MSG를 보내는 경우 직접 사용
Erlang을 사용하는 RabbitMQ의 AMQP 프로토콜 때문에 메시지 전달이 매우 안정적이며 부하 분산 응용 프로그램에 매우 적합합니다. 내 단어를 지원하려면 다음을보십시오. http://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/
각 물리적 서버 (다음 전원 Xenon 4 노드, MEM 4Gb, HDD 140-1000Gb)는 3-5 sockjs 토네이도 인스턴스를 처리 할 수 있습니다. SockJS 구현은 URL에 추가 매개 변수를 사용하여 역방향 프록시 (HaProxy)를 사용하는 것도 좋습니다.
분산 테스트의 경우 gemetr 또는 tsung (erlang 기반)을 사용할 수 있습니다.
나는이 접근 방식을 몇 가지 분산 된 응용 프로그램에서 사용했습니다.
또한 Tornado 메모리를 L1 캐시로 사용하는 것을 잊지 마십시오.
모두 괜찮습니다. 토네이도 스케일링에 문제가 보이지 않습니다. Vertx는 더 쉬울 수도 있고, 보지 않았을 수도 있습니다. –