Ingeniería
Estudio
Por área de la empresa
Por sector · 12
Veodar
Tecnología · Concurrencia en Rust
Tokio es la base sobre la que se escribe en Rust casi todo lo que hace varias cosas a la vez: atender conexiones, hablar con aparatos, mover ficheros, esperar respuestas. Permite que un solo programa lleve miles de tareas en curso con muy pocos recursos. Lo usamos para servicios que no pueden pararse y para el trabajo en segundo plano de las apps de escritorio.
Situaciones
Tokio compensa cuando un programa pasa la mayor parte del tiempo esperando, a la red, al disco o a una máquina, y no puede permitirse que una espera detenga a las demás.
Decenas o cientos de sensores, lectores o máquinas que envían datos cuando quieren. Cada uno es una tarea ligera; el que tarda no retrasa a los demás.
Una petición lenta bloquea el resto, o una conexión que no responde deja el programa esperando para siempre. Aquí cada espera lleva su tiempo máximo y su forma de cancelarse.
Sincronizar, importar un fichero grande o vigilar una carpeta mientras la persona sigue trabajando, sin que la ventana se congele.
Telemetría, avisos o cambios que se envían según ocurren, por una conexión abierta, a muchos clientes a la vez.
Servicios
Cuatro tipos de encargo. Los cuatro son el mismo oficio: que un programa haga muchas cosas a la vez sin que ninguna tumbe a las demás.
Módulo 1 · VíasProgramas que mantienen abiertas muchas conexiones a la vez, con aparatos, con clientes o con otros sistemas, y reparten el trabajo sin que una bloquee a otra.
Ejemplos de entregables
Módulo 2 · Puente giratorioTareas que corren mientras la aplicación sigue respondiendo: importaciones, sincronización, vigilancia de carpetas, con su cola, su límite de trabajos simultáneos y su progreso.
Ejemplos de entregables
Módulo 3 · CanalDatos que pasan de una tarea a otra por canales y salen hacia fuera según llegan, con control para que quien produce no desborde a quien consume.
Ejemplos de entregables
Módulo 4 · RelojLo que distingue un servicio que aguanta de uno que hay que reiniciar: cada espera tiene límite, cada fallo su reintento medido y el apagado termina lo que está a medias.
Ejemplos de entregables
Un ejemplo en funcionamiento
Demostración simulada. Dieciséis aparatos envían una lectura cada uno; el número 7 no responde. Lanza la ronda atendiéndolos de uno en uno y luego a la vez, con y sin tiempo máximo de espera.
Cómo se atienden
Resultado de la ronda
Elige cómo atenderlos y lanza la ronda.
Aparatos
Los aparatos y sus retrasos están simulados en tu navegador. Lo que cambia entre un modo y otro es lo que cambia en un servicio real: quién espera a quién, y qué pasa cuando alguien no contesta.
Integración
Tokio no se ve: es lo que hay debajo de un servicio o de una app cuando hacen varias cosas a la vez. Alrededor están quienes le hablan y a quienes responde.
De dónde viene
A dónde llega
Cómo trabajamos y qué entregamos
Miramos qué tiene que atender el servicio a la vez, cuánto tarda cada cosa y qué falla hoy bajo carga.
Escribimos las tareas, sus límites, qué pasa cuando algo no responde y cómo se apaga; y lo que queda fuera.
El servicio funcionando con tus aparatos, o con una simulación fiel de ellos, y sus métricas a la vista.
Lo pruebas con carga real, desconectando aparatos y cortando la red a mitad.
El mapa de tareas, los límites elegidos y por qué, y cómo leer las métricas.
Preguntas
¿Falta la tuya? Escríbela a info@veodar.com y te respondemos con una pregunta concreta, no con un dossier.
Es una biblioteca de Rust, la más usada para programación asíncrona. Se ocupa de repartir muchas tareas entre pocos hilos del procesador, de modo que una tarea que está esperando no ocupa a nadie. Sobre ella están construidos la mayoría de los servidores, clientes de base de datos y bibliotecas de red del ecosistema.
Si hace algo más que mostrar formularios, casi seguro: sincronizar, hablar con un aparato o importar un fichero sin congelar la ventana es trabajo asíncrono. En una app hecha con Tauri, Tokio ya viene debajo.
La idea es parecida: no bloquear mientras se espera. La diferencia es que Rust usa todos los núcleos del procesador, gasta menos memoria y comprueba al compilar que dos tareas no pisan el mismo dato. Para un servicio que mueve muchos datos o debe estar siempre en pie, eso pesa; para una integración sencilla, Node.js suele bastar.
Lo que se haya decidido, y se decide antes: esperar un tiempo máximo, reintentar unas cuantas veces con pausas crecientes, marcarlo como caído y avisar. Lo que no puede pasar es que el servicio entero se quede esperando.
No es su papel. Tokio brilla cuando hay muchas esperas; el cálculo intensivo se manda a hilos aparte para no frenar al resto. Parte del diseño consiste en separar bien las dos cosas.
Con métricas y trazas desde el primer día: cuántas tareas hay en curso, cuánto esperan, cuáles fallan. Sin eso, un servicio concurrente es una caja negra, así que forma parte de la entrega.
Actualizado:
Servicios relacionados
Otras tecnologías
Empezar
Con saber cuántos aparatos o conexiones hay y qué falla hoy nos basta para una primera respuesta.
Qué ayuda a valorarlo
¿Antes de escribir? Mira cómo presupuestamos un proyecto o las soluciones por área de la empresa.
Cookies
Guardamos tu idioma y esta elección para que la web funcione. Con tu permiso medimos visitas y velocidad de forma anónima, sin cookies de seguimiento ni publicidad.
Cookies
Necesarias
Tu idioma, esta elección y la protección antispam del formulario de contacto.
Medición anónima
Páginas vistas y tiempos de carga, en conjunto, con Vercel. No usan cookies ni te siguen por otros sitios.