Kafka assume a função de armazenamento e distribuição de dados unificados na plataforma de dados Meituan. Em vista dos pontos problemáticos das operações em tempo real afetadas por operações atrasadas devido à contaminação mútua do PageCache, que desencadeia a competição do PageCache, a Meituan desenvolveu o armazenamento em cache da camada de aplicativo do Kafka arquitetura baseada em SSDs. Este artigo apresenta principalmente o design e a implementação da arquitetura, incluindo a seleção do esquema, a comparação com outras alternativas e os principais pontos de pensamento do esquema e, finalmente, a comparação de desempenho entre este esquema e outras alternativas.
O status atual de Kafka na plataforma de dados Meituan
A excelente otimização de E / S de Kafka e vários designs assíncronos têm um rendimento mais alto do que outros sistemas de enfileiramento de mensagens, ao mesmo tempo que garantem uma boa latência, o que é muito adequado para aplicação em todo o ecossistema de big data.
Atualmente na plataforma de dados Meituan, Kafka assume o papel de buffer e distribuição de dados. Conforme mostrado na figura abaixo, logs de negócios, logs de camada de acesso Nginx ou dados de banco de dados online são enviados para Kafka por meio da camada de coleta de dados, e os dados subsequentes são consumidos e calculados pelas operações em tempo real do usuário ou usados pela camada ODS do warehouse para a produção do data warehouse. Outra parte entrará no centro de log unificado da empresa para ajudar os engenheiros a solucionar problemas online.
A escala atual de Kafka em Meituan:
-
Tamanho do cluster : mais de 6000 nós e mais de 100 clusters.
-
Portador do cluster : Tópico número 60.000+, Partição número 410.000+.
-
A escala de mensagens processadas : Atualmente, a quantidade total de mensagens processadas por dia é de 8 trilhões e o tráfego de pico é de 180 milhões de mensagens por segundo
-
A escala dos serviços fornecidos : atualmente, a plataforma de computação em tempo real downstream executa mais de 30.000 trabalhos, e a maioria dessas fontes de dados são de Kafka.
Análise de pontos problemáticos on-line Kafka e objetivos principais
Atualmente, o Kafka suporta um grande número de tarefas em tempo real e um grande número de tópicos e partições realizadas por uma única máquina. O problema que tende a aparecer neste cenário é que partições diferentes na mesma máquina competem por recursos do PageCache e afetam umas às outras, resultando em um aumento no atraso de processamento de todo o Broker e uma diminuição no rendimento.
A seguir, analisaremos os pontos problemáticos do Kafka online combinando o fluxo de processamento das solicitações de leitura e gravação do Kafka e estatísticas online.
Análise de princípio
Para solicitações de produção : o thread de E / S no lado do servidor grava uniformemente os dados solicitados no PageCache do sistema operacional e retorna imediatamente. Quando o número de mensagens atingir um certo limite, o próprio aplicativo Kafka ou o kernel do sistema operacional será acionado uma operação forçada de disco flash (conforme mostrado no fluxograma à esquerda).
Para solicitações de consumo: o mecanismo ZeroCopy do sistema operacional é usado principalmente. Quando o Kafka Broker recebe uma solicitação de leitura de dados, ele envia uma chamada de sistema sendfile para o sistema operacional. Depois de recebê-la, o sistema operacional primeiro tenta obter dados de PageCache (conforme mostrado no fluxograma do meio) Se os dados não existirem, ele irá disparar uma interrupção de exceção de falha de página para ler os dados do disco no buffer temporário (conforme mostrado no fluxograma à direita) e, em seguida, copiar diretamente os dados para o buffer da placa de rede por meio da operação DMA para aguardar a transmissão TCP de acompanhamento.
Resumindo, o Kafka tem boa taxa de transferência e latência para uma única solicitação de leitura e gravação. Ao processar uma solicitação de gravação, os dados são retornados imediatamente após serem gravados no PageCache, e os dados são liberados para o disco em lotes de forma assíncrona, o que não apenas garante que a maioria das solicitações de gravação possa ter um atraso menor e a liberação sequencial de lote seja mais amigável para o disco. Ao processar solicitações de leitura, as tarefas de consumo em tempo real podem ler dados diretamente do PageCache, com menos latência de solicitação. Ao mesmo tempo, o mecanismo ZeroCopy pode reduzir a alternância entre o modo de usuário e o modo kernel durante a transmissão de dados, o que melhora muito a eficiência do transmissão de dados.
No entanto, quando há vários Consumidores no mesmo Broker, eles podem ser atrasados devido a vários Consumidores competindo por recursos do PageCache. A seguir, tomamos dois consumidores como exemplo para explicar em detalhes:
Conforme mostrado na figura acima, o Produtor envia dados para o Broker, e o PageCache armazenará em cache essa parte dos dados. Quando a capacidade de consumo de todos os Consumers for suficiente, todos os dados serão lidos do PageCache e a latência de todas as instâncias do Consumidor será baixa. Neste momento, se um dos Consumidores apresentar um atraso de consumo (Processo do Consumidor2 na figura), de acordo com o fluxo de processamento da solicitação de leitura, a leitura do disco será acionada neste momento, e parte dos dados será pré-lida para PageCache ao ler os dados do disco. Quando o espaço do PageCache for insuficiente, os dados serão eliminados de acordo com a estratégia LRU.Neste momento, os dados lidos pelo consumidor atrasado substituirão os dados do cache em tempo real no PageCache. Posteriormente, quando a solicitação de consumo em tempo real chegar, porque os dados no PageCache foram substituídos, ocorrerão leituras de disco inesperadas. Isso tem duas consequências:
-
Os consumidores com poder de compra suficiente perderão o bônus de desempenho do PageCache ao consumir.
-
Vários consumidores influenciam uns aos outros, e as leituras de disco inesperadas aumentam e a carga do HDD aumenta.
Conduzimos testes de gradiente no desempenho do HDD e no impacto da simultaneidade de leitura e gravação, conforme mostrado na figura a seguir:
Pode-se ver que conforme a simultaneidade de leitura aumenta, o IOPS e a largura de banda do HDD diminuirão significativamente, o que afetará ainda mais a taxa de transferência e o atraso de processamento de todo o Broker.
Estatísticas online
Atualmente, o tráfego TP99 do cluster Kafka é de 170 MB / s, o tráfego TP95 é de 100 MB / s, o tráfego TP50 é de 50-60 MB / s; a alocação média de PageCache de uma única máquina é de 80 GB, e o tráfego de TP99 é tomado como referência Sob esse tráfego e alocação de PageCache, o período máximo de dados armazenáveis em cache do PageCache é 80 * 1024/170/60 = 8min, o que mostra que o serviço Kafka atual como um todo tem tolerância extremamente baixa para operações de consumo atrasadas. Nesse caso, uma vez que o consumo de alguns trabalhos é atrasado, os trabalhos de consumo em tempo real podem ser afetados.
Ao mesmo tempo, contamos a distribuição do atraso de consumo de trabalhos online em tempo real. Os trabalhos com um intervalo de atraso de 0-8min (consumo em tempo real) representaram apenas 80%, indicando que 20% dos trabalhos online estão atualmente em um estado de consumo retardado.
Resumo da análise do ponto de dor
Resumindo os princípios de análise e estatísticas de dados online mencionados acima, o Kafka atualmente online tem os seguintes problemas:
-
Os trabalhos de consumo em tempo real e de consumo atrasado competem no nível do PageCache, levando a leituras de disco inesperadas devido ao consumo em tempo real.
-
O desempenho do HDD tradicional cai drasticamente à medida que aumenta a simultaneidade de leitura.
-
Há 20% das operações do consumidor online atrasadas.
De acordo com a atual alocação de espaço do PageCache e análise de tráfego de cluster online, Kafka não pode fornecer uma garantia de qualidade de serviço estável para operações de consumidor em tempo real, e esse ponto problemático precisa ser resolvido com urgência.
Meta esperada
Com base na análise de pontos problemáticos acima, nossa meta esperada é garantir que os empregos do consumidor em tempo real não sejam afetados por atrasos nos empregos do consumidor devido à concorrência do PageCache e garantir que o Kafka forneça garantias de qualidade de serviço estáveis para os empregos do consumidor em tempo real .
solução
Por que escolher SSD
De acordo com a análise das razões acima, isso pode ser visto nas duas direções a seguir para resolver os pontos de dor atuais:
-
Elimine a competição do PageCache entre o consumo em tempo real e o consumo atrasado, como por exemplo: permitir que os dados sejam lidos por tarefas de consumo atrasado não gravar no PageCache ou aumentar a alocação do PageCache.
-
Adicione um novo dispositivo entre o HDD e a memória, que tenha melhor largura de banda de leitura e gravação e IOPS do que o HDD.
Para a primeira direção, como o PageCache é gerenciado pelo sistema operacional, se sua estratégia de eliminação for modificada, será mais difícil de implementar e destruirá a semântica externa do próprio kernel. Além disso, o custo dos recursos de memória é alto e a expansão ilimitada não é possível, portanto, a segunda direção deve ser considerada.
O desenvolvimento do SSD está se tornando cada vez mais maduro.Comparado com o HDD, o IOPS e a largura de banda do SSD tem uma melhoria de ordem de magnitude, que é muito adequada para participar do tráfego de leitura após a competição do PageCache ocorrer no cenário acima. Também testamos o desempenho do SSD, e os resultados são mostrados na figura a seguir:
Pode-se ver na figura que à medida que a simultaneidade de leitura aumenta, o IOPS e a largura de banda do SSD não diminuirão significativamente. A partir dessa conclusão, podemos usar o SSD como a camada de cache entre o PageCache e o HDD.
Decisão arquitetônica
Depois de introduzir o SSD como a camada de cache, os principais problemas a serem resolvidos na próxima etapa incluem a sincronização de dados entre PageCache, SSD e HDD e roteamento de dados para solicitações de leitura e gravação. Ao mesmo tempo, nossa nova arquitetura de cache precisa ser totalmente corresponder ao mecanismo Kafka de leitura e gravação. As características da solicitação. Esta seção apresentará como a nova arquitetura resolve os problemas mencionados acima na seleção e design.
O mecanismo Kafka tem as seguintes características no comportamento de leitura e gravação:
-
A frequência do consumo de dados muda ao longo do tempo, quanto maior a frequência de consumo de dados, menor.
-
Cada partição (partição) apenas o Leader fornece serviços de leitura e gravação.
-
Para um cliente, o comportamento de consumo é linear e os dados não serão consumidos repetidamente.
Duas alternativas são fornecidas abaixo, e nossa base de seleção e decisões arquitetônicas serão fornecidas para as duas opções abaixo.
Alternativa 1: implementação com base na camada de kernel do sistema operacional
Atualmente, as tecnologias de cache de código aberto incluem FlashCache, BCache, DM-Cache, OpenCAS, etc. Entre eles, BCache e DM-Cache foram integrados ao Linux, mas existem requisitos para a versão do kernel e são limitados pela versão do kernel. só pode escolher FlashCache / OpenCAS.
Conforme mostrado na figura abaixo, as ideias principais de design do FlashCache e do OpenCAS são semelhantes. A base teórica central das duas arquiteturas é o princípio da "localidade dos dados". O SSD e o HDD são divididos em unidades de gerenciamento fixas com a mesma granularidade, e, em seguida, o SSD é instalado.O espaço é mapeado para vários dispositivos de camada de HDD (mapeamento lógico ou mapeamento físico). No processo de acesso, semelhante ao processo de acesso da CPU ao cache e à memória principal, tente primeiro acessar a camada de Cache. Se CacheMiss aparecer, a camada de HDD será acessada. Ao mesmo tempo, de acordo com o princípio da localidade dos dados, este parte dos dados serão gravados de volta na camada de cache. Se o espaço do cache estiver cheio, alguns dados serão substituídos por meio da estratégia LRU.
FlashCache / OpenCAS fornece quatro estratégias de cache: WriteThrough, WriteBack, WriteAround, WriteOnly. Uma vez que o quarto tipo não faz cache de leitura, aqui veremos apenas os três primeiros tipos.
Escreva:
-
WriteThrough : a operação de gravação de dados será gravada no armazenamento de back-end ao mesmo tempo em que é gravada no SSD.
-
WriteBack : a operação de gravação de dados retorna somente após a gravação no SSD e a estratégia de cache é liberada para o armazenamento em segundo plano.
-
WriteAround : as operações de gravação de dados são gravadas diretamente no armazenamento de back-end e o cache correspondente ao SSD se tornará inválido.
Ler:
-
WriteThrough / WriteBack / WriteAround : primeiro leia o SSD, se ele falhar , o armazenamento de back-end será lido novamente e os dados serão liberados para o cache do SSD.
Para obter detalhes de implementação mais detalhados, consulte os documentos oficiais dos dois:
Alternativa dois: implementação interna do aplicativo Kafka
No primeiro tipo de alternativas mencionadas acima, a base teórica central do princípio de "localidade de dados" e as características de leitura e gravação de Kafka não são completamente consistentes. O recurso de "flashback de dados" ainda introduzirá o problema de poluição do espaço de cache. Ao mesmo tempo, a estratégia de eliminação baseada em LRU da arquitetura acima também contradiz as características de leitura e gravação de Kafka. Quando vários consumidores consomem simultaneamente, a estratégia de eliminação de LRU pode erroneamente eliminar alguns dados quase em tempo real, resultando em instabilidade de desempenho real em tempo de operações do consumidor.
Pode-se ver que a solução alternativa não pode resolver completamente os pontos de dor atuais do Kafka e precisa ser transformada de dentro do aplicativo. A ideia geral do design é a seguinte. Os dados são distribuídos em diferentes dispositivos de acordo com a dimensão do tempo, e a parte quase em tempo real dos dados é armazenada em cache no SSD, de modo que, quando ocorrer a competição do PageCache, o trabalho do consumidor em tempo real lê os dados do SSD para garantir que o trabalho em tempo real não seja afetado. Impacto das operações de consumo atrasadas. A figura a seguir mostra o processo de processamento de solicitações de leitura com base na arquitetura implementada na camada do aplicativo:
Quando uma solicitação de consumo chega ao Kafka Broker, o Kafka Broker obtém os dados diretamente do dispositivo correspondente de acordo com a relação entre o deslocamento da mensagem (deslocamento) mantido por ele e o dispositivo e o retorna, e os dados lidos do HDD não são incluído na solicitação de leitura. Volte ao SSD para evitar poluição do cache. Ao mesmo tempo, o caminho de acesso está livre e não haverá sobrecarga de acesso adicional devido à perda de cache.
A tabela a seguir fornece uma comparação mais detalhada de diferentes soluções candidatas:
Por fim, considerando o grau de correspondência com os recursos de leitura e gravação do Kafka, a carga de trabalho geral e outros fatores, usamos a camada de aplicativo Kafka para implementar esta solução, porque a solução está mais próxima dos recursos de leitura e gravação do próprio Kafka e pode resolver de forma mais completa Pontos de dor de Kafka.
Novo projeto de arquitetura
Visão geral
Com base na análise acima das características de leitura e gravação de Kafka, fornecemos os objetivos de design da arquitetura de cache baseada em SSD na camada de aplicativo:
-
Os dados são distribuídos em diferentes dispositivos de acordo com a dimensão do tempo, os dados quase em tempo real são distribuídos no SSD e eliminados no HDD ao longo do tempo.
-
Todos os dados na partição líder são gravados no SSD.
-
Os dados lidos do HDD não são devolvidos ao SSD.
De acordo com os objetivos acima, fornecemos a implementação da arquitetura de cache Kafka baseada em SSD na camada de aplicativo:
Uma partição no Kafka consiste em vários LogSegments e cada LogSegment contém dois arquivos de índice e arquivos de mensagem de log. Vários LogSegments de uma partição são organizados em ordem de acordo com a dimensão Offset (tempo relativo).
De acordo com as ideias de design na seção anterior, primeiro marcamos diferentes LogSegment como estados diferentes, conforme mostrado na figura (a parte superior da figura) de acordo com a dimensão do tempo, é dividido em três estados residentes: OnlyCache, Cached, e WithoutCache. A transição dos três estados e o processamento das operações de leitura e gravação pela nova arquitetura são mostrados na parte inferior da figura. O LogSegment marcado como OnlyCached é armazenado apenas no SSD, e o thread de segundo plano armazenará periodicamente o Inativo ( sem tráfego de gravação) LogSegment Sincronize com o SSD, e o LogSegment sincronizado é marcado como em cache.
Por fim, o encadeamento de segundo plano verificará periodicamente o espaço usado no SSD. Quando o espaço atingir o limite, o encadeamento de segundo plano removerá o LogSegment com a maior distância do SSD de acordo com a dimensão do tempo, e esta parte do LogSegment será marcado como o estado WithoutCache.
Para solicitações de gravação, a solicitação de gravação ainda grava os dados no PageCache primeiro, e o SSD será liberado após a condição de limite ser atendida. Para uma solicitação de leitura (quando o PageCache não obteve os dados), se o status do LogSegment correspondente ao deslocamento de leitura for Cached ou OnlyCache, os dados são retornados do SSD (LC2-LC1 e RC1 na figura). o status é WithoutCache, o HDD retorna (LC1 na figura).
Para a sincronização de dados da cópia do seguidor, você pode decidir se deseja gravar em SSD ou HDD por meio da configuração de acordo com os requisitos do Tópico para latência e estabilidade.
Principais pontos de otimização
O texto acima apresentou o esboço de design e as ideias principais de design da arquitetura de cache da camada de aplicativo Kafka baseada em SSD, incluindo processos de leitura e gravação, gerenciamento de estado interno e novas funções de thread em segundo plano. Esta seção apresentará os principais pontos de otimização da solução, que estão intimamente relacionados ao desempenho do serviço. Inclui principalmente a sincronização LogSegment e a otimização da estratégia de flashing Append, que serão apresentadas separadamente abaixo.
Sincronização LogSegment
A sincronização LogSegment refere-se ao processo de sincronização de dados no SSD para o HDD. O mecanismo é projetado com os dois pontos principais a seguir:
-
Método de sincronização : o método de sincronização determina a pontualidade visível dos dados SSD no HDD, o que afetará a pontualidade da recuperação de falha e da limpeza do LogSegment.
-
Limite de velocidade de sincronização : o processo de sincronização LogSegment usa um mecanismo de limite de velocidade para evitar que solicitações normais de leitura e gravação sejam afetadas durante o processo de sincronização
Synchronously
Quanto ao método de sincronização do LogSegment, apresentamos três alternativas: A tabela a seguir lista a introdução dos três esquemas e suas respectivas vantagens e desvantagens:
No final, consideramos de forma abrangente fatores como custo de manutenção de consistência e complexidade de implementação, e escolhemos o método de sincronização de LogSegment inativo em segundo plano.
Limite de velocidade síncrona
O comportamento de sincronização do LogSegment é essencialmente a transmissão de dados entre os dispositivos, o que irá gerar tráfego adicional de leitura e gravação nos dois dispositivos ao mesmo tempo, ocupando a largura de banda de leitura e gravação do dispositivo correspondente. Ao mesmo tempo, como optamos por sincronizar os dados na parte Inativa, precisamos sincronizar toda a seção. Se o processo de sincronização não for restrito, terá um impacto maior no atraso geral do serviço, principalmente nos seguintes dois aspectos:
-
Do ponto de vista do desempenho de um único disco, como o desempenho do SSD é muito maior do que o do HDD, a largura de banda de gravação do HDD ficará cheia durante a transmissão de dados. Neste momento, outras solicitações de leitura e gravação terão falhas. Se houver um atraso no consumo do HDD neste momento Lendo dados ou o seguidor está sincronizando dados com o HDD, o que causará instabilidade no serviço.
-
Da perspectiva de implantação autônoma, uma única máquina implanta 2 SSDs e 10 HDDs. Portanto, durante o processo de sincronização, 1 SSD precisa suportar o volume de gravação de 5 HDDs. Portanto, o SSD também terá problemas de desempenho durante o processo de sincronização , o que afeta a normalidade. A resposta da solicitação está atrasada.
Com base nos dois pontos acima, precisamos adicionar um mecanismo de limite de velocidade no processo de sincronização LogSegment. O princípio geral do limite de velocidade é sincronizar o mais rápido possível sem afetar o atraso das solicitações normais de leitura e gravação. Como a velocidade de sincronização é muito lenta, os dados SSD não podem ser apagados a tempo e eventualmente ficam cheios. Ao mesmo tempo, para poder se ajustar de maneira flexível, a configuração também é definida como um parâmetro de configuração de uma única granularidade do Broker.
Estratégia otimizada de liberação de log
Além do problema de sincronização, o mecanismo de flashing durante o processo de gravação de dados também afeta a latência de leitura e gravação do serviço. O design desse mecanismo não afetará apenas o desempenho da nova arquitetura, mas também afetará o Kafka nativo.
A figura a seguir mostra o fluxo de processamento de uma única solicitação de gravação:
No processo de processamento da solicitação de Produção, primeiro determine se o segmento de log precisa ser rolado com base na localização LogSegment atual e nas informações de dados na solicitação, em seguida, grave os dados solicitados no PageCache, atualize o LEO e as informações estatísticas e, finalmente, determine esteja ou não de acordo com a informação estatística. O piscar deve ser acionado, se necessário, através do fileChannel.forcepiscar forçado, caso contrário o pedido é devolvido diretamente.
Em todo o processo, exceto para as operações de rolagem e flashing do log, outras operações são operações de memória, que não causarão problemas de desempenho. A rolagem de log envolve a operação do sistema de arquivos. Atualmente, o Kafka fornece parâmetros de perturbação para a rolagem de log para evitar que vários segmentos acionem a operação de rolagem ao mesmo tempo para colocar pressão no sistema de arquivos. Para operações de liberação de log, o mecanismo atual fornecido por Kafka é acionar a liberação forçada com um número fixo de mensagens (atualmente 50.000 online). Esse mecanismo só pode garantir que as mensagens serão liberadas com a mesma frequência quando o tráfego de entrada for constante. , ele não pode limitar a quantidade de dados que são transferidos para o disco a cada vez e não pode fornecer restrições efetivas ao carregamento do disco.
Conforme mostrado na figura abaixo, é o valor instantâneo de write_bytes de um disco durante o horário de pico do meio-dia. Durante o horário de pico do meio-dia, devido ao aumento no tráfego de gravação, um grande número de rebarbas será gerado durante o processo de escovação, e o valor da rebarba está quase perto do disco máximo, o que fará com que o atraso das solicitações de leitura e gravação sofra um jitter.
Em resposta a esse problema, modificamos o mecanismo de discos flash e alteramos o limite original por número para o limite de taxa de flash real. Para um único segmento, a taxa de flash é limitada a 2 MB / s. Este valor leva em consideração o tamanho médio real da mensagem na linha. Se a configuração for muito pequena, o tópico com uma única mensagem grande será atualizado com muita frequência, o que aumentará o atraso médio quando o tráfego estiver alto. Atualmente, o mecanismo tem uma pequena faixa de escalas de cinza online. A imagem à direita mostra o índice write_bytes correspondente para o mesmo período de tempo após a escala de cinza. Pode-se ver que, em comparação com a imagem à esquerda, a taxa de liberação de dados é significativamente mais suave do que antes da escala de cinza, e a taxa máxima é de apenas 40 MB / s.
Para a nova arquitetura de cache SSD, os problemas acima também existem.Portanto, na nova arquitetura, a taxa de flashing também é limitada na operação de flashing.
Teste de solução
Alvo de teste
-
É verificado que a arquitetura de cache SSD baseada na camada de aplicação pode evitar que jobs em tempo real sejam afetados por jobs atrasados.
-
Verifica-se que comparada à arquitetura da camada de cache baseada na camada kernel do sistema operacional, a arquitetura SSD baseada na camada de aplicação possui menor latência de leitura e gravação sob diferentes tráfegos.
Descrição do cenário de teste
-
Construir 4 clusters: cluster de nova arquitetura, cluster HDD comum, cluster FlashCache, cluster OpenCAS.
-
3 nós por cluster.
-
Fluxo de gravação fixo, leitura e gravação relativamente demoradas.
-
Configuração de consumo atrasado: consome apenas dados de 10 a 150 minutos em relação ao tempo atual (excedendo a área de transporte do PageCache e não excedendo a área de transporte do SSD).
Conteúdo de teste e indicadores-chave
-
Caso 1: quando houver apenas consumo retardado, observe o desempenho de produção e consumo do cluster.
-
Indicadores principais: tempo de gravação e tempo de leitura. Esses dois indicadores refletem a latência de leitura e gravação.
-
Indicadores de taxa de acerto: volume de leitura de HDD, relação de leitura de HDD (volume de leitura de HDD / volume total de leitura), taxa de acerto de leitura de SSD. Esses três indicadores refletem a taxa de acerto de cache de SSD.
-
Caso 2: Quando houver consumo atrasado, observe o desempenho do consumo em tempo real.
-
Indicadores principais: a proporção de SLA (qualidade de serviço) para operações em tempo real em 5 áreas de tempo diferentes.
Resultado dos testes
Da perspectiva de um único atraso na solicitação do corretor:
Antes da otimização do mecanismo de flashing, a nova arquitetura de cache SSD tem vantagens óbvias sobre outras soluções em todos os cenários.
Depois de otimizado o mecanismo de flush de disco, a qualidade do serviço das outras soluções melhorou em termos de atraso. Com um pequeno volume de tráfego, devido à otimização do mecanismo de flush, as vantagens da nova arquitetura e outras soluções tornaram-se menores . Quando o tráfego de gravação de um único nó é grande (mais de 170 MB), a vantagem é óbvia.
Da perspectiva do impacto das operações atrasadas nas operações em tempo real:
Em todos os cenários envolvidos no teste, a nova arquitetura de cache não afeta as operações em tempo real devido a operações atrasadas, o que está de acordo com as expectativas.
Resumo e perspectivas futuras
Kafka assume a função de armazenamento e distribuição de dados unificados na plataforma de dados Meituan. Visando os pontos problemáticos atuais das operações em tempo real afetadas por operações atrasadas devido à contaminação mútua do PageCache e causando competição do PageCache, desenvolvemos o cache da camada de aplicativo do Kafka. arquitetura baseada em SSD. Este artigo apresenta principalmente as idéias de design da nova arquitetura do Kafka e sua comparação com outras soluções de software livre. Em comparação com clusters comuns, a nova arquitetura de cache tem vantagens óbvias:
-
Reduza o tempo de leitura e gravação : em comparação com clusters comuns, o cluster de nova arquitetura reduz o tempo de leitura e gravação em 80%.
-
O consumo em tempo real não é afetado pelo consumo atrasado : em comparação com clusters comuns, o novo cluster de arquitetura tem desempenho estável de leitura e gravação em tempo real e não é afetado pelo consumo atrasado.
No momento, esse conjunto de arquitetura de cache foi verificado e está no estágio cinza e será implantado em clusters de alta qualidade no futuro. O código envolvido também será enviado à comunidade Kafka como um feedback para a comunidade, e todos são bem-vindos para se comunicar conosco.
Sobre o autor
Shiji e Shilu são engenheiros da plataforma de dados da Meituan.
---------- FIM ----------
Ofertas de trabalho
O grupo de armazenamento em tempo real da plataforma básica de P&D da Meituan é responsável principalmente pela P&D, manutenção e construção de plataforma relacionada de mecanismos de armazenamento em tempo real para cenários de big data. Projetado para fornecer um serviço de armazenamento de streaming unificado, eficiente, confiável e fácil de usar. Alunos interessados são bem-vindos a se juntar a nós! O currículo pode ser enviado para: [email protected] (indique o assunto do e-mail: armazenamento em tempo real)
Talvez você ainda queira assistir
| Mecanismo de armazenamento de arquivos Kafka essas coisas
| A exploração e prática do sistema de gerenciamento de serviços de próxima geração da Meituan OCTO2.0