Introdução

Em sistemas distribuídos, um ID globalmente único é um componente fundamental. Entidades como pedidos, usuários e logs necessitam de um identificador que seja simultaneamente único e rastreável. No entanto, a natureza "multi-nós e sem centro" de ambientes distribuídos apresenta três desafios principais na geração de IDs:

1. Unicidade Global: IDs duplicados devem ser evitados a todo custo (por exemplo, IDs de pedido duplicados podem causar inconsistências nos dados).
2. Ordem: Certos cenários exigem que os IDs sejam incrementados sequencialmente com base no tempo ou na lógica de negócios (por exemplo, para otimizar índices de banco de dados).
3. Alto Desempenho: A geração de IDs em cenários de alta concorrência não pode se tornar um gargalo (por exemplo, um cenário de leilão rápido pode exigir mais de 100.000 IDs por segundo).

Este artigo explora três abordagens populares para geração de IDs distribuídos: Leaf-segment (Meituan), UUID (Identificador Único Universal) e uma versão aprimorada do Snowflake (como Leaf-Snowflake). Compararemos seus princípios, performance, vantagens e desvantagens, e através de testes de QPS e análise de impacto em índices, ajudaremos você a escolher a melhor solução para suas necessidades de negócio.

Necessidades Essenciais e Dimensões de Design para IDs Distribuídos

Ao projetar uma solução de ID distribuído, é crucial considerar as seguintes dimensões:

Leaf-segment: Solução Robusta com Segmentos em Cache para Evitar Problemas de Relógio

Leaf-segment é uma solução de ID distribuído de código aberto da Meituan. Sua abordagem principal é a "pré-alocação de segmentos de ID no banco de dados + cache local". Isso resolve o problema de retrocesso do relógio visto em implementações tradicionais do Snowflake, garantindo ao mesmo tempo um alto QPS.

Princípio: Cache de Segmento e Prevenção de Retrocesso do Relógio

A lógica central do Leaf-segment é "pré-alocar um segmento de IDs e usá-los gradualmente localmente":

1. Pré-alocação no Banco de Dados: O serviço de geração de ID obtém um segmento contínuo de IDs do banco de dados (por exemplo, ID inicial = 1000, passo = 10000).
2. Cache Local: O segmento de ID pré-alocado é armazenado em cache na memória do serviço. Solicitações subsequentes buscam IDs diretamente do cache.
3. Mecanismo de Renovação: Quando o cache de ID se esgota, um novo segmento de ID é solicitado ao banco de dados.
4. Tratamento de Retrocesso do Relógio: Se o relógio do servidor retroceder, os IDs pré-alocados (que são para o "futuro") não entrarão em conflito (por exemplo, se o relógio voltar para ontem, os IDs em uso hoje são do futuro, evitando conflitos).

Estrutura da Tabela do Banco de Dados:

CREATE TABLE `leaf_alloc` (
 `biz_tag` varchar(128) NOT NULL COMMENT 'Tag de negócio (ex: order, user)',
 `max_id` bigint(20) NOT NULL COMMENT 'ID máximo atual',
 `step` int(11) NOT NULL COMMENT 'Passo de pré-alocação',
 `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 

Performance e Vantagens/Desvantagens

• QPS: Cache local + pré-alocação em lote permitem um QPS de mais de 100.000/segundo (Ambiente de teste: servidor 4核8G, MySQL 8.0).
• Vantagens:
  1. Globalmente único e ordenado (IDs incrementam de acordo com o passo de pré-alocação).
  2. Resolve retrocesso do relógio (segmentos pré-alocados não são afetados por problemas de relógio).
  3. Alta disponibilidade (em caso de falha do banco de dados, o cache local ainda pode suportar por um tempo).
• Desvantagens:
  1. Depende do banco de dados (se o banco de dados cair, a renovação de ID não é possível).
  2. O passo de pré-alocação deve ser definido razoavelmente (muito pequeno leva a consultas frequentes ao banco de dados, muito grande pode desperdiçar IDs).

UUID: Solução Simples e Rápida, Porém Desordenada

UUID é uma solução de ID distribuído fornecida pela biblioteca padrão Java (UUID.randomUUID()). Ele gera um ID globalmente único de 128 bits baseado em números aleatórios + timestamp + endereço MAC.

Princípio: Geração de ID Desordenado via Números Aleatórios

A lógica de geração de UUID é:

1. Gera 16 bytes de números aleatórios.
2. Combina informações como timestamp (60 bits) e endereço MAC (48 bits) para gerar um ID único de 128 bits.
3. Formata-o como uma string de 36 caracteres (ex: 550e8400-e29b-41d4-a716-446655440000).

Performance e Vantagens/Desvantagens

• QPS: Gerado localmente, sem requisições de rede, o QPS pode chegar a mais de 1 milhão/segundo (Ambiente de teste: servidor 4核8G, JDK 17).
• Vantagens:
  1. Simples e fácil de usar (gerado com uma linha de código).
  2. Absolutamente único (com um espaço de 128 bits, a prboabilidade de colisão é extremamente baixa).
  3. Sem dependência centralizada (gerado localmente, sem necessidade de banco de dados ou serviço).
• Desvantagens:
  1. Desordem: IDs gerados aleatoriamente causam divisão de páginas de índice em árvores B+ durante a inserção no banco de dados, reduzindo a performance de escrita em 30%-50% (comparado a IDs ordenados).
  2. Alto Ocupação de Armazenamento: Uma string de 36 caracteres é 4 vezes maior que o tipo Long (8 bytes).
  3. Baixa Legibilidade: Informações de negócio (como tempo ou ID da máquina) não podem ser extraídas do ID.

Snowflake Aprimorado: Solução Equilibrada com Ordem e Alta Disponibilidade

Snowflake é uma solução de ID distribuído de código aberto do Twitter. Sua lógica principal é gerar IDs ordenados usando timestamp + ID da máquina + número de série. No entanto, a versão original apresenta problemas como retrocesso do relógio e complexidade na alocação do ID da máquina. A equipe do Meituan Leaf aprimorou-a (Leaf-Snowflake).

Pontos de Aprimoramento: Tratamento de Retrocesso do Relógio e Alocação de ID da Máquina

Os principais aprimoramentos do Leaf-Snowflake incluem:

1. Tratamento de Retrocesso do Relógio:
   • Registra o timestamp da última geração de ID (lastTimestamp).
   • Se o timestamp atual for menor que lastTimestamp (retrocesso do relógio), o sistema aguarda até que o tempo passe lastTimestamp antes de gerar o próximo ID (evitando duplicatas).
2. Alocação de ID da Máquina:
   • Usa ZooKeeper ou banco de dados para alocar IDs de máquina (por exemplo, cada instância de serviço solicita um ID único ao ZooKeeper durante a inicialização).
   • Evita o incômodo da configuração manual de IDs de máquina.
3. Ciclo do Número de Série:
   • O número de série (12 bits) é redefinido diariamente (evitando overflow), suportando geração de IDs de mais de 1 milhão/segundo por máquina.

Performance e Vantagens/Desvantagens

• QPS: Um único nó pode atingir mais de 100.000/segundo (Ambiente de teste: servidor 4核8G, ZooKeeper 3.7).
• Vantagens:
  1. Globalmente único e ordenado (IDs incrementam com base no timestamp).
  2. Alta disponibilidade (sem dependência centralizada, IDs de máquina alocados automatciamente).
  3. Armazenamento eficiente (tipo Long, 8 bytes).
• Desvantagens:
  1. Depende do ZooKeeper ou banco de dados (a alocação de ID da máquina requer um serviço externo).
  2. O retrocesso do relógio requer espera (em casos extremos, pode causar latência na geração de IDs). Comparativo de Performance e Seleção de Cenários

Comparativo de QPS e Ordenação

Árvore de Decisão para Seleção de Cenários

Use a seguinte árvore de decisão para escolher a melhor solução:

1. É necessário que os IDs sejam ordenados?
   ├─ Sim (ex: IDs de pedido, IDs de usuário, para otimizar índices de banco de dados) → Vá para 2
   └─ Não (ex: IDs de log, traceIDs, apenas unicidade é necessária) → Vá para 3

2. É necessária alta disponibilidade e evitar retrocesso do relógio?
   ├─ Sim (ex: negócios centrais de e-commerce) → Leaf-segment ou Leaf-Snowflake
   └─ Não (ex: sistemas internos onde a espera pelo retrocesso do relógio é aceitável) → Leaf-Snowflake

3. É necessário geração local e performance máxima?
   ├─ Sim (ex: coleta de logs, computação de borda) → UUID
   └─ Não (ex: gerenciamento centralizado é necessário) → Leaf-segment
  

Conclusão

• Leaf-segment: Adequado para cenários de negócios principais que exigem ordem, alto QPS e alta disponibilidade (ex: IDs de pedido). Resolve o retrocesso do relógio através de cache de segmento, dependendo do banco de dados, mas oferece alta estabilidade.
• UUID: Adequado para cenários que exigem geração local, performance máxima e onde a ordem não é crucial (ex: IDs de log). No entanto, sua desordem afeta a indexação do banco de dados.
• Leaf-Snowflake: Adequado para cenários que exigem ordem, geração distribuída e sem dependência centralizada (ex: IDs de usuário). A versão aprimorada resolve os problemas de retrocesso do relógio e alocação de ID da máquina.

Referências:

• Projeto Leaf de código aberto: Meituan Leaf
• Especificação UUID: RFC 4122
• Algoritmo Snowflake: Twitter Snowflake

Apêndice: Dados de Teste de QPS para Leaf-segment e Leaf-Snowflake

• Ambiente de Teste: Servidor 4核8G, MySQL 8.0, JDK 17.
• Leaf-segment: Passo de pré-alocação = 10000, QPS = 123.000/segundo.
• Leaf-Snowflake: Cluster ZooKeeper = 3 nós, QPS = 118.000/segundo.
• UUID: UUID.randomUUID(), QPS = 1.050.000/segundo.

Com base na análise acima, você pode selecionar a solução mais adequada às suas necessidades de negócio: escolha Leaf-segment ou Snowflake para ordenação, e UUID para velocidade, encontrando o equilíbrio entre unicidade, ordem e performance.