Como um mecanismo de pesquisa distribuído, o ES é incomparável em termos de capacidade de expansão e recursos de pesquisa. No entanto, ele tem seus próprios pontos fracos. Como sistema de armazenamento quase em tempo real, seus princípios de design de fragmentação e replicação também o tornam incapaz de competir com o OLTP. (Online Transaction Processing) em termos de latência e consistência de dados.
Por causa disso, seus dados geralmente são sincronizados de outros sistemas de armazenamento para filtragem e análise secundárias. Isso introduz um nó chave, ou seja, o método de gravação síncrona de dados ES. Este artigo apresenta o método ES síncrono do MySQL.
Ao escrever dados MySQL no ES, a primeira coisa que vem à mente é consumir o Binlog e escrever diretamente no ES. No entanto, se você considerar mais dimensões, encontrará algumas desvantagens deste método. Portanto, existe outra maneira, ou seja, ecologia integrada
[RocketMQ
+ Flink Consumer + ES Bulk]. Avaliaremos esses dois métodos de acesso a partir de quatro aspectos: atraso de sincronização, características de consumo, desempenho de gravação ES e tolerância a desastres do sistema . que Inspire a todos e escolha o método de sincronização mais adequado ao seu negócio.
Princípios básicos de escrita ES
A gravação ES é um processo de gravação do tipo apêndice que primeiro forma segmentos de um tamanho específico e, em seguida, mescla periodicamente pequenos segmentos de dados em grandes segmentos de dados para reduzir a fragmentação da memória e melhorar a eficiência da consulta. Um índice consiste em N fragmentos e suas cópias. Ele armazena documentos do mesmo tipo. Seu método de indexação é definido por Mapeamento. Cada fragmento é composto por N segmentos. unidade de processamento do segmento ES é a menor unidade de processamento de dados do ES, e cada segmento é um índice invertido independente.
A gravação ES, na verdade, grava dados continuamente no mesmo segmento (memória) e, em seguida, aciona a atualização para atualizar o segmento no cache do sistema operacional (padrão 1s). Neste momento, os dados podem ser consultados e o cache do sistema operacional acionará o Flush pelo sistema operacional. . As operações são persistidas no disco.
Faz você pensar: como o ES garante que os dados não sejam perdidos? Quais são as vantagens e desvantagens da escrita de anexos? Como a gravação de anexos lida com problemas de atualização de dados? A qual método de escrita o MySQL pertence? O foco deste artigo não está aqui, você pode ler o artigo separadamente.
Conceitos básicos de ES
ES gravação direta
A vantagem de usar a gravação de conexão direta ES é que o caminho é curto e há poucos componentes dependentes. Além disso, o Dsyncer (sistema de conversão de armazenamento heterogêneo) geralmente fornece um mecanismo completo de nova tentativa de limitação de corrente, portanto, o atraso no consumo e a integridade dos dados de consumo são ambos. Garantido.
deficiência:
-
Não é fácil acessar a implantação de recuperação de desastres em salas de vários computadores. Atualmente, as salas de computadores de recuperação de desastres ES são todas implantadas de forma independente e em modo de leitura e gravação independente. várias salas de computadores ao mesmo tempo, e o efeito de recuperação de desastres não será alcançado. Binlog-->Dsyncer Normalmente uma tabela MySQL corresponde a uma tarefa de conversão. Se você iniciar múltiplas tarefas de conversão repetidas para escrever múltiplas salas de computadores, isso parece um pouco estúpido.
-
Se o seu próprio cenário de negócios envolve gravação simultânea do mesmo registro, mas nem todas as gravações vêm do Binlog, é mais provável que você encontre conflitos de gravação se você considerar a gravação direta no ES globalmente, porque não há garantia de uma fila ordenada.
Construa um sistema integrado ES através do Flink
Flink constrói um sistema integrado ES, o que significa que todas as gravações ES são concluídas por tarefas Flink monitora fluxos de dados em tempo real do RocketMQ, o que não apenas garante a ordem das partições de dados, mas também faz uso total dos recursos de gravação em lote do ES. A capacidade de gravação em lote é muitas vezes maior do que o desempenho de gravação única. Ao mesmo tempo, devido à tolerância a falhas do próprio Flink, a consistência final dos dados pode ser garantida mesmo em cenários anormais.
vantagem
:
-
O MQ pode ser usado para acessar clusters ES de salas de várias máquinas mais rapidamente e as gravações são desacopladas. Os consumidores nas três salas de computadores gravam dados independentemente um do outro . Quando uma única sala de computadores falha, desde que haja uma sala de computadores disponível. o tráfego de leitura será cortado diretamente. Sim, o plano de recuperação de desastres é simples e claro ;
-
Quando problemas como tremores de rede fazem com que o ES falhe temporariamente na gravação, o RocketMQ armazenará temporariamente a mensagem sem afetar a gravação de outros clusters, e o Flink salvará o instantâneo de consumo e continuará tentando novamente até obter sucesso, o que garante melhor a consistência final dos dados sexo ;
-
A gravação de diversas fontes de dados pode garantir a consistência global da partição.
deficiência
:
-
Depender de mais componentes aumentará o atraso de sincronização de dados de todo o link, e a frequência de atualização padrão do ES é uma vez por segundo. Após o teste, o atraso de dados do link em circunstâncias normais é de segundo nível, o que não é completamente inaceitável;
-
Ele depende de mais componentes e tem requisitos mais elevados para a estabilidade dos componentes básicos. Exceções do RocketMQ ou exceções de tarefas do Flink causarão problemas no link de sincronização e aumentarão o risco de exceções de negócios.
Uma questão que precisa de atenção aqui é que algumas pessoas podem considerar conectar-se a um cluster ES de sala com várias máquinas. Como garantir que várias salas de computadores sejam bem-sucedidas ao mesmo tempo e como garantir que os dados possam ser consultados após a gravação bem-sucedida? Atualmente, esses dois pontos não podem ser alcançados porque várias salas de computadores escrevem de forma independente, sem afetar umas às outras, e o cluster ES é um cluster de consistência de dados fraca, portanto não há garantia de que gravações bem-sucedidas possam ser encontradas imediatamente.
Pré-requisitos para construir e executar um programa de consumidor ES Flink :
-
Ambiente de execução do Flink : Em primeiro lugar, você precisa ter um ambiente de execução para tarefas do Flink. Normalmente, as tarefas do Flink de nível empresarial serão agendadas como um trabalho do YARN no sistema distribuído e alocarão recursos para execução, mas, ao mesmo tempo, o Flink. também pode ser usado como um processo independente ou para construir uma operação de cluster independente.
-
Formato de mensagem ES : É necessário concordar com um formato de transmissão de mensagem ES e método de serialização. Um conjunto de paradigmas pode resolver todos os cenários de sincronização. O método de serialização atualmente popular é o formato pb ou formato json. . Formato de dados Definição do esquema:
|
Nome do campo
|
tipo de valor
|
Obrigatório/Opcional
|
descrever
|
|
_índice
|
corda
|
obrigatório
|
O nome ou apelido do documento a ser indexado
|
|
_tipo
|
corda
|
Obrigatório/Opcional
|
Tipo de documento
|
|
_no_tipo
|
corda
|
obrigatório
|
Tipo de operação de gravação de documento
, intervalo de valores:
index, create, update,
upsert
, delete
|
|
_eu ia
|
corda
|
Opcional
|
ID do documento
. Se não for especificado, ele será
gerado automaticamente
quando gravado no ES . No entanto, se os mesmos dados forem consumidos e gravados repetidamente no ES, vários documentos serão gerados.
|
|
_roteamento
|
corda
|
Opcional
|
Roteamento
de documentos Se não for especificado, o roteamento do valor do campo _id será usado por padrão.
|
|
_versão
|
int64
|
Opcional
|
Versão do documento
. Quando especificado, é maior que 0
e é válido apenas para operações de indexação/exclusão
. O tipo de versão
external_gte
é usado por padrão.
|
|
_fonte
|
objeto
|
Obrigatório/Opcional
|
Conteúdo do documento
, não precisa ser especificado quando o tipo de operação é excluído.
|
|
_roteiro
|
objeto
|
Opcional
|
Script do documento
, válido quando o tipo de operação é update/upsert, mas não pode existir com _source ao mesmo tempo
|
syntax = "proto3";
message ESIndexInfo {
string Name = 1; // 文档要写入索引的名称或别名
}
enum ESOPType { // 文档写入操作类型
DELETE = 0; // 删除文档
INDEX = 1; // 创建新文档或更新老文档，只能全量更新 (替换老文档)
UPDATE = 2; // 更新老文档，支持部分更新 (合并老文档)
UPSERT = 3; // 创建新文档或更新老文档，支持部分更新 (合并老文档)
CREATE = 4; // 创建新文档，存在时报错丢弃
}
message ESDocAction {
ESIndexInfo IndexInfo = 1; // 索引信息 (必需)
ESOPType OPType = 2; // 操作类型 (必需)
string ID = 3; // 文档 ID (可选)
string Doc = 4; // 文档内容 (JSON 格式, 删除操作时不需要)
int64 Version = 5; // 文档版本 (可选, 大于 0 且操作为 index/create/delete 有效)
string Routing = 6; // 文档路由 (可选, 非空有效)
string Script = 7; // 文档脚本 (JSON 格式, 操作类型为 update/upsert 有效，但和 Doc 不能同时存在)
}-
Configuração necessária para tarefas do Flink : informações monitoradas do tópico RocketMQ, gravação de informações do cluster ES;
-
Função de execução do Flink : O Flink processa mensagens de streaming de duas maneiras: SQL de streaming e aplicativos personalizados O SQL de streaming está sujeito a algumas limitações próprias, como não suportar múltiplas mensagens de índice no mesmo MQ, enquanto a programação personalizada é mais flexível. como adicionar vários gerenciamentos, logs, processamento de códigos de erro, etc., este método é recomendado;
-
Configuração de recursos Flink : configuração de recursos JobManager, configuração de recursos TaskManager, etc.;
-
Configuração de parâmetros personalizados do Flink : você pode personalizar algumas configurações dinâmicas intimamente relacionadas ao aplicativo para facilitar o ajuste dinâmico dos recursos de consumo do Flink, como:
|
nome do parâmetro
|
usar
|
valor padrão
|
|
job.writer.connector.bulk-flush.max-actions
|
O número máximo de documentos em um único volume, caso ultrapasse o número, será realizada uma liberação (ou seja, será executada uma solicitação em massa de ES)
|
Padrão 300
|
|
job.writer.connector.bulk-flush.max-size
|
O número máximo de bytes em um único volume, caso ultrapasse o limite, será realizado um flush (ou seja, será executada uma solicitação em massa de ES)
|
Padrão 10 MB
|
|
job.writer.connector.bulk-flush.interval
|
O intervalo máximo entre dois volumes, se houver mais de uma liberação (ou seja, executar uma solicitação em massa ES)
|
Padrão 1000ms
|
|
job.writer.connector.global-rate-limit
|
Valor limite de velocidade de gravação global
|
Padrão -1, sem limite de velocidade
|
|
job.writer.connector.failure-handler
|
Especifique um manipulador de falhas personalizado, como lidar com erros 4xx, erros 5xx de maneiras diferentes, 429 sempre tentando novamente infinitamente, etc.;
|
|
|
global_paralelismo_num
|
simultaneidade global da tarefa flink
|
rmq é fila/4, bmq/kafka é partição/3
|
|
max_paralelismo_num
|
Simultaneidade máxima de tarefas flink
|
O número de filas/partições do mq
|
|
intervalo_de_ponto de verificação
|
O intervalo para criação do Checkpoint, unidade ms (5min=300000)
|
Padrão 15min
|
|
ponto de verificação_timeout
|
Tempo limite para criação do Checkpoint, unidade ms (5min=300000)
|
Padrão 10min
|
|
rebalance_enable
|
Habilitar consumo fora de ordem
|
Padrão falso
|
Sugestões de comparação
|
Método de escrita
|
Atraso de sincronização
|
Escrever propriedades
|
Desempenho de gravação ES
|
consumidor
|
Tolerância a desastres
|
|
conexão direta
|
Menos componentes dependentes e baixa latência
|
Chave única do Binlog solicitada
|
gravação em massa
|
FaaS
|
Pobre
|
|
RocketMQ+Flink+ES
|
Existem muitos componentes dependentes e o atraso é alto/segundo nível
|
Ordem global de chave única
|
gravação em massa
|
Considerável
|
bom
|
Após a introdução acima, se a empresa puder aceitar atrasos de segundo nível, o uso do RocketMQ + Flink pode alcançar melhor a ordem e os recursos de recuperação de desastres. O Flink também é muito superior ao FaaS em termos de recursos de processamento de tarefas de streaming, mas diretamente O método de conexão obviamente tem. links mais simples, arquitetura mais leve e menores custos de integração e manutenção de sistemas. Portanto, ainda é necessário escolher o mais adequado com base nas características do negócio.
Equipe de origem｜Plataforma de negócios de comércio eletrônico ByteDance
{{o.name}}
{{m.name}}