Pipelines de pedidos
Los pedidos fluyen a facturación, envíos y analítica, y cada uno lee el mismo stream a su propio ritmo.
Datos básicosTrabajo en segundo plano
Streaming de eventos
Streams de eventos de solo anexado con grupos de consumidores, confirmaciones y recuperación automática de los mensajes que dejó un consumidor caído.
- log de solo anexado
- Duradero
- grupos de consumidores por stream
- N
- mensajes perdidos si hay un fallo
- 0
Paso 1 de 5
Publica un evento
El servicio de pedidos añade un evento y recibe su id.
Sesión de ejemploplaying
# Publica un evento
hotkv> XADD orders * type created order 1182 total 49.00
"1790985600123-0"
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
Los servicios que reaccionan a eventos necesitan algo más que una cola. Varios consumidores independientes quieren los mismos eventos, cada grupo de consumidores necesita repartir el trabajo entre instancias y, cuando una instancia muere con mensajes en la mano, alguien tiene que darse cuenta y hacerse cargo de ellos.
Cómo lo resuelve HotKV
Un stream es un log de solo anexado. Cada grupo de consumidores lo lee de forma independiente, entrega cada mensaje a un miembro del grupo y lo mantiene pendiente hasta que el miembro lo confirma. XAUTOCLAIM pasa a un consumidor sano los mensajes que llevan demasiado tiempo pendientes.
Paso a paso
Qué ocurre, comando a comando
- 01
Publica un evento
El servicio de pedidos añade un evento y recibe su id.
XADD orders * type created order 1182 total 49.00 - 02
Dos grupos, un stream
Facturación y envíos tienen cada uno su propio grupo y cada uno recibe el evento.
XGROUP CREATE orders billing 0 MKSTREAM - 03
Consume
Una instancia de facturación lee los mensajes nuevos de su grupo y se bloquea hasta que llega algo.
XREADGROUP GROUP billing billing-1 COUNT 10 BLOCK 5000 STREAMS orders > - 04
Confirma
Una vez creada la factura, facturación confirma y el mensaje sale de su lista de pendientes.
XACK orders billing 1790985600123-0 - 05
Recupérate de un fallo
Una instancia de envíos murió con mensajes en su poder. Tras 60 segundos inactivos, los reclama una instancia sana.
XAUTOCLAIM orders shipping shipping-2 60000 0-0 COUNT 25
Dónde encaja
Escenarios reales
Auditoría y feeds de actividad
Las acciones de los usuarios se añaden a un stream y cualquier servicio que necesite el historial puede reproducirlas.
Ingesta de IoT
Los mensajes de los dispositivos se almacenan en streams y los procesa un grupo de workers que escala con la carga.
Integrado
Qué obtienes
Log de solo anexado
Las entradas reciben ids ordenados por tiempo y se pueden recortar por longitud o antigüedad.
XADDXTRIMGrupos de consumidores
Cada grupo recibe todos los mensajes y reparte el trabajo entre sus miembros.
XGROUPXREADGROUPConfirmaciones
Los mensajes quedan pendientes hasta que se confirman.
XACKXPENDINGRecuperación automática
Los mensajes inactivos durante demasiado tiempo los reclama otro consumidor.
XAUTOCLAIMXCLAIMPreguntas frecuentes
¿Puedo reproducir eventos antiguos?
Sí. XRANGE lee cualquier parte del stream por id, y un grupo de consumidores nuevo puede empezar desde el principio.
¿Cómo evito que un stream crezca sin fin?
Recórtalo con XTRIM o con la opción MAXLEN o MINID de XADD.
¿Puede XADD evitar eventos duplicados?
XADD admite ids de productor idempotentes (IDMP), así que una publicación reintentada no crea una segunda entrada. Consulta la referencia de XADD.
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.