Diseñar una arquitectura de cola de mensajes escalable

Recientemente comencé a aprender los matices de la arquitectura informática escalable y empresarial, y uno de los componentes centrales es una cola de mensajes. Para aprender lo más que pueda de cualquier paradigma de programación, estoy tratando de implementar mi propia versión de un servicio de cola de mensajería.

Hasta ahora, mi diseño inicial se ejecuta en un escucha de socket roscado, pero para evitar que el mismo mensaje sea descargado dos veces por dos nodos de procesamiento separados, el registro del índice de la cola de mensajes se bloquea cuando se inicia una lectura y se desbloquea después de que el registro ha sido actualizado. Como tal, esto niega la necesidad de que se enhebre y significa que hay un límite para el tamaño de un sistema escalable en función de la velocidad de procesamiento del servidor en el que se ejecuta el servicio de cola de mensajería.

La forma de evitar esto sería ejecutar el servicio de cola de mensajes en varios servidores, pero esto aumentará la probabilidad de que el mismo mensaje se descargue dos veces. La única forma de evitar que ocurran tales problemas sería incluir una devolución de llamada de revocación que (después de que los servidores, o incluso los hilos en un solo servidor, hayan sincronizado su información y detectado dicha reemisión) ordenaría al nodo de procesamiento que detenga su trabajo actual y vuelva a consultar la cola de mensajes para el siguiente mensaje, pero nuevamente, habría un límite en el que la mayor parte del tráfico que se enviaría sería sincronizaciones y revocaciones de revocación, lo que provocaría un cuello de botella y ralentizaría el procesamiento de la información para que Muchos de los nodos de procesamiento estarían realizando operaciones nulas y perdiendo el tiempo.

La última forma en que puedo pensar para solucionar este problema es hacer que cada servidor de la cola de mensajes (y cada hilo en cada servidor) tenga un desplazamiento específico en cuanto a en qué parte de la cola está buscando, pero eso podría tener problemas basados ​​en el tipo de aplicación, especialmente si se requiere que el procesamiento se realice en un orden específico.

Entonces, dicho todo esto, ¿hay algún diseño de arquitectura de colas de mensajes que pueda mostrarme cómo los servicios de colas de mensajes de nivel empresarial existentes evitan estos problemas?

En breve:

Es este un problema difícil. No reinventes la rueda.

Existen muchas tecnologías que resuelven la capa de la cola de mensajes. Incluyen

• ZeroMQ
• RabbitMQ
• Apache Kafka
• Redis, con BLPOP o PUBSUB (he preguntado cómo hacer esto aquí ).
• Otras implementaciones de AMQP además de RabbitMQ

Creo que está fuera de alcance para mí discutir los inconvenientes de cada uno, sobre todo porque realmente no afirmo que la experiencia para hacer esto bien la tos no use la tos del conejo .

Incluso si no desea utilizar ninguna de estas tecnologías, lea sus documentaciones.

Esto lo educará sobre los patrones de diseño que son posibles en un sistema. La lectura de la documentación de ZeroMQ lo educará sobre muchas arquitecturas clásicas de colas de mensajes que han implementado gentilmente. Incluso si no usa ZeroMQ, conocer estos patrones lo ayudará a evaluar otras tecnologías de colas al preguntarle si puede implementar ese patrón allí.

Conozca el modelo de cola de intercambio de RabbitMQ / AMQP. El enrutamiento puede surgir para usted, esto es compatible con Redis PUBSUB, pero no recuerdo haber sido respaldado por ZeroMQ, y los fanouts son algo que mi tienda ha estado utilizando, aunque mal implementado en una encuesta de Memcached (¡qué asco!), Durante bastante tiempo .

¿Cómo elegir uno?

Trabajo en una startup cuyo SLA es típico para una aplicación web: algunas interrupciones están bien, siempre que podamos restaurar rápidamente el servicio con poca pérdida de datos. No hemos tenido que pensar en problemas de escala como Twitter o Tumblr, por lo que realmente no hemos tenido que pensar en el volumen de rendimiento. Dicho esto, si está implementando un SLA similar al mío, estas consideraciones le vendrán a la mente:

• Cómo funcionan realmente las bibliotecas cliente ? ¿Es fácil mantener una conexión en ellos? (ZeroMQ, Redis: sí. RabbitMQ: no).
• ¿Es fácil monitorear y administrar desde una consola de servidor? (Redis: sí, RabbitMQ: sí, ZeroMQ: no recuerdo, pero no lo usamos por mucho tiempo)
• ¿los clientes admiten colas internas, por lo que se produce una pequeña pérdida de datos en cortes cortos? (ZeroMQ, Redis: sí. RabbitMQ: no.)

Por supuesto, si está trabajando para, por ejemplo, una tienda comercial de alta frecuencia, estas serán sus preocupaciones menores. Estará más dispuesto a dedicar tiempo de desarrollo a una biblioteca del lado del cliente a cambio de un mayor rendimiento al final. Pero escribo esto más para advertirle que estas tecnologías tienden a comercializarse en función de su rendimiento, no de su funcionalidad lista para usar. Si es una startup web, está mucho más interesado en lo último que en lo primero, y en consecuencia, probablemente algo como Redis, que está más optimizado para facilitar su uso con un buen rendimiento que la dificultad de uso con un gran rendimiento mejor opción que RabbitMQ. (Realmente no me gusta RabbitMQ).