DEV Community: Michael Alves

Cloud Spanner: tentando entender o que ele resolve e brincando com o emulador local

Michael Alves — Tue, 04 Aug 2026 02:09:43 +0000

Sumário

Por que o Spanner existe...
- Bancos relacionais
- Transações ACID
- Consistência e escalabilidade global
- Bancos NoSQL
- Distribuição pelo mundo
Como ele resolve esses problemas?
- 1. Replicação utilizando Paxos
- 2. Transações distribuídas
- 3. TrueTime
- 4. Commit Wait
Emulando o Cloud Spanner com cloud-spanner-emulator
- Conector do Spanner para Active Record
- Ferramenta para testes de carga
Conclusão
Referências

Algumas semanas atrás, fui tomado pelo tédio em relação às coisas que eu precisava estudar. Atualmente, no ano de 2026 (para você que está lendo isso no futuro), estamos vivendo o hype absoluto dos agentes de IA. Eu confesso que, apesar de também estar empolgado, testando e usando agentes de IA para trabalhar e tudo mais, eu estava à procura de outra coisa para estudar, algo que fugisse um pouco de ficar testando harnesses e ferramentas de IA, pensando em como posso usar novos agentes para escrever código, economizar tokens e blá-blá-blá.

Dito isso, juntando o útil ao agradável, já que é uma tecnologia que vou utilizar no meu trabalho, comecei a estudar sobre o Cloud Spanner, o serviço de banco de dados relacional distribuído e globalmente escalável desenvolvido pelo Google.

Por que o Spanner existe...

Lendo os artigos publicados no Google Schollar eu entendo que o Cloud Spanner nasce para responder a seguinte pergunta:

Como construir um banco de dados que funcione em vários datacenters espalhados pelo mundo sem abrir mão da consistência das transações?

Quando precisamos escolher um banco de dados para um projeto, além de considerar custos, a afinidade da equipe e os objetivos do software que sera construido, normalmente precisamos escolher entre os benefícios oferecidos por um banco de dados relacional e as características de escalabilidade e distribuição presentes em muitos bancos NoSQL.

Bancos relacionais

Os bancos de dados relacionais, como MySQL e PostgreSQL, tendem a priorizar estrutura, relacionamentos e consistência e, com isso, trazem um pacote como por exemplo as transações ACID

Transações ACID

Transações ACID são um conjunto de propriedades que garantem que as operações em um banco de dados sejam executadas de forma confiável:

O A vem de Atomicidade: ou todas as operações da transação acontecem ou nenhuma delas acontece.
O C vem de Consistência: a transação mantém o banco de dados em um estado válido, respeitando suas regras e restrições.
O I vem de Isolamento: transações concorrentes são executadas de forma isolada, evitando que uma transação interfira incorretamente no resultado de outra.
E, por fim, o D vem de Durabilidade: depois que uma transação é confirmada (COMMIT) seus dados permanecem persistidos mesmo em caso de falha.

Consistência e escalabilidade global

Em um banco de dados que oferece consistência forte, quando um dado é alterado e a transação é confirmada as leituras que vão ser executadas devem refletir essa alteração de acordo com as garantias de consistência oferecidas pelo banco de dados.

Consequentemente, a escalabilidade global de bancos relacionais tradicionais pode se tornar complicada. Isso acontece porque em um banco de dados distribuído manter a consistência forte entre servidores espalhados pelo mundo é caro e complexo.

Imagine dois servidores: um no Brasil e outro nos Estados Unidos. Se uma transação altera um dado no Brasil, o banco precisa coordenar essa alteração com os demais servidores para garantir que as réplicas mantenham as garantias de consistência esperadas. Isso pode exigir:

comunicação entre regiões, aumentando a latência;
coordenação entre servidores;
replicação síncrona, que pode reduzir o desempenho;
maior complexidade para lidar com falhas de rede e indisponibilidade de regiões.

Bancos NoSQL

E então temos os bancos de dados NoSQL. Particularmente, eu usei poucos bancos de dados desse tipo (Redis conta? kkk). Mas bancos como Bigtable, Cassandra e DynamoDB garantem uma enorme escalabilidade, pois não dependem da mesma estrutura de relacionamentos e joins entre tabelas presente nos bancos relacionais, o que pode facilitar a distribuição dos dados e a escalabilidade horizontal.

Em muitos sistemas NoSQL distribuídos, após uma alteração diferentes réplicas podem temporariamente apresentar valores diferentes, mas eventualmente convergem para o mesmo estado. Porém, essa não é uma característica obrigatória de todos os bancos NoSQL, já que alguns oferecem consistência forte ou diferentes níveis de consistência.

Distribuição pelo mundo

O Spanner foi criado justamente para tentar eliminar essa escolha.

Ele é um banco de dados realmente global e permite que um único banco esteja distribuído entre diversos datacenters ao redor do mundo, sem que a aplicação precise lidar manualmente com a replicação dos dados.

O Spanner oferece consistência forte em escala global, eu acho que esse talvez seja o maior diferencial apontado nos artigos, pois o Spanner oferece serializabilidade externa, garantindo que as transações distribuídas sejam executadas com propriedades ACID e que exista uma ordem global consistente entre as transações. Em outras palavras, mesmo com servidores em continentes diferentes, o sistema consegue manter uma visão consistente sobre a ordem em que as transações foram confirmadas.

Além disso, temos a escalabilidade automática (ou até o seu cartão de crédito aguentar $$$$$). O sistema consegue dividir os dados (sharding), mover os dados automaticamente, rebalancear a carga e distribuir e replicar os dados entre diferentes datacenters sem intervenção humana. Sim, sem intervenção humana. Isso me lembra o assunto das IAs que eu estou tentando fugir...

Como ele resolve esses problemas?

Essa imagem mostra a arquitetura de software do Spanner, mais especificamente como o sistema organiza a replicação, consenso e transações distribuídas entre diferentes datacenters.

A arquitetura é baseada em dados particionados em tablets, que são replicados por meio de grupos Paxos distribuídos entre diferentes datacenters.

Sobre essa infraestrutura, o Spanner implementa mecanismos para executar transações distribuídas e, por meio do TrueTime, consegue atribuir timestamps globalmente significativos às transações. Essas ideias trabalham em conjunto para fornecer não apenas tolerância a falhas e replicação, mas também consistência externa, fazendo com que a ordem de serialização das transações respeite a ordem em que elas realmente ocorreram.

1. Replicação utilizando Paxos

O primeiro problema é garantir que os dados continuem disponíveis e consistentes mesmo quando estão distribuídos entre várias máquinas e datacenters. O Spanner resolve isso particionando os dados em tablets e organizando cada conjunto de dados em um grupo Paxos.

Um grupo Paxos é um conjunto de réplicas que mantém uma cópia do mesmo conjunto de dados e usa o algoritmo de consenso Paxos para concordar sobre quais operações devem ser aplicadas e em qual ordem.

Cada grupo possui várias réplicas, que podem estar distribuídas geograficamente. O Paxos é responsável por fazer com que essas réplicas concordem sobre a ordem das operações realizadas naquele grupo. Dessa forma, uma falha de uma máquina ou de uma réplica não significa necessariamente a perda dos dados ou a indisponibilidade do sistema, desde que o grupo ainda consiga operar com as réplicas necessárias.

É importante falar que Paxos não resolve sozinho o problema das transações distribuídas. Ele garante consenso dentro de cada grupo de replicação. Quando uma transação precisa modificar dados pertencentes a mais de um grupo Paxos, é necessário um mecanismo adicional para coordenar esses grupos.

É aí que entram as transações distribuídas.

2. Transações distribuídas

Uma transação que acessa apenas um grupo Paxos é relativamente simples pois o próprio mecanismo de Paxos combinado com a lock table, já fornece os mecanismos necessários para a execução transacional. Porém, quando uma única transação envolve dados pertencentes a vários grupos Paxos, é necessário coordenar todos esses grupos para que a operação seja concluída de forma atômica.

Nesse cenário, o Spanner utiliza Two-Phase Commit (2PC) para coordenar os diferentes participantes da transação. Um dos grupos participantes é escolhido como coordenador, e seu Participant Leader atua como Coordinator Leader. Os demais grupos possuem seus próprios Participant Leaders, que participam do protocolo de commit.

Cada participante precisa preparar sua parte da transação. Os participantes que não são o coordenador adquirem os locks de escrita e registram seu estado de preparação utilizando Paxos. Depois eles informam ao coordenador o timestamp de preparação. O coordenador aguarda as respostas dos participantes e escolhe um timestamp de commit que respeite as restrições necessárias para preservar a ordem da transação. O resultado do commit também é registrado por meio do Paxos, garantindo que o estado do Transaction Manager seja replicado.

3. TrueTime

Mesmo resolvendo replicação e transações distribuídas, ainda existe outro problema que é como determinar a ordem global das transações?

Em um banco distribuído globalmente, diferentes máquinas possuem relógios diferentes. Mesmo utilizando sincronização de relógios, sempre existe algum nível de incerteza. Se cada máquina simplesmente utilizasse seu próprio relógio local para definir o timestamp de uma transação, poderia acontecer de uma transação que ocorreu posteriormente receber um timestamp menor que uma transação anterior.

O Spanner resolve esse problema com o TrueTime.

Em vez de fornecer um único valor afirmando "agora são exatamente X horas", a API retorna um intervalo:

TT.now() = [earliest, latest]

A ideia é que o tempo físico real esteja garantidamente dentro desse intervalo.

O Spanner mantém essa incerteza pequena utilizando múltiplas referências de tempo, incluindo GPS e relógios atômicos. O sistema não tenta fingir que todos os relógios são perfeitamente sincronizados. Pelo contrário: ele conhece explicitamente a margem de erro dos relógios e utiliza essa informação nos algoritmos de transação.

4. Commit Wait

Mas existe uma dificuldade pois mesmo que o Spanner conheça o intervalo de incerteza do relógio, ele ainda precisa garantir que um timestamp de commit não seja interpretado como pertencente ao futuro quando a transação já estiver sendo observada como concluída.

Por isso existe o Commit Wait.

O coordenador escolhe um timestamp de commit s, baseado no limite superior fornecido pelo TrueTime. Antes de permitir que a transação seja confirmada e observada pelos clientes, o sistema aguarda até que o limite inferior do intervalo retornado pelo TrueTime seja maior que s. Nesse momento, o sistema pode garantir que o timestamp de commit s pertence definitivamente ao passado.

O ponto mais importante é que o Commit Wait não serve simplesmente para "sincronizar os relógios". O relógio continua tendo incerteza. O que o Spanner faz é usar essa incerteza a seu favor.

Se uma transação recebe um timestamps, o sistema espera até que tenha certeza de que o tempo real já ultrapassou. Somente então o commit pode ser observado externamente. Dessa maneira, se uma segunda transação começar depois que a primeira já foi confirmada e observada pelo cliente, o TrueTime garante que a segunda transação não receberá um timestamp que viole essa ordem.

Resumo da ópera (Sim, foi gerado por IA Sherlock)

Após esse resumo sobre as principais features implementadas no Spanner que permitem trabalhar com transações distribuídas, dados replicados em datacenters ao redor do mundo e toda a consistência que torna o banco confiável, vamos partir para a mão na massa e emular o Spanner localmente e dar uma brincada.

Emulando o Cloud Spanner com `cloud-spanner-emulator`

É importante lembrar que o Spanner Emulator possui algumas limitações quando comparado ao Google Cloud Spanner disponibilizado pelo gcloud. O emulador é voltado principalmente para desenvolvimento e testes locais e não reproduz toda a infraestrutura distribuída do Spanner em produção. Por isso, ele não simula recursos como a replicação real entre regiões e datacenters, a distribuição física dos dados, a alta disponibilidade proporcionada pela infraestrutura global do Google Cloud, nem representa fielmente os comportamentos de latência e falhas de uma arquitetura distribuída real.

Para seguir, é necessário ter Git, Ruby, Docker e Docker Compose instalados na sua máquina. Eu uso Ubuntu como sistema operacional, então os comandos utilizados aqui são voltados para ele.

Primeiro, faça o clone do projeto na sua máquina clicando aqui.

O Spanner Emulator será executado via Docker Compose. A configuração desse serviço está definida no arquivo docker-compose.yml dentro do projeto.

services:
  spanner:
    image: gcr.io/cloud-spanner-emulator/emulator
    ports:
      - "9010:9010"
      - "9020:9020"

Essa é uma configuração simples do Spanner Emulator, executando localmente em um container Docker, sem a necessidade de utilizar o gcloud para subir ou gerenciar a instância localmente.

Também não estamos configurando aqui um cenário com múltiplas réplicas ou uma topologia distribuída. A ideia é apenas ter uma instância local do emulator para podermos realizar nossos testes

Para subir o serviço em segundo plano, o comando é o:

docker compose up -d

Ele vai criar e executar o container do Spanner Emulator. Para garantir que ele está funcionando corretamente, você pode verificar os containers em execução com o comando:

docker ps

Você tera um retorno parecido com esse

CONTAINER ID   IMAGE                                    COMMAND                  CREATED       STATUS         PORTS                                                                                      NAMES
7e5383d98efd   gcr.io/cloud-spanner-emulator/emulator   "./gateway_main --ho…"   11 days ago   Up 8 seconds   0.0.0.0:9010->9010/tcp, [::]:9010->9010/tcp, 0.0.0.0:9020->9020/tcp, [::]:9020->9020/tcp   spanner-spanner-1

Agora que temos o Spanner rodando, vou explicar como o código funciona passo a passo. Se quiser se aventurar sozinho pelo código, o README do projeto vai te ajudar a se situar.

Se você não conhece Ruby, nós usamos o Bundler para gerenciar e instalar nossas bibliotecas, que em Ruby chamamos de gems. As gems utilizadas pelo projeto, assim como suas respectivas versões, estão definidas no arquivo Gemfile.

# frozen_string_literal: true

source 'https://rubygems.org'

gem 'dotenv', '>= 3.2'
gem 'google-cloud-spanner', '>= 2.36'
gem 'mutex_m', '>= 0.3.0'

A gem principal para o nosso estudo é a google-cloud-spanner. Ela vai nos permitir utilizar a API do Spanner, conectar ao banco de dados e executar transações. O legal é que, nessa versão da gem, não precisamos adicionar uma gem secundária para gerenciar um pool de conexões, pois o próprio cliente do Spanner já trabalha com o gerenciamento de sessões.

A gem dotenv é responsável por carregar nossas variáveis de ambiente a partir do arquivo .env. Também temos a mutex_m, que foi adicionada por causa da versão do Ruby utilizada no projeto. Basicamente, ela é uma dependência necessária para o funcionamento da google-cloud-spanner nessa versão do Ruby.

Dito isso, podemos instalar as gems utilizando o comando:

bundle install

No contexto da gem google-cloud-spanner, um client é o objeto que representa sua conexão lógica com o serviço do Cloud Spanner. Ele é o ponto de entrada para acessar instâncias, bancos de dados e outros recursos.

Então temos um wrapper para criar nosso client em client.rb

# frozen_string_literal: true

require 'google/cloud/spanner'
require 'dotenv/load'

Dotenv.load

# Wraps the Google::Cloud::Spanner project client.
# Provides a configured Spanner client connected to the emulator.
class Client
  def create
    Google::Cloud::Spanner.new(
      project_id: 'localhost'
    )
  end
end

Em instance.rb temos uma classe para a criação de uma instancia do Spanner basicamente essa instancia é o nível mais alto de organização é basicamente um container que agrupa bancos de dados. A instance define onde os dados moram e quanto recurso eles têm (no emulador isso é irrelevante mas em produção, cada instance tem N nós com processamento e armazenamento dedicados).

class Instance
  def initialize
    @client = Client.new.create   # cria o client do projeto Spanner (Google::Cloud::Spanner)
  end

  attr_reader :client             # expõe o client pra outros usarem (ex: Database#client)

  def find
    @client.instance('test-instance')   # busca a instance existente
  end

  def create
    @client.create_instance(            # tenta criar a instance
      'test-instance',                  # ID da instance
      name: 'Test Instance',            # nome amigável
      config: 'emulator-config',        # região/emulador
      nodes: 1                          # quantidade de nós
    ).wait_until_done!                  # aguarda a criação terminar (é async)

    find                                # depois busca e retorna a instance criada
  rescue Google::Cloud::AlreadyExistsError
    find                                # se já existia, só retorna a existente
  end
end

Para concluir a configuração, agora precisamos criar um banco de dados e fornecer um client conectado a esse banco para executar nossas transações, isso acontece na classe database.rb

# Importa a classe responsável por gerenciar a instância do Spanner.
require_relative 'instance'

# Gerencia o ciclo de vida e o acesso ao banco de dados Spanner.
class Database
  # Define o identificador da instância do Spanner.
  INSTANCE_ID = 'test-instance'

  # Define o identificador do banco de dados.
  DATABASE_ID = 'test-db'

  # Inicializa e armazena a instância do Spanner.
  def initialize
    @instance = Instance.new.create
  end

  # Cria o banco ou retorna o banco existente.
  def create
    # Cria o banco e aguarda a conclusão da operação.
    @instance.create_database(DATABASE_ID).wait_until_done!

    # Retorna uma referência ao banco criado.
    @instance.database(DATABASE_ID)
  rescue Google::Cloud::AlreadyExistsError
    # Retorna o banco caso ele já exista.
    @instance.database(DATABASE_ID)
  end

  # Retorna um cliente reutilizável para acessar o banco.
  def client
    # Cria o cliente apenas uma vez e reutiliza nas próximas chamadas.
    @client ||= Instance.new.client.client(INSTANCE_ID, DATABASE_ID)
  end
end

Agora que temos toda a configuração explicada, precisamos de tabelas, pois estamos lidando com um banco de dados, afinal. Para isso, é uma prática legal criar migrations, que são scripts pré-definidos utilizados para criar e alterar tabelas, índices e outros recursos do banco de dados de forma versionada.

No projeto, temos a pasta migrations, que contém as migrações responsáveis por criar as tabelas Users e Accounts.

Exemplo em migrations/create_accounts.rb

# frozen_string_literal: true

require_relative 'base'

# Migration that creates the Accounts table.
class CreateAccounts < Migration
  DDL = <<~SQL
    CREATE TABLE Accounts (
      AccountId INT64 NOT NULL,
      Owner STRING(MAX) NOT NULL,
      Balance NUMERIC NOT NULL,
      UpdatedAt TIMESTAMP OPTIONS (allow_commit_timestamp=true)
    ) PRIMARY KEY (AccountId)
  SQL
end

Para executar as migrações, temos um Rakefile que contém tarefas automatizadas escritas em Ruby. O comando para executar a tarefa responsável por rodar as migrações é:

bundle exec rake db:migrate

Se tudo ocorrer como o esperado nos teremos duas tabelas criadas no Emulador de Spanner. Para testar, vamos criar alguns registros e listar os dados de User e Account. Para isso temos os models, que basicamente representam as nossas tabelas criadas no Spanner e facilitam a interação com os dados por meio do código Ruby.

Exempo em models/user.rb

# frozen_string_literal: true

require_relative 'base'

# Represents a user record in the Users table.
class User < Base
  TABLE_NAME = 'Users'
  COLUMNS = %w[UserId Name UpdatedAt].freeze

  def create(user_id:, name:)
    commit_timestamp = Google::Cloud::Spanner::ColumnValue.commit_timestamp
    super({ UserId: user_id, Name: name, UpdatedAt: commit_timestamp })
  end
end

Para criar um registro, precisamos acessar o irb, que é o console interativo do Ruby. Com ele, podemos carregar nossas classes, instanciar objetos e executar as operações que precisamos diretamente pelo terminal.

Comando para acessar o irb

irb

Bem facil você não acha?

Para criar um registro

require_relative 'models/user'

user = User.new
user.create(user_id: 123, name: "John")

Ainda no mesmo console para conferir se o registro foi feito com sucesso, execute o find

user.find(123)

Você deve receber uma resposta assim

=> {UserId: 123, Name: "John", UpdatedAt: 2026-08-02 21:51:49.196166 UTC}

Isso significa que conseguimos criar e listar registros no Cloud Spanner. O próximo passo agora é executar os examples que estão no código e que permitem explorar algumas particularidades desse banco de dados.

O primeiro é o examples/transfer.rb. Esse código serve para demonstrar o conceito de ACID, mais especificamente a atomicidade das transações no Cloud Spanner.

# frozen_string_literal: true

require_relative '../models/account'
require_relative '../config/logger'

db = Database.new
db.create
client = db.client

# Garante dados limpos (upsert é idempotente)
client.commit { |c| c.upsert 'Accounts', [{ AccountId: 1, Owner: 'Alice', Balance: 1000 }] }
client.commit { |c| c.upsert 'Accounts', [{ AccountId: 2, Owner: 'Bob',   Balance: 0 }] }

LOGGER.info 'Initial balance'
Account.new.all.each { |a| LOGGER.info "  ##{a[:AccountId]} #{a[:Owner]}: $#{a[:Balance].to_f}" }

# =============================================================================
# Successful transfer: read, validate, debit, credit inside a transaction
# =============================================================================
client.transaction do |tx|
  alice = tx.execute_query(
    'SELECT AccountId, Balance FROM Accounts WHERE AccountId = @id',
    params: { id: 1 }
  ).rows.first

  raise 'Insufficient funds' if alice[:Balance] < 700

  tx.execute_update 'UPDATE Accounts SET Balance = Balance - @amount WHERE AccountId = @id',
                    params: { amount: 700, id: 1 }
  tx.execute_update 'UPDATE Accounts SET Balance = Balance + @amount WHERE AccountId = @id',
                    params: { amount: 700, id: 2 }
end

LOGGER.info 'After transfer'
Account.new.all.each { |a| LOGGER.info "  ##{a[:AccountId]} #{a[:Owner]}: $#{a[:Balance].to_f}" }

# =============================================================================
# Rollback: an exception inside the block prevents commit
# =============================================================================
begin
  client.transaction do |tx|
    alice = tx.execute_query(
      'SELECT Balance FROM Accounts WHERE AccountId = @id',
      params: { id: 1 }
    ).rows.first

    raise "Balance: $#{alice[:Balance]}" if alice[:Balance] < 500

    tx.execute_update 'UPDATE Accounts SET Balance = Balance - @amount WHERE AccountId = @id',
                      params: { amount: 500, id: 1 }
  end
rescue RuntimeError => e
  LOGGER.info "Transfer denied: #{e.message}"
end

LOGGER.info 'Balances unchanged'
Account.new.all.each { |a| LOGGER.info "  ##{a[:AccountId]} #{a[:Owner]}: $#{a[:Balance].to_f}" }

O que ele faz?

Cria o banco e garante que as contas existam:
- Alice: $1000
- Bob: $0
Executa uma transferência de $700 dentro de uma transação:
- Verifica o saldo de Alice.
- Retira $700 de Alice.
- Adiciona $700 a Bob.
- Se tudo der certo, a transação faz commit.
Testa um rollback:
- Tenta retirar $500 de Alice.
- Como o saldo é insuficiente, uma exceção é lançada.
- A transação não é confirmada e a alteração é desfeita.

Isso demonstra que o Spanner consegue manter a consistência dos dados durante operações que envolvem múltiplas alterações. Nesse caso, a transferência é atômica: ou as duas operações que são retirar o dinheiro de Alice e adicionar o dinheiro a Bob são confirmadas, ou nenhuma delas é aplicada.

Para rodar basta executar (fora do console irb)

ruby examples/transfer.rb

Exemplo de resposta

Initial balance
  #1 Alice: $1000.0
  #2 Bob: $0.0
After transfer
  #1 Alice: $300.0
  #2 Bob: $700.0
Transfer denied: Balance: $0.3e3
Balances unchanged
  #1 Alice: $300.0
  #2 Bob: $700.0

Outro exemplo adicionado é o examples/concurrency.rb Esse código testa a concorrência e o isolamento transacional do Cloud Spanner. Ele cria 10 threads simultâneas. Cada uma tenta transferir $100 da Alice para o Bob

Como as 10 transações acontecem ao mesmo tempo, várias podem tentar alterar o mesmo registro da Alice.

O que o Spanner faz?

O Spanner detecta que existem transações concorrentes conflitantes e algumas podem ser abortadas para preservar a consistência.

A Gem então pode tentar novamente automaticamente a transação abortada.

O exemplo em examples/concurrency.rb

# frozen_string_literal: true

require_relative '../models/account'
require_relative '../config/logger'

# =============================================================================
# Concurrency test: multiple threads racing to debit the same account.
#
# Spanner detects conflicts and aborts all but one transaction.
# The client automatically retries aborted transactions.
# =============================================================================

db = Database.new
db.create
client = db.client

client.commit { |c| c.upsert 'Accounts', [{ AccountId: 1, Owner: 'Alice', Balance: 1000 }] }
client.commit { |c| c.upsert 'Accounts', [{ AccountId: 2, Owner: 'Bob',   Balance: 0 }] }

THREADS = 10
AMOUNT  = 100

successful = Queue.new
failed     = Queue.new

threads = (1..THREADS).map do |i|
  Thread.new do
    attempt = 0
    begin
      client.transaction do |tx|
        attempt += 1
        LOGGER.info "[T#{i}] attempt ##{attempt}"
        alice = tx.execute_query(
          'SELECT Balance FROM Accounts WHERE AccountId = @id', params: { id: 1 }
        ).rows.first
        raise 'Insufficient funds' if alice[:Balance] < AMOUNT

        tx.execute_update(
          'UPDATE Accounts SET Balance = Balance - @amount WHERE AccountId = @id', params: { amount: AMOUNT, id: 1 }
        )
        tx.execute_update(
          'UPDATE Accounts SET Balance = Balance + @amount WHERE AccountId = @id', params: { amount: AMOUNT, id: 2 }
        )
      end
      successful << i
      LOGGER.info "[T#{i}] committed after #{attempt} attempt(s)"
    rescue RuntimeError
      failed << i
      LOGGER.info "[T#{i}] denied after #{attempt} attempt(s)"
    end
  end
end

threads.each(&:join)

alice = client.read('Accounts', %w[Balance], keys: 1).rows.first
bob   = client.read('Accounts', %w[Balance], keys: 2).rows.first

LOGGER.info '=' * 50
LOGGER.info "Successful: #{successful.length}, Denied: #{failed.length}"
LOGGER.info "Alice: $#{alice[:Balance].to_f}, Bob: $#{bob[:Balance].to_f}"

if alice[:Balance].zero? && bob[:Balance] == 1000
  LOGGER.info 'Correct'
else
  LOGGER.info 'Unexpected balance'
end

Para executar

ruby examples/concurrency.rb

Exemplo de resposta

[T1] attempt #1
[T2] attempt #1
[T3] attempt #1
[T4] attempt #1
[T5] attempt #1
[T6] attempt #1
[T7] attempt #1
[T8] attempt #1
[T9] attempt #1
[T10] attempt #1
[T6] committed after 1 attempt(s)
[T2] attempt #2
[T3] attempt #2
[T4] attempt #2
[T7] attempt #2
[T8] attempt #2
[T9] attempt #2
[T5] attempt #2
[T10] attempt #2
[T1] attempt #2
[T7] committed after 2 attempt(s)
[T4] attempt #3
[T8] attempt #3
[T2] attempt #3
[T9] attempt #3
[T3] attempt #3
[T5] attempt #3
[T10] attempt #3
[T1] attempt #3
[T10] committed after 3 attempt(s)
[T8] attempt #4
[T2] attempt #4
[T9] attempt #4
[T3] attempt #4
[T5] attempt #4
[T1] attempt #4
[T4] attempt #4
[T1] committed after 4 attempt(s)
[T9] attempt #5
[T8] attempt #5
[T4] attempt #5
[T2] attempt #5
[T3] attempt #5
[T5] attempt #5
[T3] committed after 5 attempt(s)
[T2] attempt #6
[T9] attempt #6
[T5] attempt #6
[T8] attempt #6
[T4] attempt #6
[T2] committed after 6 attempt(s)
[T5] attempt #7
[T9] attempt #7
[T8] attempt #7
[T4] attempt #7
[T5] committed after 7 attempt(s)
[T8] attempt #8
[T9] attempt #8
[T4] attempt #8
[T9] committed after 8 attempt(s)
[T4] attempt #9
[T8] attempt #9
[T4] committed after 9 attempt(s)
[T8] attempt #10
[T8] committed after 10 attempt(s)
==================================================
Successful: 10, Denied: 0
Alice: $0.0, Bob: $1000.0
Correct

Resumidamente, o resultado mostra que:

As 10 threads começaram simultaneamente, tentando transferir $100.
Como todas alteram o saldo da mesma conta (Alice), ocorreram conflitos entre as transações.
O Spanner abortou algumas transações conflitantes, e o cliente reexecutou automaticamente essas transações.
Por isso, algumas transações precisaram de várias tentativas:
- T1 → 4 tentativas
- T8 → 10 tentativas
No final, todas as 10 transações foram concluídas com sucesso.

O saldo final está correto:

Alice: $0
Bob: $1000

Isso demonstra que o Spanner consegue controlar a concorrência e manter a consistência dos dados mesmo com várias transações sendo executadas simultaneamente.

Esse é um código simples, criado apenas para testar o Spanner Emulator. É importante lembrar que o emulador não consegue reproduzir todas as principais funcionalidades e benefícios de executar o Spanner em uma infraestrutura real do Google Cloud, como a replicação de dados entre múltiplas regiões e a distribuição dos dados entre diferentes datacenters.

Conector do Spanner para Active Record

O código que mostrei foi desenvolvido em Ruby. Porém, para facilitar a integração do Cloud Spanner com aplicações desenvolvidas em Ruby on Rails, existe a gem activerecord-spanner-adapter, que funciona como um adaptador entre o Active Record e o Spanner.

Ferramenta para testes de carga

Para avaliar o desempenho do Cloud Spanner sob diferentes níveis de carga e concorrência, podemos utilizar o YCSB (Yahoo! Cloud Serving Benchmark). O próprio Google Cloud utiliza o YCSB em benchmarks do Spanner para avaliar workloads de chave-valor, simulando diferentes padrões de leitura e escrita.

Conclusão

No fim das contas, o que mais me chamou atenção no Spanner não foi uma única tecnologia isolada, mas a forma como várias ideias diferentes trabalham juntas para um problema extremamente chato e dificil de se resolver.

O Spanner tenta unir coisas que durante muito tempo pareciam exigir escolhas diferentes entre o modelo relacional e as transações ACID dos bancos tradicionais com a distribuição global e a escalabilidade horizontal esperadas de sistemas distribuídos.

Para isso, ele combina replicação e consenso com Paxos, transações distribuídas com Two-Phase Commit, controle de concorrência, e utiliza o TrueTime e o Commit Wait para garantir uma ordem global consistente entre as transações. Cada uma dessas peças resolve um problema específico, mas é a junção desse "Lego" de ideias que permite ao Spanner oferecer consistência forte em uma arquitetura distribuída globalmente.

No nosso pequeno laboratório local (que obviamente não conseguimos reproduzir toda essa infraestrutura) por mais simples que tenha sido, foi suficiente para brincar com algumas das ideias que vimos ao longo do artigo: criar tabelas, executar transações, testar atomicidade, provocar concorrência e observar o banco lidando com conflitos entre transações.

E acho que esse é o ponto principal deste artigo. O objetivo aqui não era explicar absolutamente tudo sobre o Spanner, muito menos substituir a documentação oficial. A ideia era simplesmente entender por que ele existe, quais problemas ele tenta resolver, como suas principais peças se encaixam e colocar a mão no código para ver um pouco disso funcionando na prática.

No final, talvez a melhor forma de resumir o Spanner seja justamente aquela pergunta do começo, que é como construir um banco de dados que funcione em vários datacenters espalhados pelo mundo sem abrir mão da consistência das transações?

Para mim o Cloud Spanner é uma boa resposta.

Referências

https://static.googleusercontent.com/media/research.google.com/pt-BR//archive/spanner-osdi2012.pdf

https://static.googleusercontent.com/media/research.google.com/pt-BR//pubs/archive/45855.pdf

https://dl.acm.org/doi/epdf/10.1145/3035918.3056103

https://medium.com/@mani.saksham12/raft-and-paxos-consensus-algorithms-for-distributed-systems-138cd7c2d35a

https://medium.com/@sylvain.tiset/two-phase-commit-the-good-the-bad-and-the-blocking-eee29e1f5a84

https://cloud.google.com/blog/products/databases/benchmarking-spanner-for-key-value-workloads

Implementando um Sistema de Ranking com Rating Elo em Ruby

Michael Alves — Wed, 17 Jun 2026 17:45:10 +0000

Rating Elo e o filme A Rede Social

Um dos filmes que me fez querer entrar na área de tecnologia foi A Rede Social. O filme conta a história de como Mark Zuckerberg fundou o Facebook, eu descobri várias coisas legais com esse filme. A primeira delas foi que o melhor amigo do Mark era um brasileiro chamado Eduardo e esse brasileiro processou o Mark depois por ter perdido suas ações na empresa. A segunda coisa é que, antes do Facebook, dois irmãos tiveram a ideia de uma rede social para pessoas de Harvard, chamaram o Mark para desenvolver e, depois, esses dois caras também acabaram processando o Mark por plágio, Entre outras coisas, é um ótimo filme, com uma boa trilha sonora.

Nesse filme o Mark briga com a namorada, enche a cara de álcool e decide ter uma ideia bem canalha, que é hackear os Facebooks de Havard (Os Facebooks de Harvard eram diretórios digitais que consistiam em catálogos com as fotos, nomes, cursos e interesses dos calouros), pegar as imagens com os rostos das alunas e fazer um site onde ele compara qual aluna era "mais atraente" (Sim, isso foi bem bizarro e escroto). Nesse momento, ele pede ao seu amigo Eduardo para explicar qual algoritmo usar para fazer o ranking dessas garotas. Nesse caso, era o algoritmo que o Eduardo usava para ranquear os jogadores de xadrez. Daí temos a lendária cena da janela do quarto do Mark contendo a equação usada para gerar o ranking.

Tirando o fato de que essa equação foi usada para o mal, eu fiquei pensando se ela era real e por que foi usada para aquela finalidade de ranking.

Eu pedi para a IA ajustar a imagem para trazer com mais clareza a equação usada.

Apesar da imagem ter o expoente parecendo uma fração, a equação seria esta:

Pesquisando, eu descobri que isso se chama Rating Elo. Segundo a Wikipédia:

O Rating Elo é um método estatístico utilizado para calcular a força relativa entre jogadores de xadrez, inventado pelo físico americano Arpad Elo e utilizado no ranking da FIDE. O método funciona adequadamente quando utilizado da maneira que foi projetado, embora existam algumas limitações. O rating também foi adaptado para outros esportes, como, por exemplo, o tênis.

Porque usar essa equação para ranquear?

É uma boa pergunta. Vamos criar um modelo mental para visualizar melhor o problema. Digamos que temos que ranquear os melhores jogadores de xadrez.

Acredito que o modelo mental mais simples seria ranquear pelo número de vitórias.

Exemplo:

Jogador	Vitórias
João	20
Maria	18
Pedro	5

À primeira vista, parece justo colocar João em primeiro lugar, já que ele possui mais vitórias.

Mas esse modelo possui um problema: ele considera apenas a quantidade de vitórias, ignorando a força dos adversários enfrentados.

Imagine que:

João venceu 20 partidas contra iniciantes.
Maria venceu 16 iniciantes e 2 mestres.
Pedro venceu 5 mestres.

Nesse cenário, as vitórias não possuem o mesmo valor.

Era esperado que um mestre derrotasse um iniciante, então as 20 vitórias de João trazem pouca informação sobre sua habilidade real. Por outro lado, as 5 vitórias de Pedro contra mestres são resultados muito mais difíceis e inesperados, indicando que ele provavelmente é mais forte do que seu histórico inicial sugere.

O sistema Elo foi criado para resolver exatamente esse problema: em vez de contar apenas quantas partidas cada jogador venceu, ele também considera a força dos adversários derrotados. Dessa forma, vencer um jogador forte vale mais do que vencer um jogador fraco, tornando o ranking muito mais representativo da habilidade real dos participantes.

Vamos implementar a equação

ELO_DIVISOR = 400.00

def rating_elo(rating_player_a, rating_player_b)
  rating_players_result = (rating_player_b - rating_player_a) / ELO_DIVISOR
  1 / (1 + 10**rating_players_result)
end

Explicando cada linha, o ELO_DIVISOR é uma constante em Ruby, usada para indicar que esse valor não deve mudar.

A próxima linha é o nosso método, def rating_elo. Esse método recebe dois parâmetros, que seriam equivalentes ao RA e ao RB.

Na próxima linha (rating_players_result = (rating_player_b - rating_player_a) / ELO_DIVISOR), calculamos a expectativa de pontuação dos jogadores, ou seja, a probabilidade de o jogador A vencer o jogador B.

Exemplo de uso (copie e cole o código no console Ruby, o IRB):

ELO_DIVISOR = 400.00

def rating_elo(rating_player_a, rating_player_b)
  rating_players_result = (rating_player_b - rating_player_a) / ELO_DIVISOR
  1 / (1 + 10**rating_players_result)
end

# Criamos variáveis para definir o rating inicial de cada jogador
rating_player_a = 1500
rating_player_b = 1900

# Usamos o método para calcular a probabilidade de vitória do jogador A
result = rating_elo(rating_player_a, rating_player_b)

# Pegamos apenas duas casas decimais para facilitar o entendimento do resultado
result.round(2)

Resultado da execução:

irb(main):027> rating_player_a = 1500
irb(main):028> rating_player_b = 1900
=> 1900
irb(main):029> result = rating_elo(rating_player_a, rating_player_b)
=> 0.09090909090909091
irb(main):030> result.round(2)
=> 0.09
irb(main):031>

Ou seja, o nosso jogador A tem apenas 9% de chance de ganhar do jogador B. Faz sentido, pois o rating inicial dele é menor.

Se invertermos a ordem, o jogador B terá 91% de chance de vitória.

irb(main):031> result = rating_elo(rating_player_b, rating_player_a)
=> 0.9090909090909091
irb(main):032> result.round(2)
=> 0.91
irb(main):033>

Agora precisamos usar a fórmula Elo e, após isso, calcular o novo rating depois de uma partida. Para isso, precisamos definir o quanto o rating muda ao finalizar uma partida.

Para isso, vamos usar uma constante chamada K_FACTOR. Ela é o parâmetro que controla o quanto o rating vai mudar após uma vitória ou derrota.

Eu vou definir que o nosso K_FACTOR é 90 e também vou criar uma classe para os nossos jogadores, facilitando a atualização do rating.

ELO_DIVISOR = 400.0
K_FACTOR = 90

class Player
  attr_reader :name
  attr_accessor :rating

  def initialize(name, rating)
    @name = name
    @rating = rating
  end
end

Agora precisamos adicionar a lógica do Elo com atualização de rating. Seguindo a lógica de uma partida normal, teremos atualização para vitória, derrota e empate.

def play(player_a_name, player_b_name, score_a)
  # Busca o jogador A no hash de jogadores através do nome
  player_a = @players.fetch(player_a_name)

  # Busca o jogador B no hash de jogadores através do nome
  player_b = @players.fetch(player_b_name)

  # Calcula automaticamente o resultado do jogador B

  # Exemplos:
  # Resultado de A   Resultado de B
  # 1.0 (vitória)   0.0
  # 0.5 (empate)    0.5
  # 0.0 (derrota)   1.0
  score_b = 1.0 - score_a

  # Calcula a expectativa de pontuação de A contra B
  expected_a = rating_elo(player_a, player_b)

  # Calcula a expectativa de B
  expected_b = rating_elo(player_b, player_a)

  # Atualiza o rating dos jogadores
  player_a.rating += K_FACTOR * (score_a - expected_a)
  player_b.rating += K_FACTOR * (score_b - expected_b)
end

Basicamente, com o método play, nós decidimos o vencedor da partida ou se houve empate.

Exemplo de uso:

# Player A vence
ranking.play("Michael", "Angelica", 1.0)

# Empate
ranking.play("Michael", "Angelica", 0.5)

# Player A perde
ranking.play("Michael", "Angelica", 0.0)

Por último, adicionamos um método para trazer o ranking dos jogadores ordenados.

def leaderboard
  @players.values
          .sort { |a, b| b.rating <=> a.rating }
          .each_with_index do |player, index|
    puts "#{index + 1}. #{player.name.ljust(8)} #{player.rating.round(2)}"
  end
end

Agora adicionamos tudo em uma classe chamada Ranking e temos o código completo.

ELO_DIVISOR = 400.0
K_FACTOR = 90

class Player
  attr_reader :name
  attr_accessor :rating

  def initialize(name, rating)
    @name = name
    @rating = rating
  end
end

class Ranking
  def initialize(players)
    @players = {}

    players.each do |name, rating|
      @players[name] = Player.new(name, rating)
    end
  end

  def rating_elo(player_a, player_b)
    1.0 / (1 + 10**((player_b.rating - player_a.rating) / ELO_DIVISOR))
  end

  def play(winner_name, loser_name)
    winner = @players.fetch(winner_name)
    loser = @players.fetch(loser_name)

    expected_winner = rating_elo(winner, loser)
    expected_loser = rating_elo(loser, winner)

    winner.rating += K_FACTOR * (1 - expected_winner)
    loser.rating += K_FACTOR * (0 - expected_loser)

    puts "#{winner.name} venceu #{loser.name}"
    puts "#{winner.name}: #{winner.rating.round(2)}"
    puts "#{loser.name}: #{loser.rating.round(2)}"
  end

  def leaderboard
    @players.values
            .sort_by { |player| -player.rating }
            .each_with_index do |player, index|
      puts "#{index + 1}. #{player.name.ljust(8)} #{player.rating.round(2)}"
    end
  end

  def player(name)
    @players[name]
  end
end

ranking = Ranking.new(
  "Judit"    => 1900,
  "Angelica" => 1800,
  "Michael"  => 1600,
  "Maria"    => 1300,
  "Pedro"    => 1200,
  "Eric"     => 1100
)

Legal, temos a equação funcionando. Agora podemos usá-la na prática para criar um pequeno sistema de ranking.

Ranqueando jogadores

Jogador	Rating inicial
Judit	1900
Angelica	1800
Michael	1600
Maria	1300
Pedro	1200
Eric	1100

Esses são os nossos jogadores. Perceba que a Judit já começa com um rating inicial bem alto, provavelmente porque ela é uma boa jogadora e tem muita experiência. E temos o Eric. Vamos partir do pressuposto de que ele é um jogador promissor, porém teve poucas vitórias.

Rodada 1 — Grande surpresa

Vamos colocar o jogador Eric, último do ranking, para enfrentar o top 3 de jogadores: Judit, Angelica e Michael. E vamos dar a vitória para o Eric.

ranking.play("Eric", "Judit", 1.0)
ranking.play("Eric", "Angelica", 1.0)
ranking.play("Eric", "Michael", 1.0)

O resultado foi:

1. Judit    1810.89
2. Angelica 1712.6
3. Michael  1522.1
4. Eric     1354.41
5. Maria    1300
6. Pedro    1200

O que observar?

Eric ganha muitos pontos.
Judit perde muitos pontos.
Angelica perde muitos pontos.
Michael perde muitos pontos.

Por quê?

Era um resultado extremamente improvável.

Após enfrentar o top 3 e vencer, Eric subiu para a quarta posição do ranking. Ao mesmo tempo que a equação beneficia o jogador que se arrisca e enfrenta os melhores do ranking, ela também pune o jogador de alto nível que perdeu.

Vamos criar outras rodadas para elucidar os conceitos da equação.

Rodada 2 — Resultado esperado

Judit vence Pedro.

ranking.play("Judit", "Pedro", 1.0)

Resultado:

irb(main):067> ranking.leaderboard
1. Judit    1813.49
2. Angelica 1712.6
3. Michael  1522.1
4. Eric     1354.41
5. Maria    1300
6. Pedro    1197.4

O que observar?

Judit ganha poucos pontos.
Pedro perde poucos pontos.

Por quê?

O sistema já esperava que uma jogadora com rating 1810.89 vencesse um jogador com rating 1200.

Rodada 3 — Empate surpreendente

ranking.play("Eric", "Judit", 0.5)

Resultado

irb(main):069> ranking.leaderboard
1. Judit    1774.47
2. Angelica 1712.6
3. Michael  1522.1
4. Eric     1393.43
5. Maria    1300
6. Pedro    1197.4
=>

O que observar?

Eric ganha pontos.
Judit perde pontos.

Mesmo sem vitória.

Por quê?

Empatar contra alguém muito mais forte já é melhor do que o esperado.

Conclusão

O sistema que implementamos aqui é uma versão simplificada do Rating Elo, mas já é suficiente para demonstrar o principal conceito por trás da fórmula: não basta contar vitórias e derrotas, também é necessário considerar a força dos adversários enfrentados.

Na prática, sistemas de ranking costumam ser bem mais sofisticados. Uma possível evolução seria tornar o K_FACTOR dinâmico, fazendo com que ele varie de acordo com o nível ou experiência do jogador. Jogadores novos poderiam ter um fator maior para que o sistema identificasse rapidamente sua habilidade real, enquanto jogadores mais experientes teriam um fator menor, deixando o ranking mais estável.

Outra possibilidade seria considerar o histórico de partidas do jogador. Alguém que mantém uma alta taxa de vitórias ao longo do tempo poderia receber ajustes diferentes de um jogador com desempenho inconsistente. Também poderíamos criar regras específicas para séries de vitórias, frequência de partidas ou até diferentes pesos para torneios.

O objetivo deste artigo não foi construir o sistema de ranking perfeito, mas entender a matemática por trás do Elo e implementar uma versão funcional do algoritmo. A partir daqui, existem diversas formas de aumentar a complexidade do modelo e adaptá-lo para diferentes tipos de jogos e aplicações.

Referências

Rating Elo

The Elo Rating System: A Data-Driven Approach to Ranking Competitor

Concorrência e Paralelismo em Ruby

Michael Alves — Wed, 21 May 2025 22:29:49 +0000

Software concorrente, paralelismo, múltiplas threads, esses assuntos sempre acabam surgindo, independentemente do seu nível de senioridade. Por muito tempo, esses temas foram verdadeiros pesadelos para mim. Eu me lembro de estudar concorrência usando C na faculdade. Eu fazia os exercícios, e eles funcionavam, mas, por muito tempo, parecia que eu não entendia muito bem como o computador conseguia fazer a "mágica" de executar meus programas de forma mais "rápida".

Este guia foi feito para abordar os conceitos de processos, clone de processos e threads, usando Ruby como linguagem base.

Ruby: Uma Linguagem Amigável e Elegante

Ruby é uma linguagem de programação interpretada e multi paradigma, com tipagem dinâmica e gerenciamento automático de memória. O interpretador mais comum é o MRI, sigla para Matz's Ruby Interpreter, também conhecido como CRuby por ser implementado em C. Ele é considerado o interpretador padrão da linguagem e o mais amplamente utilizado pela comunidade.

MRI por padrão oferece suporte a tão falada concorrência.

Recurso	Suporte?
Threads	✅ Sim
Fork	✅ Sim
Processos	✅ Sim

Vamos utilizar duas versões diferentes de interpretadores Ruby para os testes. Para alternar entre eles de forma fácil e rápida, usaremos o gerenciador de versões rbenv.

Comandos para instalar as versões usadas aqui:

rbenv install 3.3.5
rbenv install jruby-9.4.8.0

Comando para usar uma versão especifica de forma global:

rbenv global 3.3.5

Comando para listar as versões instaladas:

rbenv versions

Saída

  system
* 3.3.5 (set by /home/michael/.rbenv/version)
  jruby-9.4.8.0

Processos

Usaremos o Ubuntu como sistema operacional, ou seja, os conceitos abordados aqui se aplicam a sistemas do tipo UNIX-like.

Os programas que rodam no seu Sistema operacional estão dentro de uma estrutura chamada processos. Os processos são independentes entre si e tem seus próprios recursos, como espaço em memória. O sistema operacional é inteligente o suficiente para gerenciar esses processos de forma simultânea usando um escalonador preemptivo. O fato de cada processo ter seu próprio espaço na memória permite que o sistema operacional lide com eles de forma concorrente. Ele consegue fazer trocas de contexto (context switch), aumentando a eficiência no uso da CPU.

Exemplo: você está assistindo a um vídeo no YouTube, editando um texto no LibreOffice e recebendo mensagens no seu Telegram, cada tarefa dessa é um processo.

Sua CPU tem múltiplos núcleos, mas você provavelmente tem dezenas de processos ativos. O sistema operacional faz a troca de contexto entre esses processos em questão de milissegundos, salvando o estado do processo atual e carregando o de outro.

É possivel listar os processos ativos do seu sistema com o comando top.

Segundo o manual (man top): The top program provides a dynamic real-time view of a running system.

Cada processo possui um estado próprio e é identificado por um PID (Process ID). O sistema operacional reconhece os processos como uma unidade de concorrência. Os processos também podem se comunicar entre si por meio de IPC (Inter-Process Communication), um conjunto de mecanismos que permite essa troca de informações.

É possível criar um processo filho por meio da syscall clone do sistema operacional.

O que é uma syscall? é um mecanismo pelo qual um programa de computador solicita serviços ao kernel do sistema operacional no qual ele está sendo executado

Quando essa chamada é executada, o processo pai é clonado, e um novo processo filho é criado com uma cópia do seu espaço de memória, fila de execução e descritores de arquivos, tudo isso dependendo dos parâmetros passados à syscall.

Segue a documentação da syscall clone diretamente do manual Linux https://man7.org/linux/man-pages/man2/clone3.2.html

Vamos criar um processo filho a partir de um processo pai utilizando fork em Ruby.

puts "Processo pai: PID = #{Process.pid}"

pid = fork do
  puts "Processo filho: PID = #{Process.pid}, PPID = #{Process.ppid}"
  sleep 2
  puts "Processo filho terminou."
end

puts "Processo pai continua executando..."
Process.wait(pid)
puts "Processo pai terminou após o filho."

Saida

Processo pai: PID = 2864854
Processo pai continua executando...
Processo filho: PID = 2864890, PPID = 2864854
Processo filho terminou.
Processo pai terminou após o filho.
=> nil

O processo pai imprime seu próprio PID e, em seguida, cria um processo filho usando fork. O filho imprime seu PID e o do pai (PPID), simulando uma tarefa demorada com sleep. Enquanto isso, o pai continua executando, aguarda a finalização do filho com Process.wait, e só então encerra sua execução.

É possivel que um processo filho se comunique com o processo principal através de mensagens (pipe), no ruby conseguimos fazer essa comunicação usando IO.pipe

reader, writer = IO.pipe

pid = fork do
  reader.close
  writer.puts "Olá do processo filho!"
  writer.close
end

writer.close
mensagem = reader.gets
puts "Pai recebeu: #{mensagem}"
reader.close

Process.wait(pid)

Saída

Pai recebeu: Olá do processo filho!
=> 2866592

Threads

Agora que falamos um pouco sobre processos, vamos falar das threads. Threads são como "partes" de um processo, elas compartilham os mesmos recursos como a memória com o processo principal e com outras threads do mesmo processo. Enquanto um processo é um contêiner que possui memória, recursos e ao menos uma thread, as threads são unidades de execução dentro desse contêiner, trabalhando de forma colaborativa no mesmo espaço de memória.

As threads são úteis quando queremos executar múltiplas tarefas simultaneamente dentro de um único processo, oferecendo uma forma leve e eficiente de alcançar a tão desejada concorrência.

Vamos escrever um programa que cria 4 threads que executam um cálculo de raiz quadrada.

Cada thread calcula a soma das raízes quadradas dos números de 0 até 99.999.999, totalizando 400 milhões de operações (Sim é bastante coisa). O programa utiliza a biblioteca Benchmark para medir e exibir o tempo total gasto para que todas as threads concluam o processamento.

require 'benchmark'
require 'date'

NUM_THREADS = 4
WORK_PER_THREAD = 100_000_000

def trabalho_pesado(pid)
  total = 0
  WORK_PER_THREAD.times do |i|
    total += Math.sqrt(i)
  end

  puts "Thread #{pid} terminou! #{DateTime.now}"
  total
end

puts "Iniciando benchmark com #{NUM_THREADS} threads... em #{DateTime.now}"
tempo = Benchmark.realtime do
  threads = NUM_THREADS.times.map do

    Thread.new do
      pid = Thread.current.object_id
      puts "Thread trabalhando: #{pid}"
      trabalho_pesado(pid)
    end
  end
  threads.each(&:join)
end

puts "Tempo total: #{tempo.round(2)} segundos"

Saída

Iniciando benchmark com 4 threads... em 2025-05-18T12:15:31-03:00
Thread trabalhando: 31440
Thread trabalhando: 31460
Thread trabalhando: 31480
Thread trabalhando: 31500
Thread 31500 terminou! 2025-05-18T12:16:04-03:00
Thread 31500 terminou! 2025-05-18T12:16:05-03:00
Thread 31500 terminou! 2025-05-18T12:16:05-03:00
Thread 31500 terminou! 2025-05-18T12:16:05-03:00
Tempo total: 34.12 segundos
=> nil

Nosso programa levou 34,12 segundos para executar todas essas operações. Pode parecer rápido, mas ainda podemos melhorar. Nesse caso, usamos concorrência para dividir a carga em 4 threads, que trabalham de forma concorrente, mas não em paralelo. Por que não em paralelo? Será que Ruby não escala?

O MRI utiliza um mecanismo chamado GIL (Global Interpreter Lock), que garante que apenas uma thread Ruby execute código Ruby por vez, mesmo em máquinas com múltiplos núcleos. Ou seja, o MRI não é thread safe em nível interno para algumas operações. O GIL impede que múltiplas threads executem código Ruby simultaneamente, evitando problemas de concorrência no gerenciamento de memória e objetos.

Agora, o que faremos é mudar o interpretador. Até aqui usamos o padrão MRI para os testes, mas vamos migrar para uma implementação que roda sobre a máquina virtual Java, o JRuby. Esse interpretador permite o paralelismo real entre threads, o que pode melhorar o desempenho nesse caso.

Vamos mudar a versão do Ruby usando o gerenciador rbenv.

rbenv global jruby-9.4.8.0
ruby --version

Saída

jruby 9.4.8.0 (3.1.4) 2024-07-02 4d41e55a67 OpenJDK 64-Bit Server VM 11.0.26+4-post-Ubuntu-1ubuntu122.04 on 11.0.26+4-post-Ubuntu-1ubuntu122.04 +jit [x86_64-linux

Agora que mudamos o interpretador para JRuby, vamos executar o mesmo código novamente. E o resultado é bem diferente...

Iniciando benchmark com 4 threads... em 2025-05-18T12:24:29-03:00
Thread trabalhando: 4004
Thread trabalhando: 4000
Thread trabalhando: 4008
Thread trabalhando: 4012
Thread 4012 terminou! 2025-05-18T12:24:43-03:00
Thread 4000 terminou! 2025-05-18T12:24:43-03:00
Thread 4008 terminou! 2025-05-18T12:24:43-03:00
Thread 4004 terminou! 2025-05-18T12:24:43-03:00
Tempo total: 13.48 segundos

Nosso programa, interpretado pelo JRuby, levou apenas 13,48 segundos para realizar os 400 milhões de cálculos. Isso representa uma execução aproximadamente 2,5 vezes mais rápida, ou cerca de 60,5% de ganho em desempenho em comparação com o MRI. Essa diferença acontece porque o JRuby consegue aproveitar os múltiplos núcleos do processador (A Java Virtual Machine é thread safe), aplicando paralelismo real entre as threads do programa.

Isso quer dizer que, para esse programa, precisamos mudar de interpretador para usar paralelismo? Não necessariamente. Podemos continuar usando o MRI e ainda assim aproveitar múltiplos núcleos através do uso de fork. Isso porque o fork cria um novo processo, independente do pai, com sua própria memória, seu próprio GIL e sua própria thread principal. Como cada processo é isolado, o sistema operacional pode executá-los em paralelo real, os distribuindo entre os núcleos da CPU.

Vamos mudar para ruby padrão usando rbenv

rbenv global 3.3.5
ruby --version

Saída

ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux]

Vamos executar o programa usando fork

require 'benchmark'

NUM_PROCESSES = 4
WORK_PER_PROCESS = 100_000_000

def trabalho_pesado
  total = 0
  WORK_PER_PROCESS.times do |i|
    total += Math.sqrt(i)
  end
  total
end

puts "Iniciando benchmark com #{NUM_PROCESSES} processos (fork)..."

tempo = Benchmark.realtime do
  pids = []

  NUM_PROCESSES.times do |i|
    pid = fork do
      puts "[Filho ##{i}] PID: #{Process.pid}, Pai: #{Process.ppid}"
      trabalho_pesado
      exit!
    end
    pids << pid
  end

  pids.each { |pid| Process.wait(pid) }
end

puts "Tempo total: #{tempo.round(2)} segundos"

Saída

[Filho #0] PID: 2881532, Pai: 2881489
[Filho #1] PID: 2881535, Pai: 2881489
[Filho #2] PID: 2881538, Pai: 2881489
[Filho #3] PID: 2881541, Pai: 2881489
Tempo total: 8.74 segundos

No final esse foi o resultado dos nossos testes

Teste	Interpretador	Abordagem	Tempo
Teste 1	MRI	Threads	34.12 s
Teste 2	JRuby	Threads	13.48 s
Teste 3	MRI	Fork	8.74 s

Teste 3 foi ~3,9 vezes mais rápido e teve um ganho de ~74,4% sobre o Teste 1 e ~1,5 vezes mais rápido e teve um ganho de ~35,2% sobre o Teste 2.

Race condition

Agora vamos falar sobre um problema bastante comum quando tratamos de concorrência, o race condition. Sabemos que as threads são executadas de forma concorrente, mas como não controlamos a ordem em que elas são executadas, isso fica a cargo do escalonador preemptivo do sistema operacional. Ou seja, quando executamos uma tarefa com múltiplas threads que dependem da ordem de execução, temos o risco de enfrentar uma race condition. Para exemplificar, vamos rodar o código abaixo usando o Ruby padrão (MRI) e o JRuby, assim como nos exemplos anteriores. O programa cria 10 threads e cada uma incrementa a variável contador 1000 vezes. Esperamos que o valor final seja 10000.

contador = 0

threads = 10.times.map do
  Thread.new do
    1000.times do
      contador += 1
    end
  end
end

threads.each(&:join)
puts "O valor final deve ser 10000"
puts "Valor final do contador: #{contador}"

Saída usando MRI (Versão do ruby 3.3.5)

O valor final deve ser 10000
Valor final do contador: 10000

Saída usando JRuby (Versão jruby-9.4.8.0)

O valor final deve ser 10000
Valor final do contador: 9451

Perceba que a saída com JRuby não retornou a contagem de 10000 e sim 9451, executando outra vez:

O valor final deve ser 10000
Valor final do contador: 8800

No MRI (CRuby), mesmo utilizando múltiplas threads nativas do sistema operacional, existe um bloqueio global chamado GVL (Global VM Lock) que garante que apenas uma thread execute código Ruby por vez na CPU, evitando assim condições de corrida (race conditions) em operações concorrentes sobre variáveis compartilhadas. Esse lock global limita o paralelismo de CPU, liberando-o apenas em operações de I/O ou chamadas de código nativo, o que explica por que o exemplo com múltiplas threads incrementando uma variável compartilhada sempre retorna o valor correto no MRI, ao contrário do que acontece em outras implementações como JRuby que não possuem esse bloqueio global.

Conclusão

Ruby é realmente fantástico, não é? Ele conta com gems (Gem são as bibliotecas de ruby) especializadas para paralelismo, como a gem parallel, que facilita o uso de múltiplos processos. Além disso, Ruby oferece APIs nativas para a criação de threads, que funcionam muito bem em tarefas de I/O concorrente. É importante lembrar que criar múltiplas threads ou usar fork pode aumentar a complexidade no gerenciamento dos recursos e do fluxo do programa, exigindo cuidado na implementação. Ou seja, não existe uma bala de prata para todas as situações, pois a melhor abordagem depende do contexto e dos objetivos do projeto. Por aqui aprendemos como Ruby lida com processos forkados e threads, a comunicação entre processos e entendemos o risco das race conditions, que acontecem quando recursos compartilhados são acessados sem a devida sincronização.

Referências

https://concorrencia101.leandronsp.com/

https://www.akitaonrails.com/2019/03/13/akitando-43-concorrencia-e-paralelismo-parte-1-entendendo-back-end-para-iniciantes-parte-3

https://www.toptal.com/ruby/ruby-concurrency-and-parallelism-a-practical-primer

https://apidock.com/ruby/Process/fork/class

https://www.rubyguides.com/2015/07/ruby-threads/

https://linuxjourney-com.translate.goog/lesson/monitor-processes-ps-command?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt&_x_tr_pto=tc

https://man7.org/linux/man-pages/man2/syscalls.2.html

DEV Community: Michael Alves

Cloud Spanner: tentando entender o que ele resolve e brincando com o emulador local

Sumário

Por que o Spanner existe...

Bancos relacionais

Transações ACID

Consistência e escalabilidade global

Bancos NoSQL

Distribuição pelo mundo

Como ele resolve esses problemas?

1. Replicação utilizando Paxos

2. Transações distribuídas

3. TrueTime

4. Commit Wait

Emulando o Cloud Spanner com cloud-spanner-emulator

O que ele faz?

Conector do Spanner para Active Record

Ferramenta para testes de carga

Conclusão

Referências

Implementando um Sistema de Ranking com Rating Elo em Ruby

Rating Elo e o filme A Rede Social

Porque usar essa equação para ranquear?

Vamos implementar a equação

Ranqueando jogadores

Rodada 1 — Grande surpresa

Rodada 2 — Resultado esperado

Rodada 3 — Empate surpreendente

Conclusão

Referências

Concorrência e Paralelismo em Ruby

Ruby: Uma Linguagem Amigável e Elegante

Processos

Threads

Race condition

Conclusão

Referências

Emulando o Cloud Spanner com `cloud-spanner-emulator`