Em ambientes de aplicação modernos construídos com Midway.js, TypeScript e TypeORM, o desempenho e a disponibilidade do banco de dados são fatores cruciais para o sucesso. A estratégia de separação de leitura e escrita (read/write splitting) é uma técnica fundamental para escalar sistemas que enfrentam altas cargas de tráfego. Este artigo explora dez técnicas avançadas para implementar e otimizar a separação de leitura e escrita em suas aplicações baseadas em Midway.js e TypeORM, visando um acesso a dados de alto desempenho.

A Necessidade da Separação de Leitura e Escrita

Bancos de dados frequentemente se tornam o gargalo de desempenho em aplicações de grande escala. Embora configurações padrão utilizem uma única fonte de dados, o crescimento do volume de transações e consultas torna a separação de leitura e escrita uma escolha estratégica:

1. Aumento do Desempenho de Leitura: Distribui operações de consulta entre múltiplos servidores replicados (réplicas ou "slaves").
2. Melhora da Estabilidade de Escrita: O servidor principal (mestre) pode focar exclusivamente nas operações de escrita, minimizando contenções.
3. Maior Disponibilidade do Sistema: Falhas em servidores replicados não afetam a capacidade do mestre de processar escritas.
4. Balanceamento de Carga Eficiente: Distribui a pressão do banco de dados de forma mais equitativa.

Configuração Essencial: Separação com TypeORM

O TypeORM, uma das ORMs mais populares para TypeScript, oferece suporte nativo à configuração de replicação. Para implementar a separação de leitura e escrita em um projeto Midway.js, ajuste o arquivo de configuração de ambiente (ex: src/config/config.prod.ts) da seguinte forma:

export default {
  typeorm: {
    dataSource: {
      default: {
        type: 'mysql',
        replication: {
          master: {
            host: 'host-principal-bd',
            port: 3306,
            username: 'usuario_mestre',
            password: 'senha_mestre',
            database: 'minha_aplicacao',
          },
          slaves: [{
            host: 'host-replicado-1',
            port: 3306,
            username: 'usuario_replicado',
            password: 'senha_replicado',
            database: 'minha_aplicacao',
          }, {
            host: 'host-replicado-2',
            port: 3306,
            username: 'usuario_replicado',
            password: 'senha_replicado',
            database: 'minha_aplicacao',
          }]
        },
        synchronize: false,
        logging: ['query', 'error'],
        charset: 'utf8mb4',
        cache: true,
        entities: ['src/entity/**/*.ts'], // Ajuste conforme a estrutura do seu projeto
        // subscribers: [], // Adicione subscribers se necessário
      },
    },
  },
};

1. Estratégias de Múltiplas Fontes de Dados

Para cenários mais complexos ou modulares, pode ser benéfico configurar múltiplas fontes de dados independentes. O Midway.js, com sua injeção de dependência, permite registrar e gerenciar várias instâncias de DataSource. Isso é útil quando diferentes módulos da aplicação precisam de configurações de banco de dados distintas, talvez para bancos de dados completamente separados ou para um controle mais granular da replicação.

Por exemplo, você pode configurar uma fonte de dados para operações gerais com replicação e outra, exclusiva para um módulo de relatórios, que sempre lê de uma réplica específica ou de um banco de dados de data warehousing.

import { Inject, Provide } from '@midwayjs/core';
import { DataSource } from 'typeorm';

@Provide()
export class ServicoDados {
  // Injeta a fonte de dados padrão (com replicação configurada)
  @Inject('dataSourceManager')
  private defaultDataSource: DataSource;

  // Se você tivesse outra fonte de dados chamada 'reportingDb'
  // @Inject('dataSourceManager.reportingDb')
  // private reportingDataSource: DataSource;

  async buscarDadosPrincipais() {
    return this.defaultDataSource.query('SELECT * FROM alguma_tabela');
  }

  // ... outros métodos usando defaultDataSource ou outras fontes de dados
}

2. Separação Explícita de Operações

É uma boa prática garantir que as operações de leitura e escrita sejam explicitamente direcionadas para os servidores apropriados. Embora o TypeORM com a configuração replication tente gerenciar isso automaticamente (leituras para réplicas, escritas para o mestre), é importante estar ciente de como o controle funciona:

• Consultas (SELECT): Por padrão, serão direcionadas a uma das réplicas disponíveis para distribuir a carga.
• Modificações (INSERT, UPDATE, DELETE): Sempre serão encaminhadas ao servidor mestre para garantir a consistência dos dados.
• Transações: Devem ser executadas integralmente no servidor mestre. Iniciar uma transação em uma réplica geralmente não é permitido ou não faz sentido, pois a transação implica modificações.

3. Otimização do Pool de Conexões

A configuração do pool de conexões é vital para o desempenho e a robustez da aplicação. Em aplicações usando mysql2 como driver, o TypeORM permite configurar o pool. Ajuste o tamanho do pool e o comportamento da fila para evitar esgotamento de conexões e gerenciar picos de requisições:

export default {
  typeorm: {
    dataSource: {
      default: {
        // ... outras configurações ...
        extra: {
          connectionLimit: 20, // Aumente conforme a demanda de concorrência
          queueLimit: 0, // 0 para fila ilimitada ou defina um limite
          enableKeepAlive: true, // Mantém as conexões ativas
          keepAliveInitialDelay: 0,
        },
      },
    },
  },
};

4. Mecanismo de Failover Automatizado

Em ambientes de produção, é essencial ter um mecanismo de failover robusto para garantir a alta disponibilidade. Isso envolve:

• Verificação de Saúde (Health Checks): Monitore proativamente o status de cada servidor de banco de dados (mestre e réplicas).
• Comutação Automática: Em caso de falha de uma réplica, o sistema deve ser capaz de redirecionar as consultas para outras réplicas saudáveis ou, em último caso, para o mestre (se a falha for em uma réplica). Falha do mestre exige um processo de promoção de réplica a mestre.
• Estratégia de Reaplicação: Implemente lógicas de retry para requisições de banco de dados que falhem temporariamente devido a problemas de conexão ou indisponibilidade, usando estratégias como backoff exponencial.

5. Monitoramento e Alertas Proativos

Um sistema de monitoramento eficaz é crucial para identificar e resolver problemas rapidamente. Para configurações de separação de leitura e escrita, monitore:

• Latência de Replicação: Garanta que a replicação entre o mestre e as réplicas esteja dentro de limites aceitáveis para manter a consistência dos dados.
• Contagem de Conexões: Monitore o número de conexões ativas e em pool para evitar esgotamento e identificar vazamentos.
• Desempenho de Consultas: Rastreie consultas lentas e o tempo médio de resposta para leituras e escritas para otimizar índices e queries.

6. Garantia da Consistência dos Dados

A separação de leitura e escrita introduz o desafio da consistência dos dados, especialmente a "consistência eventual". Para gerenciar isso:

• Leitura Forçada do Mestre: Para operações que exigem consistência imediata (ex: verificação de saldo após uma transação), force a leitura diretamente do servidor mestre. O TypeORM permite isso usando .useMasterDataSource() em suas queries.
• Tolerância à Latência: Para dados que podem ter uma pequena defasagem, estabeleça uma tolerância aceitável à latência da replicação.
• Camadas de Cache: Utilize caches (ex: Redis) para dados frequentemente acessados, reduzindo a carga do banco de dados e a dependência da consistência em tempo real para algumas leituras.

7. Combinação com Fragmentação de Dados (Sharding)

Quando a separação de leitura e escrita não é suficiente para a escala, a fragmentação de dados pode ser combinada. Isso envolve dividir o banco de dados horizontalmente:

• Fragmentação por Domínio: Separe bancos de dados por módulos ou domínios de negócio (ex: um BD para usuários, outro para pedidos).
• Particionamento Temporal: Divida tabelas grandes com base no tempo (ex: dados de log de cada mês em uma tabela diferente).
• Distribuição Geográfica: Mantenha dados de usuários em data centers próximos a eles para menor latência, replicando apenas o necessário globalmente.

8. Otimização do Tratamento de Transações

Transações são fundamentais para garantir a atomicidade das operações. No TypeORM, o controle explícito de transações é realizado através de QueryRunner. Sempre execute transações no servidor mestre. Um tratamento robusto de transações deve incluir controle de erros e liberação de recursos:

import { Injectable, Inject } from '@midwayjs/core';
import { DataSource } from 'typeorm';

@Injectable()
export class ServicoTransacao {
  @Inject()
  private conexaoBD: DataSource;

  async executarOperacaoTransacional() {
    const executorTransacao = this.conexaoBD.createQueryRunner();
    await executorTransacao.connect();
    
    try {
      await executorTransacao.startTransaction();
      
      // Exemplo de operações dentro da transação
      await executorTransacao.manager.save('Entidade1', { /* dados */ });
      await executorTransacao.manager.update('Entidade2', { id: 1 }, { /* novos dados */ });
      
      await executorTransacao.commitTransaction();
      console.log('Transação concluída com sucesso.');

    } catch (erro) {
      await executorTransacao.rollbackTransaction();
      console.error('Transação falhou, realizando rollback:', erro);
      throw erro; // Re-lança o erro para ser tratado pela camada superior
    } finally {
      await executorTransacao.release(); // Sempre libere o QueryRunner
    }
  }
}

9. Testes de Desempenho e Ajustes

Após a implementação da separação de leitura e escrita, é imperativo realizar testes abrangentes para validar a eficácia e identificar gargalos:

• Testes de Carga: Simule cenários de alta concorrência para avaliar o comportamento do sistema sob estresse, medindo o desempenho de leituras e escritas.
• Testes de Referência (Benchmark): Estabeleça uma linha de base de desempenho antes e depois da implementação para quantificar os ganhos.
• Testes A/B: Compare diferentes configurações de replicação ou estratégias de pool de conexões para determinar a mais eficiente para seu caso de uso.

10. Implantação e Operação

A implantação de uma arquitetura com separação de leitura e escrita requer considerações adicionais de operação:

• Conteinerização (Docker): Utilize ferramentas como docker-compose.yml para orquestrar facilmente múltiplos contêineres de banco de dados (mestre e réplicas) em ambientes de desenvolvimento e produção.
• Gerenciamento de Configuração: Utilize sistemas de gerenciamento de configuração (como variáveis de ambiente, HashiCorp Vault ou Kubernetes Secrets) para diferenciar configurações de banco de dados entre ambientes de desenvolvimento, teste e produção.
• Estratégias de Backup: Implemente rotinas de backup robustas, idealmente realizando backups tanto do servidor mestre quanto das réplicas, e teste a recuperação periodicamente.