Con los protocolos gossip vamos a dar por interrumpida esta serie, en la que hemos hablado de cachés, de particionado y de tablas hash siempre en torno a un ejemplo de Infinitext, un caso realista aunque no real.

Podéis encontrar definiciones mucho más detalladas y con categorizaciones y todo, pero ya sabéis que me gustan las cosas simples y un protocolo gossip simplemente es un algoritmo de comunicación que montas para «que todo el mundo lo sepa todo».

Haces que las máquinas (los agentes) hablen entre sí y se cuenten todo confiando en lo que se les cuenta pero siempre teniendo en mente que puede ser erróneo. De este modo consigues que todos tengan más o menos la misma información.

Cómo sea este protocolo ya depende del entorno al que te enfrentes. En un sistema con muchos agentes, será preferible que cada uno le cuente las noticias a unos pocos de los que tiene por alrededor y a su vez estos se lo cuenten a otros pocos con un paso exponencial de la información. En un sistema pequeño y con poca información que manejar puede que sea más fácil hacer que el agente que genera un evento sea el que se lo cuente a todos los demás.

Generalmente se usan en sistemas muy grandes, y por eso es preferible que en lugar de que una sóla máquina mande muchos mensajes, sólo informe a un par de compañeros y estos a su vez a otros dos cada uno, de tal modo que el número de máquinas que conocen la nueva información aumente exponencialmente.

Sé que puede parecer muy abstracto, pero veámoslo sobre nuestro ejemplo:

De repente, una madrugada te despiertas sobresaltado y lo visualizas: el bug de la Nube™ afecta también al servidor que tienes con la tabla hash. Todo se para porque todo pasa por él, y gracias a que el procesado de las peticiones que recibe es muy corto, es cosa de un instante… ¿y ahora qué? ¿cómo lo solucionas? Aquí no te vale meter más servidores, necesitas que sólo haya una tabla hash.

Lo que necesitas es tener varias réplicas de la tabla para que si se cae el servidor que la contiene el sistema no se vea afectado. Necesitas que los datos que se almacenen en todas esas réplicas sean consistentes, y preferiblemente gastarte lo menos posible.

Lo que puedes hacer es que el balanceador de carga mande la petición al servidor que sea (dejarlo como al principio de todo, sin una lógica especial). Ese servidor mirará en su tabla si esa petición la debería de procesar él. En caso de que no, se la pasará al servidor que si debería de hacerlo (hace el trabajo que hacía antes el pequeño servidor que tenía la tabla hash) y el servidor que la recibe la procesa normalmente.

Hasta aquí todo normal, pero… ¿y si ese servidor está afectado por el bug de la Nube™ en ese momento y no recibe la petición? ¡Aquí empieza el cotilleo! La máquina 1 que recibió inicialmente la petición tiene que hacer algo con la petición. Podría levantar una máquina nueva que se encargase de todos los usuarios que tenía asignados la máquina 2 y luego lanzar el mensaje de «cambiar máquina 2 por máquina 3 para todos los usuarios», pero como sabemos que el bug de la Nube™ es una cosa muy temporal vamos a optar porque en ese caso la maquina 1 se asigne a si misma la petición. Pero claro, una vez que se empiece a hacer ella cargo de ese usuario es necesario que el resto de servidores se enteren para que actualicen sus tablas hash internas. Como en nuestro caso no tenemos muchísimas máquinas, será la propia máquina 1 la que informe a todas las máquinas que tiene en su lista, aunque nos dejamos una nota mental para que si el número de servidores aumenta mucho lo cambiemos para que cada máquina se lo cuente a otras dos y así la actualización de las tablas sea mucho más rápida.

Con este sistema, en el que las máquinas hablan entre ellas para contarse las novedades, consigues que cada una tenga su propia foto de la situación actual y pueda decidir como reaccionar y que hacer con cada petición.

Ahora sí, ya tienes tu sistema funcionando a tope, no hay nada raro en las estadísticas así que, al menos por ahora, puedes descansar tranquilo.

Post By Javi López (27 Posts)

Arquitecto/desarrollador, creativo, buscador de nuevas soluciones y modelos de negocio, crítico constructivo y ex muchas cosas

Website: → JaviLopezG

Connect

cloud, nube, Patrones, protocolos gossip