AVISO: esta série é uma fantasia satírica baseada em fatos reais sobre Elixir. Nada aqui deve ser levado ao pé da letra. Ao final de cada capítulo, os fatos por trás da lenda são revelados. Tags: #satire #humor #elixir #enchiridium
Elixir Enchiridium — Tomo VI: A Batalha
Capítulos 21 a 45
Capítulo 21 — :pg: O Grupo de Processos que Atravessa Nós
A lenda diz que o :pg é um grupo de processos. Mas não é um grupo comum. É um grupo que atravessa nós. Você entra no grupo. Outros processos entram no grupo. Todos se conhecem. Todos se falam. Se um morre, o grupo sente falta. Se um nasce, o grupo dá boas-vindas. O grupo nunca se desfaz. O grupo nunca se perde.
A verdade é que o módulo pg implementa grupos de processos distribuídos e nomeados. Uma mensagem pode ser enviada para um, alguns ou todos os membros do grupo. Um grupo de processos pode ser acessado por um nome comum. Por exemplo, se existe um grupo chamado foobar, pode haver um conjunto de processos (que podem estar localizados em nós diferentes) que são todos membros do grupo foobar. Não há funções especiais para enviar uma mensagem ao grupo. Em vez disso, funções cliente devem ser escritas com get_members/1 e get_local_members/1 para determinar quais processos são membros do grupo. Se um membro termina, ele é automaticamente removido do grupo. Process Groups implementam strong eventual consistency. A visão de associação do grupo pode divergir temporariamente. Por exemplo, quando processos em node1 e node2 entram concorrentemente, node3 e node4 podem receber atualizações em ordem diferente. Grupos são automaticamente criados quando qualquer processo entra, e removidos quando todos os processos saem.
A lenda diz que, na primeira vez que um programador usou :pg, ele perguntou: "Onde está o grupo?" O instrutor respondeu: "Em todo lugar. E em lugar nenhum. É distribuído."
O fato por trás da lenda: O módulo pg implementa grupos de processos distribuídos e nomeados. Uma mensagem pode ser enviada para um, alguns ou todos os membros do grupo. Process Groups implementam strong eventual consistency. Grupos são automaticamente criados quando qualquer processo entra, e removidos quando todos saem.
Gancho: O grupo atravessa nós. Mas há uma coisa que distribui processos pelo cluster: o Swarm.
Capítulo 22 — Swarm: O Enxame que Distribui Processos
A lenda diz que o Swarm é um enxame. Ele distribui processos pelo cluster. Ele usa hash consistente. Ele move processos quando nós entram ou saem. Ele nunca deixa um nó sobrecarregado. Ele nunca deixa um processo órfão.
A verdade é que Swarm é tanto um registro global distribuído, como gproc, quanto um utilitário de clustering. Ele foi projetado para o caso de uso onde grandes números de processos persistentes são criados para coisas como dispositivos, e são únicos através de um cluster de nós Erlang, e mensagens devem ser roteadas para esses processos, tanto individualmente quanto em grupos. Swarm distribui esses processos uniformemente pelo cluster com base em um algoritmo de hashing consistente, e automaticamente move processos em resposta a mudanças de topologia do cluster ou quedas de nós. Ele favorece disponibilidade sobre consistência, e é eventualmente consistente. Partições de rede resultam em todas as partições executando uma instância de processos criados com Swarm.
A lenda diz que, na primeira vez que um programador usou Swarm, ele perguntou: "Como os processos se movem?" O instrutor respondeu: "Pelo hash consistente. E pela magia do enxame."
O fato por trás da lenda: Swarm é um registro global distribuído e utilitário de clustering. Distribui processos uniformemente com hashing consistente. Favorece disponibilidade sobre consistência. Partições de rede resultam em múltiplas instâncias de processos.
Gancho: O enxame distribui. Mas há uma coisa que gerencia grupos: o Syn.
Capítulo 23 — Syn: O Sinônimo que Registra Tudo
A lenda diz que o Syn é um sinônimo. Ele registra processos. Ele gerencia grupos. Ele lida com partições de rede. Ele recupera. Ele é escalável. Ele é global. Ele nunca perde um registro. Ele nunca deixa um grupo vazio.
A verdade é que Syn (abreviação de synonym) é um registro global de processos e gerenciador de grupos de processos para Erlang e Elixir. Syn gerencia automaticamente a adição e remoção de nós do cluster, e também é capaz de recuperar de partições de rede. Um registro global de processos permite registrar um processo em todos os nós de um cluster com uma única chave. Um grupo global de processos é um grupo nomeado que contém muitos processos, possivelmente rodando em nós diferentes. Syn é eventualmente consistente — disponibilidade foi escolhida sobre consistência.
A lenda diz que, na primeira vez que um programador usou Syn, ele perguntou: "O que é um sinônimo?" O instrutor respondeu: "É um nome que vale para todos os nós."
O fato por trás da lenda: Syn é um registro global de processos e gerenciador de grupos de processos. Gerencia adição/remoção de nós e recupera de partições de rede. Eventualmente consistente. Disponibilidade sobre consistência.
Gancho: O sinônimo registra. Mas há uma coisa que usa consenso: o RaRegistry.
Capítulo 24 — RaRegistry: O Registro que Usa Consenso
A lenda diz que o RaRegistry é um registro. Mas não é um registro comum. Ele usa consenso. Ele usa Raft. Ele é consistente. Ele é distribuído. Ele é otimizado para consistência, não para performance bruta. Ele nunca mente. Ele nunca diverge.
A verdade é que RaRegistry é um registro distribuído para GenServers Elixir usando Ra (a implementação Raft do RabbitMQ). Ele funciona como um registro normal, mas com consenso distribuído via Ra, tornando-o adequado para aplicações distribuídas em múltiplos nós. RaRegistry é otimizado para consistência distribuída em vez de performance bruta. O registro embutido do Elixir é local, mas RaRegistry é distribuído.
A lenda diz que, na primeira vez que um programador usou RaRegistry, ele perguntou: "Por que é mais lento?" O instrutor respondeu: "Porque ele garante consistência. E consistência custa."
O fato por trás da lenda: RaRegistry é um registro distribuído usando Ra (Raft). Otimizado para consistência distribuída em vez de performance bruta.
Gancho: O registro consensual existe. Mas há uma coisa que usa gossip: o PgRegistry.
Capítulo 25 — PgRegistry: O Registro que Fofoca
A lenda diz que o PgRegistry é um registro. Mas não é um registro comum. Ele fofoca. Ele usa gossip para replicar entradas pelo cluster. Ele é eventualmente consistente. Ele tem metadados por entrada. Ele é cluster-aware. Ele nunca fica desatualizado por muito tempo.
A verdade é que PgRegistry é um registro de processos distribuído e cluster-aware para Elixir com metadados por entrada. Ele fornece uma interface semelhante ao Registry do Elixir, mas descobre processos através de um cluster. Entradas são replicadas pelo cluster através de membership eventualmente consistente baseada em gossip, o mesmo modelo do módulo pg do Erlang.
A lenda diz que, na primeira vez que um programador usou PgRegistry, ele perguntou: "O que é gossip?" O instrutor respondeu: "É como fofoca. Um nó conta para o outro. E a notícia se espalha."
O fato por trás da lenda: PgRegistry é um registro distribuído cluster-aware com metadados por entrada. Replicação via gossip eventualmente consistente, o mesmo modelo do pg.
Gancho: O registro fofoca. Mas há uma coisa que gerencia clusters no Kubernetes: o ClusterHelper.
Capítulo 26 — ClusterHelper: O Mapa de Papéis do Cluster
A lenda diz que o ClusterHelper é um mapa. Ele mapeia papéis. Cada nó tem um papel: :data, :web, :cache. Outros nós entram no cluster e descobrem quem tem cada papel. O mapa nunca mente. O mapa nunca se perde.
A verdade é que ClusterHelper é uma biblioteca que ajuda a gerenciar clusters dinâmicos Elixir em ambientes como Kubernetes. Cada nó tem papéis como :data, :web, :cache, e outros nós que entram no cluster podem facilmente obter nós por papel. A biblioteca mapeia papel (ou ID, se necessário) para o nome do nó Elixir em runtime. Se um nó entra no cluster, ele atualiza automaticamente o papel do nó para os outros nós.
A lenda diz que, na primeira vez que um programador usou ClusterHelper, ele perguntou: "Como outros nós me encontram?" O instrutor respondeu: "Pelo papel. Você é :web. Eles te encontram."
O fato por trás da lenda: ClusterHelper gerencia clusters dinâmicos em Kubernetes. Mapeia papéis (:data, :web, :cache) para nomes de nós. Atualiza automaticamente quando nós entram.
Gancho: O mapa mapeia. Mas há uma coisa que forma clusters via Kubernetes API: o Galaxy.
Capítulo 27 — Galaxy: A Galáxia de Nós
A lenda diz que o Galaxy é uma galáxia. Ele forma clusters. Ele usa a API do Kubernetes. Ele consulta nós por label selector. Ele usa basename. Ele nunca perde um nó. Ele nunca deixa um nó sozinho no espaço.
A verdade é que Galaxy é uma biblioteca que fornece um mecanismo para formar automaticamente clusters de nós Erlang, com associação de nós estática ou dinâmica. Ele suporta Kubernetes via sua API de metadados, usando um label selector configurável e node basename. Galaxy.Kubernetes usa a API de metadados do Kubernetes para consultar nós com base em um label selector e basename.
A lenda diz que, na primeira vez que um programador usou Galaxy, ele perguntou: "Como ele encontra os nós?" O instrutor respondeu: "Pela API do Kubernetes. E pelo basename."
O fato por trás da lenda: Galaxy forma clusters Erlang automaticamente. Suporta Kubernetes via API de metadados, usando label selector e node basename.
Gancho: A galáxia forma. Mas há uma coisa que usa DNS: o Libcluster com Kubernetes.
Capítulo 28 — Libcluster Kubernetes: O Feitiço que Usa a API do Kubernetes
A lenda diz que o Libcluster tem uma estratégia para Kubernetes. Ele usa a API de metadados do Kubernetes. Ele consulta nós por label selector e basename. Ele também tem uma estratégia DNS que usa DNS para juntar nós sob um headless service em um namespace.
A verdade é que Libcluster suporta Kubernetes via sua API de metadados usando um label selector configurável e node basename. Alternativamente, ele suporta Kubernetes.DNS, que usa DNS para juntar nós sob um headless service em um dado namespace. A estratégia Cluster.Strategy.Kubernetes usa a API de metadados do Kubernetes para consultar nós com base em um label selector e basename.
A lenda diz que, na primeira vez que um programador usou Libcluster com Kubernetes, ele perguntou: "Como ele encontra os pods?" O instrutor respondeu: "Pelo label selector. E pelo basename."
O fato por trás da lenda: Libcluster suporta Kubernetes via API de metadados (label selector e basename) e Kubernetes.DNS (headless service).
Gancho: O feitiço encontra. Mas há uma coisa que autentica os nós: o cookie.
Capítulo 29 — O Cookie: O Segredo que Nunca é Enviado em Claro
A lenda diz que o cookie é um segredo. Ele nunca é enviado em claro. Ele nunca é transmitido. Ele é usado em um desafio-resposta. O cliente prova que conhece o cookie. O servidor verifica. Se o digest bater, a conexão é permitida. Se não, é negada. O cookie é a senha. O cookie é a lei.
A verdade é que o cookie é usado para autenticar a distribuição Erlang. Os cookies nunca são enviados em claro, e o procedimento de handshake espera que o cliente (chamado A) seja o primeiro a provar que pode gerar um digest suficiente. O digest é um hash MD5 de 16 bytes do Challenge (como texto) concatenado com o cookie (como texto). Os cookies são strings de texto que podem ser vistas como senhas. O valor do cookie não é transmitido na rede (um mecanismo de desafio/resposta é usado), mas nenhuma proteção está em vigor contra um ataque ativo (man-in-the-middle).
A lenda diz que, na primeira vez que um programador perguntou "O cookie é seguro?", o instrutor respondeu: "Ele é uma senha. Mas não é criptografia. Use TLS."
O fato por trás da lenda: O cookie autentica a distribuição Erlang via desafio-resposta. Nunca é enviado em claro. Mas não há proteção contra man-in-the-middle. Use TLS para segurança.
Gancho: O cookie autentica. Mas há uma coisa que protege a conexão: o TLS.
Capítulo 30 — Distribuição sobre TLS: A Armadura da BEAM
A lenda diz que a distribuição sobre TLS é uma armadura. Ela protege a conexão. Ela criptografa. Ela autentica. Ela usa certificados. Ela usa cookies. Ela nunca deixa um intruso entrar. Ela nunca deixa uma mensagem ser lida.
A verdade é que Erlang Distribution over TLS permite que todas as conexões de distribuição usem TLS. Todos os nós Erlang participantes em um sistema distribuído devem usar este módulo de distribuição. O nível de segurança depende dos parâmetros fornecidos à configuração da conexão TLS. No entanto, os cookies de nó Erlang são sempre usados, pois podem ser usados para diferenciar entre duas redes Erlang diferentes.
A lenda diz que, na primeira vez que um programador ativou TLS, ele perguntou: "Agora está seguro?" O instrutor respondeu: "Agora está mais seguro. Mas o cookie ainda é usado."
O fato por trás da lenda: Erlang Distribution over TLS criptografa conexões de distribuição. Cookies ainda são usados para diferenciar redes Erlang. O nível de segurança depende dos parâmetros TLS.
Gancho: A armadura protege. Mas há uma coisa que ninguém vê: o EPMD.
Capítulo 31 — EPMD: O Cartório dos Nós que Ninguém Vê
A lenda diz que o EPMD é um cartório. Ele mapeia nomes de nós para portas. Ele fica rodando na sombra. Ele nunca aparece. Ele nunca reclama. Ele só registra. Ele só responde. Sem ele, os nós não se encontram. Sem ele, a distribuição não funciona.
A verdade é que EPMD (Erlang Port Mapper Daemon) é o serviço que mapeia nomes de nós para portas. Ele é iniciado automaticamente quando um nó é iniciado. Ele é um ponto de falha conhecido: se o EPMD cair, os nós não conseguem se conectar. Ele também é um vetor de segurança: se alguém puder se conectar ao EPMD, pode descobrir todos os nós do cluster.
A lenda diz que, na primeira vez que um programador perguntou "O que é EPMD?", o instrutor respondeu: "É o cartório. E o cartório fica na sombra."
O fato por trás da lenda: EPMD mapeia nomes de nós para portas. É iniciado automaticamente. É um ponto de falha e um vetor de segurança.
Gancho: O cartório registra. Mas há uma coisa que oferece uma alternativa à distribuição totalmente conectada: o Partisan.
Capítulo 32 — Partisan: A Alternativa à Distribuição Totalmente Conectada
A lenda diz que o Partisan é uma alternativa. Ele não usa a distribuição totalmente conectada do Erlang. Ele usa topologias de rede alternativas. Ele é mais escalável. Ele é mais configurável. Ele é mais complexo. Ele nunca substitui a BEAM. Ele apenas a complementa. A distribuição Erlang totalmente conectada requer O(n) conexões TCP/IP ativas, o que induz tráfego de rede significativo acima de 40 nós.
A verdade é que Partisan é uma biblioteca que fornece uma alternativa à distribuição Erlang nativa, com foco em escalabilidade e configurabilidade. Ele foi criado para resolver alguns dos problemas da distribuição totalmente conectada do Erlang, que pode se tornar um gargalo em clusters grandes. Partisan oferece diferentes topologias de rede e estratégias de comunicação. Libcluster pode suportar projetos como Partisan através de callbacks.
A lenda diz que, na primeira vez que um programador ouviu falar de Partisan, ele perguntou: "Por que não usar a distribuição nativa?" O instrutor respondeu: "Porque ela não escala para 100 nós."
O fato por trás da lenda: Partisan é uma alternativa à distribuição Erlang nativa, focada em escalabilidade e configurabilidade. A distribuição totalmente conectada requer O(n) conexões TCP/IP, um gargalo acima de 40 nós.
Gancho: A alternativa existe. Mas há uma coisa que testa partições: o Schism.
Capítulo 33 — Schism: O Feiticeiro que Parte a Rede (Parte 2)
A lenda diz que o Schism é um feiticeiro. Ele parte a rede. Ele simula netsplits. Ele testa partições. Ele usa um truque com cookies. Ele nunca erra. Ele nunca deixa uma partição passar despercebida. Ele é usado em conjunto com ferramentas como local_cluster e propcheck.
A verdade é que Schism é uma ferramenta de teste de partição para Elixir. Ele fornece uma API simples para testar partições entre nós BEAM. O motivo de existência do Schism é testar netsplits entre BEAMs de forma rápida e fácil, e ele usa um truque rudimentar com cookies para atingir esse objetivo. Schism é usado em conjunto com ferramentas como local_cluster e propcheck.
A lenda diz que, na primeira vez que um programador usou Schism, ele perguntou: "O que é um netsplit?" O instrutor respondeu: "É quando a rede se parte ao meio. E o Schism te ajuda a testar isso."
O fato por trás da lenda: Schism é uma ferramenta de teste de partição para Elixir. Usa um truque com cookies. Usado com local_cluster e propcheck.
Gancho: O feiticeiro parte. Mas há uma coisa que lida com partições: o global.
Capítulo 34 — O Módulo global: O Cartório dos Nomes Distribuídos (Parte 2)
A lenda diz que o módulo global é um cartório. Ele registra nomes. Ele notifica todos os nós. Ele monitora nós. Ele mantém a rede totalmente conectada. Ele é o cartório dos nomes distribuídos. Ele nunca perde um nome. Ele nunca deixa um nó sozinho. A partir do OTP 25, ele previne partições sobrepostas devido a problemas de rede, desconectando ativamente de nós que relatam ter perdido conexões com outros nós.
A verdade é que o módulo global fornece registro de nomes globalmente distribuído. Ele consiste em serviços para: registro global de nomes, monitoramento de nós, e manutenção da rede totalmente conectada. Esses serviços são controlados através do processo global, que existe em cada nó. O global é iniciado automaticamente quando um nó é iniciado. A partir do OTP 25, o global irá, por padrão, prevenir partições sobrepostas devido a problemas de rede, desconectando ativamente de nós que relatam ter perdido conexões com outros nós.
A lenda diz que, na primeira vez que um programador usou global, ele perguntou: "Onde está o nome?" O instrutor respondeu: "No cartório. E o cartório está em todo lugar."
O fato por trás da lenda: O módulo global fornece registro de nomes globalmente distribuído. A partir do OTP 25, previne partições sobrepostas desconectando ativamente nós que perderam conexões.
Gancho: O cartório registra. Mas há uma coisa que supervisiona processos distribuídos: o Pogo.
Capítulo 35 — Pogo: O Supervisor que Pula de Nó em Nó
A lenda diz que o Pogo é um supervisor. Mas não é um supervisor comum. Ele pula de nó em nó. Ele usa :pg por baixo dos panos. Ele mantém o estado do cluster. Ele coordena o trabalho entre supervisores locais. Ele automaticamente escolhe um nó para supervisionar um processo filho. Ele nunca deixa um processo órfão.
A verdade é que Pogo é um supervisor distribuído para aplicações Elixir em cluster. Ele usa grupos de processos nomeados distribuídos (:pg) por baixo dos panos para manter o estado do cluster e coordenar o trabalho entre supervisores locais rodando em nós diferentes. Ele automaticamente escolhe um nó para supervisionar localmente um processo filho. Um processo filho rodando no cluster pode ser iniciado ou parado usando qualquer supervisor local. Pogo tem cerca de 98 estrelas no GitHub.
A lenda diz que, na primeira vez que um programador usou Pogo, ele perguntou: "Como ele escolhe o nó?" O instrutor respondeu: "Pelo :pg. E pela magia do Pogo."
O fato por trás da lenda: Pogo é um supervisor distribuído que usa :pg para manter o estado do cluster. Escolhe automaticamente um nó para supervisionar processos. Cerca de 98 estrelas no GitHub.
Gancho: O supervisor pula. Mas há uma coisa que usa :pg como registro: o DistributedSupervisor.
Capítulo 36 — DistributedSupervisor: O Supervisor que Usa :pg como Registro
A lenda diz que o DistributedSupervisor é um supervisor. Mas não é um supervisor comum. Ele usa :pg como registro. Ele é um DynamicSupervisor que funciona transparentemente em um ambiente distribuído. Ele distribui processos entre nós conectados. Ele redistribui processos quando nós entram ou saem. Ele oferece seleção/atribuição de nó por processo. Ele nunca deixa um processo preso.
A verdade é que distributed_supervisor é um dynamic supervisor especializado projetado para funcionar transparentemente em ambientes Erlang/Elixir distribuídos. Ele estende a funcionalidade do DynamicSupervisor embutido do Elixir adicionando distribuição automática de processos entre nós conectados, redistribuição de processos quando nós entram ou saem do cluster, capacidades de seleção/atribuição de nó por processo, e tolerância a falhas com recuperação automática entre nós. Ele usa :pg como registro.
A lenda diz que, na primeira vez que um programador usou DistributedSupervisor, ele perguntou: "O que é isso?" O instrutor respondeu: "É um supervisor que usa :pg como registro. E distribui processos."
O fato por trás da lenda: DistributedSupervisor é um dynamic supervisor especializado para ambientes distribuídos. Usa :pg como registro. Oferece distribuição automática, redistribuição, seleção de nó e recuperação.
Gancho: O supervisor distribui. Mas há uma coisa que garante que um processo rode exatamente uma vez: o Chosen.
Capítulo 37 — Chosen: O Supervisor que Roda Exatamente Uma Vez
A lenda diz que o Chosen é um supervisor. Mas não é um supervisor comum. Ele garante que um processo rode exatamente uma vez em todo o cluster. Ele não precisa de clustering BEAM. Ele usa advisory locks do PostgreSQL. Ele é o supervisor singleton. Ele nunca deixa dois processos rodarem ao mesmo tempo.
A verdade é que Chosen é um supervisor singleton distribuído baseado em advisory locks do PostgreSQL. Ele garante que um processo ou supervisor rode exatamente uma vez em todo o cluster. Ele não requer clustering BEAM. Chosen é ideal para casos onde você precisa de um processo singleton mas não quer configurar clustering BEAM.
A lenda diz que, na primeira vez que um programador usou Chosen, ele perguntou: "Como ele garante que só um rode?" O instrutor respondeu: "Pelo advisory lock. E pela magia do PostgreSQL."
O fato por trás da lenda: Chosen é um supervisor singleton distribuído baseado em advisory locks do PostgreSQL. Garante que um processo rode exatamente uma vez. Não requer clustering BEAM.
Gancho: O supervisor escolhe. Mas há uma coisa que fornece uma alternativa: o Sworm.
Capítulo 38 — Sworm: O Híbrido de Supervisor e Registro
A lenda diz que o Sworm é um híbrido. Ele combina o DynamicSupervisor e o Registry do Horde. Ele reproduz a biblioteca Swarm. Ele mantém um diretório CRDT global do cluster. Ele rastreia em qual nó cada tipo de Sworm roda. Ele nunca perde um registro. Ele nunca deixa um nó sozinho.
A verdade é que Sworm é uma combinação de um registro de processos global e distribuído e um supervisor, reunidos em uma API amigável. Sworm combina os módulos Horde.DynamicSupervisor e Horde.Registry para reproduzir a biblioteca Swarm. Sworm mantém um diretório CRDT global do cluster de Sworms registrados, rastreando em qual nó cada tipo de Sworm roda.
A lenda diz que, na primeira vez que um programador usou Sworm, ele perguntou: "O que é isso?" O instrutor respondeu: "É o Swarm, mas com Horde por baixo."
O fato por trás da lenda: Sworm combina Horde.DynamicSupervisor e Horde.Registry. Mantém um diretório CRDT global. Rastreia em qual nó cada tipo de Sworm roda.
Gancho: O híbrido combina. Mas há uma coisa que oferece um registro distribuído com metadados: o PgRegistry.
Capítulo 39 — PgRegistry: O Registro com Metadados (Parte 2)
A lenda diz que o PgRegistry é um registro. Mas não é um registro comum. Ele tem metadados por entrada. Ele é cluster-aware. Ele usa gossip. Ele é eventualmente consistente. Ele descobre processos através do cluster. Ele nunca perde uma entrada.
A verdade é que PgRegistry é um registro de processos distribuído e cluster-aware para Elixir com metadados por entrada. Ele fornece uma interface semelhante ao Registry do Elixir, mas descobre processos através de um cluster. Entradas são replicadas pelo cluster através de membership eventualmente consistente baseada em gossip, o mesmo modelo do módulo pg do Erlang. PgRegistry é um registro de chaves duplicadas, cluster-aware.
A lenda diz que, na primeira vez que um programador usou PgRegistry, ele perguntou: "O que são metadados?" O instrutor respondeu: "São informações extras. E o PgRegistry as guarda."
O fato por trás da lenda: PgRegistry é um registro distribuído cluster-aware com metadados por entrada. Replicação via gossip eventualmente consistente. Registro de chaves duplicadas.
Gancho: O registro guarda. Mas há uma coisa que usa Raft: o Ragistry.
Capítulo 40 — Ragistry: O Registro que Usa Raft
A lenda diz que o Ragistry é um registro. Mas não é um registro comum. Ele usa Ra. Ele usa Raft. Ele é consistente. Ele é distribuído. Ele é work-in-progress. Ele nunca mente. Ele nunca diverge.
A verdade é que Ragistry é um sistema de registro de processos distribuído Elixir construído sobre a implementação Ra do Raft. Ele funciona através de um cluster de nós. Ragistry é um work-in-progress.
A lenda diz que, na primeira vez que um programador usou Ragistry, ele perguntou: "Por que é work-in-progress?" O instrutor respondeu: "Porque Raft é difícil. E o Ragistry está aprendendo."
O fato por trás da lenda: Ragistry é um sistema de registro de processos distribuído construído sobre Ra (Raft). É um work-in-progress.
Gancho: O registro consensual existe. Mas há uma coisa que oferece uma alternativa à distribuição nativa: o Partisan.
Capítulo 41 — Partisan (Parte 2): A Alternativa que Escala
A lenda diz que o Partisan é uma alternativa. Ele não usa a distribuição nativa do Erlang. Ele usa topologias de rede alternativas. Ele é mais escalável. Ele é mais configurável. Ele é mais complexo. Ele nunca substitui a BEAM. Ele apenas a complementa. A distribuição Erlang totalmente conectada requer O(n) conexões TCP/IP ativas, o que induz tráfego de rede significativo acima de 40 nós.
A verdade é que Partisan é uma biblioteca que fornece uma alternativa à distribuição Erlang nativa, com foco em escalabilidade e configurabilidade. Ele foi criado para resolver alguns dos problemas da distribuição totalmente conectada do Erlang, que pode se tornar um gargalo em clusters grandes. Partisan oferece diferentes topologias de rede e estratégias de comunicação. Libcluster pode suportar projetos como Partisan através de callbacks.
A lenda diz que, na primeira vez que um programador ouviu falar de Partisan, ele perguntou: "Por que não usar a distribuição nativa?" O instrutor respondeu: "Porque ela não escala para 100 nós."
O fato por trás da lenda: Partisan é uma alternativa à distribuição Erlang nativa, focada em escalabilidade e configurabilidade. A distribuição totalmente conectada requer O(n) conexões TCP/IP, um gargalo acima de 40 nós.
Gancho: A alternativa existe. Mas há uma coisa que sempre foi o desafio: a partição de rede.
Capítulo 42 — Net Splits: A Emboscada que Ninguém Vê (Parte 2)
A lenda diz que os net splits são emboscadas. A rede se parte. Os nós ficam presos em lados opostos. Cada lado acha que o outro morreu. Cada lado reinicia seus processos. Quando a rede volta, há dois exércitos de processos. A batalha é sangrenta. A batalha é confusa. A batalha é a pior parte de ser distribuído.
A verdade é que lidar com net splits é um dos maiores desafios de sistemas distribuídos. A natureza da distribuição Erlang torna net splits parciais um problema não solucionável com o mecanismo nativo, e a única forma de mitigar é usar ferramentas como Partisan. Em caso de partição de rede, cada partição reinicia os processos que estavam rodando na outra parte, assumindo que aquela parte está caída. Quando a partição é curada, pode haver múltiplas instâncias do mesmo processo rodando. Para prevenir que duas instâncias do mesmo processo permaneçam rodando após a cura de um netsplit, você precisa registrar cada processo filho com um nome único.
A lenda diz que, na primeira vez que um programador viu um net split, ele perguntou: "O que aconteceu?" O instrutor respondeu: "A rede se partiu. E agora há dois de tudo."
O fato por trás da lenda: Net splits parciais são um problema não solucionável com a distribuição Erlang nativa. Ferramentas como Partisan ajudam a mitigar. Quando a partição é curada, pode haver múltiplas instâncias do mesmo processo.
Gancho: A emboscada é real. Mas há uma coisa que ajuda a lidar com ela: o global_supervisor.
Capítulo 43 — GlobalSupervisor: O General que Reinicia os Processos (Parte 2)
A lenda diz que o global_supervisor é um general. Ele supervisiona processos. Mas não é um supervisor comum. Ele distribui processos pelo cluster. Em caso de partição de rede, cada partição reinicia os processos da outra parte. Quando a partição é curada, ele verifica se há duplicatas. Se houver, ele mata uma. O general nunca deixa dois exércitos iguais.
A verdade é que global_supervisor é um supervisor que distribui dinamicamente os filhos pelo cluster. Em caso de partição de rede, cada partição reinicia os processos filhos que estavam rodando na outra parte, assumindo que aquela parte está caída. Uma vez que a partição é curada, pode haver múltiplas instâncias do mesmo filho rodando. Para prevenir que duas instâncias do mesmo filho permaneçam rodando após a cura de um netsplit, você precisa registrar cada processo filho com um nome único.
A lenda diz que, na primeira vez que um programador usou global_supervisor, ele perguntou: "E se houver dois?" O instrutor respondeu: "O general mata um."
O fato por trás da lenda: global_supervisor distribui filhos pelo cluster. Em caso de partição, cada partição reinicia os processos da outra. Após a cura, pode haver múltiplas instâncias. Registrar cada filho com nome único previne duplicatas.
Gancho: O general comanda. Mas há uma coisa que conecta tudo: o PubSub.
Capítulo 44 — Phoenix.PubSub Distribuído: O Megafone que Atravessa Oceanos (Parte 2)
A lenda diz que o Phoenix.PubSub é um megafone. Mas não é um megafone comum. Ele atravessa oceanos. Ele conecta nós. Ele transmite mensagens para todos os processos inscritos, não importa em qual nó eles estejam. O megafone nunca falha. O megafone nunca se perde.
A verdade é que Phoenix.PubSub é um serviço de Publisher/Subscriber em tempo real. Ele foi projetado para ser flexível e suportar múltiplos backends. Há dois backends oficialmente suportados. Phoenix.PubSub permite que desenvolvedores realizem dispatch customizado passando um módulo dispatcher, que é responsável pelas entregas locais de mensagens. Ele é usado pelo Phoenix para transmitir atualizações do LiveView. Em um cluster, o PubSub distribui mensagens entre os nós usando a distribuição Erlang.
A lenda diz que, na primeira vez que um programador usou PubSub em cluster, ele perguntou: "Como a mensagem chegou lá?" O instrutor respondeu: "Pelo megafone. E o megafone tem alcance global."
O fato por trás da lenda: Phoenix.PubSub é um serviço de Publisher/Subscriber em tempo real. Suporta múltiplos backends. Distribui mensagens entre nós em cluster.
Gancho: O megafone transmite. Mas há uma coisa que registra presenças: o Phoenix.Presence.
Capítulo 45 — Phoenix.Presence Distribuído: O Vigia que Vê Tudo (Parte 2)
A lenda diz que o Phoenix.Presence é um vigia. Ele vê quem está online. Ele vê quem entrou. Ele vê quem saiu. Ele replica essa informação para todos os nós. Se um nó cai, os outros sentem falta. Se um nó volta, os outros dão boas-vindas. O vigia nunca dorme. O vigia nunca esquece.
A verdade é que Phoenix.Presence fornece rastreamento de presença para processos e canais. É um behaviour que fornece recursos como buscar presenças para um tópico e lidar com diffs de eventos de join e leave em tempo real. Usar este módulo define um supervisor e permite que o módulo chamador implemente o behaviour Phoenix.Tracker, que inicia um processo tracker para lidar com informações de presença. Presence.track registra o processo do canal como presença para o ID do usuário do socket, com um mapa de metadados. Em cluster, Presence usa PubSub para replicar informações de presença entre nós.
A lenda diz que, na primeira vez que um programador usou Presence em cluster, ele perguntou: "Como isso funciona?" O instrutor respondeu: "PubSub."
O fato por trás da lenda: Phoenix.Presence fornece rastreamento de presença para processos e canais. Define um supervisor e usa Phoenix.Tracker com Phoenix.PubSub para broadcast de atualizações de presença.
Gancho: O vigia vê. Mas há uma coisa que coordena transações: o :global.
Epílogo Parcial do Tomo VI
Quarenta e cinco capítulos. Uma batalha. Mil processos. E um brasileiro que ouviu um sussurro.
Este foi o Tomo VI — A Batalha, com fatos verificados. Ainda faltam 55 capítulos para completar este tomo. Nos próximos, vamos explorar: Distributed Erlang nativo, :pg2 (depreciado), segurança em distribuição, clustering com Kubernetes, e muitos outros tópicos.
Até lá.
Agora, sério: A distribuição no BEAM é embutida no runtime. O módulo pg implementa grupos de processos distribuídos. Swarm distribui processos com hashing consistente. Syn gerencia registro e grupos. RaRegistry usa Ra (Raft). PgRegistry usa gossip. ClusterHelper mapeia papéis. Galaxy usa Kubernetes API. Libcluster suporta Kubernetes. O cookie autentica via desafio-resposta. TLS criptografa a distribuição. EPMD mapeia nomes para portas. Partisan oferece uma alternativa à distribuição totalmente conectada. Schism testa netsplits. O módulo global previne partições sobrepostas no OTP 25. Pogo é um supervisor distribuído. DistributedSupervisor usa :pg como registro. Chosen é um supervisor singleton via PostgreSQL. Sworm combina Horde. Ragistry usa Ra. Net splits são um problema não solucionável. global_supervisor lida com partições. Phoenix.PubSub distribui mensagens. Phoenix.Presence rastreia presenças. As capivaras quânticas não são reais — mas deveriam ser. Este artigo é uma fantasia satírica baseada em fatos. Mantenha o aviso para não enganar ninguém.
Top comments (0)