Egutierrez
c9e28b8135
JetStream: anatomia de streams (storage/retention/limits), consumers pull durables con ack y cursor, dedup por Nats-Msg-Id, retencion workqueue, deliver policies. Simulador: boton ipywidgets que lanza 1 publisher -> N subscribers con miles de mensajes y grafica en movimiento (acumulado + throughput instantaneo).
3.3 KiB
name, lang, domain, description, tags, uses_functions, uses_types, framework, entry_point, dir_path, repo_url
| name | lang | domain | description | tags | uses_functions | uses_types | framework | entry_point | dir_path | repo_url | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| nats | py | datascience | Demostracion de envio de datos por pub/sub entre procesos con NATS (core pub/sub, wildcards, queue groups, request/reply, JetStream y procesos OS reales) |
|
jupyterlab | notebooks/01_core_pubsub.ipynb | analysis/nats |
Notas
Analisis didactico de NATS como sistema de mensajeria pub/sub entre procesos. El broker corre en Docker (nats:latest -js, puerto 4222) y el cliente es nats-py (asyncio). Tres notebooks progresivos:
| Notebook | Contenido |
|---|---|
01_core_pubsub.ipynb |
Modelo base: conexion, publish/subscribe, fan-out a N subscribers, wildcards * y >. |
02_queue_request_jetstream.ipynb |
Queue groups (reparto de carga), request/reply (RPC con inbox temporal), JetStream (stream persistente + consumer durable + replay). |
03_procesos_reales.ipynb |
Publisher y subscribers como procesos del SO independientes (subprocess), cada uno con su PID. Demuestra el desacople real: el publisher no conoce a sus subscribers. |
04_jetstream_benchmark.ipynb |
JetStream a fondo (storage/retention/limits, consumers durables + ack + cursor, dedup por Nats-Msg-Id, retención workqueue, deliver policies) + simulador de rendimiento interactivo: un botón ipywidgets que lanza 1 publisher → N subscribers con miles de mensajes y una gráfica en movimiento (acumulado pub vs subs + throughput instantáneo). |
Los scripts notebooks/procs/publisher.py y notebooks/procs/subscriber.py son los programas que el notebook 03 lanza como procesos reales.
El notebook 04 requiere ipywidgets (incluido en el .venv del análisis). El simulador es interactivo: al abrir el notebook en JupyterLab, ejecuta sus celdas hasta el widget y pulsa ▶ Ejecutar benchmark (los sliders ajustan número de mensajes y de subscribers). La gráfica se anima mientras corre.
Como usar
- Requiere Docker disponible (con permisos para el usuario actual). La primera celda de cada notebook arranca el broker de forma idempotente con la funcion
ensure_nats, asi que cada notebook funciona de forma aislada. - Lanzar Jupyter del analisis:
cd analysis/nats && ./run-jupyter-lab.sh(puerto 8890). - Abrir cualquier notebook y ejecutar las celdas en orden.
Requisitos
nats-py(instalado en el.venvdel analisis).- Imagen Docker
nats:latest(se descarga condocker pull nats:latestla primera vez). - El broker comparte el contenedor
nats_demoentre los tres notebooks.
Parar el broker
Cuando termines, para y elimina el contenedor:
docker stop nats_demo && docker rm nats_demo
Reproducir / regenerar los notebooks
El script build_notebooks.py regenera los tres .ipynb desde cero con nbformat (sin ejecutar). La ejecucion se hace luego desde JupyterLab o via el MCP de Jupyter:
.venv/bin/python build_notebooks.py
Nota tecnica sobre el MCP de Jupyter
Si abres Claude desde la raiz de fn_registry, su MCP de Jupyter apunta al servidor global (puerto 8899, root fn_registry), no al servidor de este analisis (8890). Para usar el MCP contra este analisis con su propio .venv, abre Claude desde el directorio del analisis: cd analysis/nats && claude — el .mcp.json local enlaza el MCP al puerto 8890.