Message Queues Vs DB Table Queue a través de CRON
message-queue beanstalkd (4)
Próximamente tenemos un gran proyecto con bastante procesamiento de medios (imágenes, video), salida de correo electrónico, etc., el tipo de cosas que normalmente poníamos en una tabla llamada "email_queue" y usamos un cron para ejecutar un El script procesa la cola en la tabla.
He estado leyendo mucho en sistemas de Message Queue como beanstalkd, e incluso lo he configurado. Fue fácil y agradable de usar, el problema es que no estoy seguro de si me estoy perdiendo algo.
¿Podría alguien detallar los beneficios de usar un sistema de colas en lugar de una tabla y un CRON? Ya que realmente no puedo ver para ver qué son.
Gracias
Diferencias
Una vez que un mensaje se pone en la cola, se puede entregar inmediatamente. Entonces, si su cron normalmente se ejecuta cada 5 minutos, podría procesar más rápido con la cola.
Si su sistema de colas admite transacciones, entonces volverá a enviar un mensaje automáticamente si falla el procesamiento.
Puede ser más difícil consultar qué hay en tu cola. Una tabla de base de datos tiene una buena manera de buscar (sql).
Si tiene varios servidores / procesos / subprocesos que manejan mensajes, el sistema de cola se asegurará de que solo se entregue un mensaje a uno de ellos. Con una tabla de base de datos debe manejar esto a través del código de la aplicación (bloqueo, indicadores, etc.)
Esto se hace con bastante frecuencia y, por lo general, no hay una razón convincente para ir a MQ si se siente cómodo con las bases de datos. Aquí hay un ejemplo de hilo .
Mi opinión es que es posible que desee evitar la curva de aprendizaje a menos que sus requisitos de datos incluyan volúmenes excepcionalmente altos, lo cual es improbable si usted es cron cronico en lugar de un proceso con un temporizador (mucho menos procesos múltiples con temporizadores).
Primero, las colas a menudo están respaldadas por tablas de base de datos reales y pueden mantener la durabilidad del mensaje. Aparte de eso, la cola es una forma natural de eliminar el trabajo que se debe hacer de forma asíncrona, que si se diseña en ese principio desde el principio es muy poderoso.
Aparte del hecho de que una tabla (entidad) tiene un conjunto de columnas duras (atributos), tanto esta tabla que se compone de un conjunto de registros que componen como una cola no son más que listas de cosas. Está utilizando la cola como -una tabla como una cola formal, solo que la está encuestando regularmente (cron).
Las MQ agregan otra característica ingeniosa, aunque generalmente sincronizan el acceso al mensaje en sí mismo (puede o no estar haciendo esto en su SQL para obtener la siguiente cosa).
Me gusta considerar el mecanismo cron / table como basado en POLL y el MQ como basado en EVENT.
El beneficio de una cola en mi opinión es que se encarga de la sincronización y la actualización del estado. Los MQ se pueden configurar para "transmitir" (tema) o poner el mensaje a disposición de un grupo de consumidores u oyentes.
Las MQ aunque asíncronas probablemente funcionarán entre su ventana cron. ¿Cómo sabe que la cantidad de mensajes que procesa en su tabla se puede lograr antes de que se ejecute el siguiente trabajo cron e intente avanzar en el trabajo anterior?
Múltiples consumidores para el MQ le permite escalar el trabajo como mejor le parezca. En el ejemplo anterior, si vio que su load average (igual que en la cola de proceso del sistema operativo) es mayor de lo que desea, puede aprovisionar a otro consumidor para manejar dicha carga, activándola y desconectándola según lo requiera la métrica.
Las MQ pueden configurarse para tener diferentes parámetros operativos, como la prioridad y el rendimiento del mensaje (algunas colas pueden permanecer en la memoria, otras persisten en el disco).
El inconveniente es que (como ya se mencionó) a veces la cola puede ser difícil de consultar y para la cual obtener métricas. Siempre encuentro sistemas MQ que tienen un almacén de respaldo de base de datos para que yo pueda ver la cola con SQL.
Una cola de mensajes (al menos una distribuida, por ejemplo, RabbitMQ ) le brinda la capacidad de distribuir el trabajo entre los nodos físicos. Aún necesita tener un proceso en cada nodo para poner en cola el trabajo y procesarlo.
En última instancia, se reduce a sus necesidades, supongo. Puede lograr una solución más manejable a escala con el uso de colas de mensajes: puede desacoplar sus nodos más fácilmente.
Por supuesto, hay una curva de aprendizaje ... por lo que, nuevamente, vuelve a tus objetivos.
Tenga en cuenta que en cada nodo aún puede reutilizar su tabla cron / db hasta (y si) desea cambiar la implementación. Eso es lo bueno de la disociación cuando puedes .