Solid Cable: escalando WebSockets
O curso acompanha um broadcast do Turbo pelo Solid Cable, o adapter de pub/sub apoiado em banco. Mostra que broadcast_refresh_to é uma escrita síncrona, sem fila, e como a tabela solid_cable_messages guarda cada mensagem com um hash de canal de 64 bits com sinal. Trata da thread listener que consulta linhas novas, das suas duas marcas d'água e do semáforo de desligamento. Explica a loteria de limpeza que apaga linhas vencidas, por que o custo de consulta cresce com o número de processos e como ler uma tabela viva como evidência.
O que você vai aprender
- ✓Como o broadcast_refresh_to grava de forma síncrona pelo Action Cable, sem fila
- ✓A tabela única solid_cable_messages e o hash SHA256 de canal com sinal
- ✓Como a thread listener consulta, acompanha marcas d'água e desliga com segurança
- ✓Como a loteria de limpeza apaga mensagens vencidas durante os broadcasts
- ✓Por que o custo de consulta cresce com o número de processos do servidor
- ✓Como ler contagem de linhas e intervalo de ids numa tabela de cable viva
broadcast_refresh_to é uma escrita síncrona
Três arquivos desta aplicação chamam a mesma linha. Admin::Catalog::SaveCourseService, Admin::Catalog::ReorderCourseService e Admin::Catalog::ReorderLessonService terminam com Turbo::StreamsChannel.broadcast_refresh_to("catalog_roadmap"), e app/views/catalog/courses/index.html.erb abre com <%=…
Ler a aula completa grátis →Currículo
7 aulasbroadcast_refresh_to é uma escrita síncrona
O broadcast_refresh_to envia uma tag de refresh de 45 caracteres pelo Action Cable de forma síncrona, sem fila nem canal próprio.
Uma tabela, um canal com hash, e um insert cru
O Solid Cable guarda mensagens numa única tabela, converte canais em inteiros de 64 bits com sinal e grava com insert.
O listener: uma thread que só lê
Uma thread listener por processo consulta linhas novas, acompanha duas marcas d'água e usa um semáforo para desligar com segurança.
A loteria do trim: dois por cento de chance por broadcast
Cada broadcast roda o TrimJob na hora, e em cerca de 2% das vezes ele apaga até 100 linhas vencidas.
Polling é um custo por processo, não por thread
Threads listener crescem com processos Puma, então as consultas aumentam com o WEB_CONCURRENCY, seja qual for o volume de mensagens.
Os números reais desta aplicação: uma tabela de cable, totalmente atrasada pra um trim
Uma tabela de cable de desenvolvimento cheia de linhas vencidas mostra que a limpeza só acontece quando há broadcasts.
Juntando tudo: um refresh, dois processos, uma tabela
O rastro de um broadcast: escrita síncrona, loteria de limpeza, consulta por processo e o GET do navegador.