He leído mis documentos, la mayoría de los ejemplos son para casos de uso básico.
Donde simplemente un proceso publica un evento X y otro se suscribe al evento X.
Pero en mis aplicaciones X es un tipo de variable. entonces digamos que "X" significa mi usuario.
entonces puedo publicar desde un evento servidor como user-ID significa que si hay 1000 usuarios conectados al servidor, estará bien publicar y suscribirse a tantos temas dinámicos, y luego otros 20 servidores se suscribirán a los temas de 1000 en este servidor.
Veamos el ejemplo.
Tengo 10 servidores. Cada servidor con 1000 usuarios conectados, por lo que hay 10 000 usuarios. Necesito enviar datos X de cada usuario a otro usuario.
así que he hecho esto.
Publicación del servidor X user-ID datos (1 publica el usuario que está conectado, 1K publica)
Servidor Y suscribirse user-ID datos (solicitud de suscripción de 10k enviada a cada servidor)
¿Cuál debería ser la forma óptima de pub sub con temas dinámicos para que se use menos ancho de banda entre los servidores?
Darse cuenta::
ID de usuario es solo un ejemplo donde ID es un número dinámico y publica algunos datos en tiempo real que no se pueden almacenar en ningún lado.
Respuestas
1 para la respuesta № 1En ZeroMQ, se implementa la coincidencia de suscripción en el socket PUB con un prefijo-matching trie. Esta es una estructura de datos muy eficiente, y yo esperaría que las suscripciones de 10K y 10K msg / seg no supongan ningún problema.
El conector PUB solo envía mensajes para hacer coincidirsuscripciones (para que no haya "desperdicio"). Si un mensaje no coincide con ninguna suscripción, el socket PUB lo descartará. Los mensajes coincidentes solo se envían a los sockets SUB que se han suscrito a ellos.
Cuando agrega o elimina una suscripción, el socket SUB enviará un mensaje a su (s) socket (s) PUB conectado (s). Cada socket PUB actualizará su tema trie.
Mi suposición es 10k subs y 10k msgs / s no esproblema, pero lo mejor sería escribir un código de prueba y probarlo. Una vez, lo bueno de ZeroMQ es que no es mucho trabajo probar diferentes arquitecturas.
1 para la respuesta № 2
Por lo que sé, en Pyzmq el editor API puede enviar mensajes a cualquier tema
socket.send("%d %d" % (topic, messagedata))
y los suscriptores establecen un filtro sobre estos temas para el tema de sus intereses con setsockopt
topicfilter = "10001"
socket.setsockopt(zmq.SUBSCRIBE, topicfilter)
Entonces creo que puedes implementar completamente tu plan.