Correo y SMS transaccionales
La app web encola los mensajes de registro, recibo y restablecimiento, y un grupo de workers los envía.
Datos básicosTrabajo en segundo plano
Colas de trabajos
Colas FIFO que no pierden trabajos cuando un worker muere, con productores y consumidores ejecutándose en paralelo.
- LPUSH/s con pipeline, medido
- 31.6M
- trabajos perdidos si hay un fallo
- 0
- sondeos
- 0
Paso 1 de 5
Los productores añaden trabajos
Cualquier servicio añade trabajo sin esperar a los consumidores.
Sesión de ejemploplaying
# Los productores añaden trabajos
hotkv> LPUSH queue:emails "{\"to\":\"ada@example.com\",\"tpl\":\"welcome\"}"
(integer) 18
Un recorrido animado con comandos reales de HotKV y respuestas de ejemplo. Haz clic en cualquier paso para saltar a él. Los comandos y las respuestas se quedan en inglés, tal como los escribes y los ves en HotKV.
El problema
El trabajo en segundo plano, como los correos, el redimensionado de imágenes y los webhooks, necesita una cola entre el código que lo crea y el código que lo hace. Una cola que pierde un trabajo cuando un worker falla a mitad de tarea es peor que no tener cola, porque nadie se da cuenta de que el trabajo ha desaparecido.
Cómo lo resuelve HotKV
Las listas te dan una cola FIFO sencilla. BLMOVE mueve cada trabajo a una lista de proceso en el momento en que se entrega a un worker, así que un trabajo en curso siempre está guardado en algún sitio si ese worker desaparece. Productores y consumidores se atienden en hilos de trabajo paralelos.
Paso a paso
Qué ocurre, comando a comando
- 01
Los productores añaden trabajos
Cualquier servicio añade trabajo sin esperar a los consumidores.
LPUSH queue:emails "{\"to\":\"ada@example.com\",\"tpl\":\"welcome\"}" - 02
Un worker toma un trabajo de forma segura
BLMOVE se bloquea hasta que hay un trabajo disponible y luego lo mueve a una lista de proceso en un solo paso.
BLMOVE queue:emails queue:emails:processing RIGHT LEFT 0 - 03
Confirma al terminar
El correo se envió. El trabajo se elimina de la lista de proceso.
LREM queue:emails:processing 1 "{\"to\":\"ada@example.com\",\"tpl\":\"welcome\"}" - 04
Un worker falla
El worker 2 muere a mitad de un trabajo. Su trabajo sigue en la lista de proceso, no se pierde.
LRANGE queue:emails:processing 0 -1 - 05
Vuelve a encolar y sigue
Un monitor devuelve el trabajo abandonado a la cola y otro worker lo recoge.
LMOVE queue:emails:processing queue:emails LEFT RIGHT
Dónde encaja
Escenarios reales
Procesamiento de medios
Las subidas se encolan para generar miniaturas y transcodificar, y un transcodificador que falla nunca pierde un archivo.
Entrega de webhooks
Los webhooks salientes se encolan y se reintentan sin bloquear la solicitud que los provocó.
Integrado
Qué obtienes
FIFO con lecturas bloqueantes
LPUSH con BRPOP, y los workers duermen hasta que llega trabajo.
LPUSHBRPOPSin trabajos perdidos
BLMOVE pasa cada trabajo a una lista de proceso de forma atómica.
BLMOVELREMProductores y consumidores en paralelo
Productores y consumidores se atienden en hilos de trabajo paralelos.
¿Necesitas más?
Para confirmaciones, grupos de consumidores y repetición, usa streams.
XADDXREADGROUPPreguntas frecuentes
¿Qué le pasa a un trabajo si un worker falla?
Si tomas los trabajos con BLMOVE, el trabajo se queda en la lista de proceso. Un monitor puede devolver a la cola todo lo que lleve ahí demasiado tiempo.
¿Los workers tienen que sondear?
No. BRPOP y BLMOVE se bloquean hasta que llega un trabajo, con un tiempo de espera opcional.
¿Listas o streams?
Las listas son la cola más sencilla. Los streams añaden grupos de consumidores, confirmación por mensaje e historial. Consulta el caso de uso de streaming de eventos.
Casos de uso relacionados
Pruébalo con tu propia carga de trabajo
HotKV habla el protocolo de Redis, así que puedes apuntar un cliente que ya usas hacia él y ejecutar estos mismos comandos.