O livro "Apache Kafka. Processamento de fluxo e análise de dados ”

Durante o trabalho de qualquer aplicativo corporativo, são gerados dados: são arquivos de log, métricas, informações sobre a atividade do usuário, mensagens enviadas, etc. A manipulação adequada de todos esses dados não é menos importante que os próprios dados. Se você é um arquiteto, desenvolvedor ou engenheiro graduado que deseja resolver esses problemas, mas ainda não conhece o Apache Kafka, neste maravilhoso livro você aprenderá como trabalhar com esta plataforma de streaming gratuita que permite processar filas de dados em tempo real.

Para quem é este livro?

Apache Kafka. Processamento de fluxo e análise de dados ”foi escrito para desenvolvedores que usam a API Kafka em seu trabalho, bem como engenheiros de processo (também chamados de SRE, DevOps ou administradores de sistema) que estão envolvidos na instalação, configuração, configuração e monitoramento de sua operação durante a operação industrial. Também não esquecemos os arquitetos de dados e os engenheiros analíticos - os responsáveis ​​pelo design e criação de toda a infraestrutura de dados da empresa. Alguns capítulos, em particular 3, 4 e 11, são voltados para desenvolvedores de Java. Para entendê-los, é importante que o leitor esteja familiarizado com os conceitos básicos da linguagem de programação Java, incluindo questões como manipulação de exceção e concorrência.

Outros capítulos, especialmente 2, 8, 9 e 10, pressupõem que o leitor tenha experiência com Linux e esteja familiarizado com a configuração de rede e armazenamento Linux. O restante das arquiteturas de livros e software de Kafka é discutido em termos mais gerais, portanto, nenhum conhecimento especial é exigido dos leitores.

Outra categoria de pessoas que podem estar interessadas neste livro são gerentes e arquitetos que não trabalham diretamente com Kafka, mas com aqueles que trabalham com ele. Não é menos importante que eles entendam quais são as garantias da plataforma e o que compromete seus subordinados e colegas ao criar sistemas baseados em Kafka. Este livro será útil para os gerentes que desejam treinar seus funcionários para trabalhar com Kafka ou para garantir que a equipe de desenvolvimento possua as informações necessárias.

Capítulo 2. Instalando o Kafka

O Apache Kafka é um aplicativo Java que pode ser executado em muitos sistemas operacionais, incluindo Windows, MacOS, Linux e outros.Neste capítulo, focaremos na instalação do Kafka no Linux, pois é a plataforma mais frequentemente instalada nesse sistema operacional. O Linux também é o sistema operacional recomendado para a implantação Kafka de uso geral. Para obter informações sobre a instalação do Kafka no Windows e MacOS, consulte o Apêndice A.

Instalar java

Antes de instalar o ZooKeeper ou Kafka, você deve instalar e configurar o ambiente Java. É recomendável usar o Java 8, e essa pode ser uma versão incluída no sistema operacional ou baixada diretamente do java.com. Embora o ZooKeeper e o Kafka funcionem com o Java Runtime Edition, é mais conveniente usar o Java Development Kit (JDK) completo ao desenvolver utilitários e aplicativos. Essas etapas de instalação assumem que você possui o JDK versão 8.0.51 instalado no diretório /usr/java/jdk1.8.0_51.

Instale o ZooKeeper

O Apache Kafka usa o ZooKeeper para armazenar metadados sobre o cluster Kafka, além de detalhes sobre clientes consumidores (Fig. 2.1). Embora o ZooKeeper também possa ser iniciado usando scripts incluídos na distribuição Kafka, a instalação da versão completa do repositório ZooKeeper a partir da distribuição é muito simples.


O Kafka foi completamente testado com a versão estável 3.4.6 do repositório ZooKeeper, que pode ser baixada em apache.org.

Servidor autônomo

O exemplo a seguir demonstra como instalar o ZooKeeper com configurações básicas no diretório / usr / local / zookeeper e salvar os dados no diretório / var / lib / zookeeper:

# tar -zxf zookeeper-3.4.6.tar.gz # mv zookeeper-3.4.6 /usr/local/zookeeper # mkdir -p /var/lib/zookeeper # cat > /usr/local/zookeeper/conf/zoo.cfg << EOF > tickTime=2000 > dataDir=/var/lib/zookeeper > clientPort=2181 > EOF # /usr/local/zookeeper/bin/zkServer.sh start JMX enabled by default Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED # export JAVA_HOME=/usr/java/jdk1.8.0_51 # /usr/local/zookeeper/bin/zkServer.sh start JMX enabled by default Using config: /usr/local/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED # 

Agora você pode verificar se o ZooKeeper deve funcionar offline, conectando-se à porta do cliente e enviando o comando srvr de quatro letras:

 # telnet localhost 2181 Trying ::1... Connected to localhost. Escape character is '^]'. srvr Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT Latency min/avg/max: 0/0/0 Received: 1 Sent: 0 Connections: 1 Outstanding: 0 Zxid: 0x0 Mode: standalone Node count: 4 Connection closed by foreign host. # 

ZooKeeper Ensemble

O cluster ZooKeeper é chamado de conjunto. Devido à natureza do próprio algoritmo, recomenda-se que o conjunto inclua um número ímpar de servidores, por exemplo, 3, 5, etc., pois para que o ZooKeeper possa responder às solicitações, a maioria dos membros do conjunto deve funcionar (quorum). Isso significa que um conjunto de três nós pode trabalhar com um nó inativo. Se o conjunto tiver três nós, pode haver dois.

Para configurar a operação dos servidores ZooKeeper no conjunto, eles devem ter uma única configuração com uma lista de todos os servidores, e cada servidor no diretório de dados deve ter um arquivo myid com o identificador desse servidor. Se os hosts do conjunto forem denominados zoo1.example.com, zoo2.example.com e zoo3.example.com, o arquivo de configuração poderá se parecer com o seguinte:

 tickTime=2000 dataDir=/var/lib/zookeeper clientPort=2181 initLimit=20 syncLimit=5 server.1=zoo1.example.com:2888:3888 server.2=zoo2.example.com:2888:3888 server.3=zoo3.example.com:2888:3888 

Nesta configuração, initLimit é a quantidade de tempo que os nós escravos podem conectar ao mestre. O valor syncLimit limita o atraso dos nós escravos do mestre. Ambos os valores são especificados em unidades tickTime, ou seja, initLimit = 20 · 2000 ms = 40 s. A configuração também lista todos os servidores de conjunto. Eles estão no formato server.X = hostname: peerPort: leaderPort com os seguintes parâmetros:

• X é o identificador do servidor. Ele deve ser um número inteiro, mas a contagem pode não ser de zero e não ser seqüencial;
• hostname - nome do host ou endereço IP do servidor;
• peerPort - porta TCP através da qual os servidores do conjunto se comunicam;
• leaderPort - porta TCP através da qual o host está selecionado.

É suficiente que os clientes possam se conectar ao conjunto por meio da porta clientPort, mas os membros do conjunto devem poder trocar mensagens entre si nas três portas.

Além de um único arquivo de configuração, cada servidor no diretório dataDir deve ter um arquivo myid. Ele deve conter o identificador do servidor correspondente ao fornecido no arquivo de configuração. Depois de concluir essas etapas, você pode iniciar os servidores e eles interagirão entre si no conjunto.

Instalando o Kafka Broker

Após concluir a configuração do Java e ZooKeeper, você pode prosseguir com a instalação do Apache Kafka. A versão mais recente do Apache Kafka pode ser baixada em kafka.apache.org/downloads.html .

No exemplo a seguir, instale a plataforma Kafka no diretório / usr / local / kafka, configure-a para usar o servidor ZooKeeper iniciado anteriormente e salve os segmentos de log de mensagens no diretório / tmp / kafka-logs:

 # tar -zxf kafka_2.11-0.9.0.1.tgz # mv kafka_2.11-0.9.0.1 /usr/local/kafka # mkdir /tmp/kafka-logs # export JAVA_HOME=/usr/java/jdk1.8.0_51 # /usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties # 

Após iniciar o broker Kafka, você pode testar seu funcionamento executando quaisquer operações simples com o cluster, incluindo a criação de um tópico de teste, gerando mensagens e consumindo-as.

Criando e verificando threads:

 # /usr/local/kafka/bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test Created topic "test". # /usr/local/kafka/bin/kafka-topics.sh --zookeeper localhost:2181 --describe --topic test Topic:test PartitionCount:1 ReplicationFactor:1 Configs: Topic: test Partition: 0 Leader: 0 Replicas: 0 Isr: 0 # 

Gerando mensagens para o tópico de teste:

 # /usr/local/kafka/bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test Test Message 1 Test Message 2 ^D # 

Consumindo mensagens do tópico de teste:

 # /usr/local/kafka/bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic test --from-beginning Test Message 1 Test Message 2 ^C Consumed 2 messages # 

Configuração do Broker

O exemplo de configuração do broker fornecido com a distribuição Kafka é bastante adequado para uma execução de teste de um servidor independente, mas para a maioria das instalações, não será suficiente. Existem muitas opções de configuração do Kafka que governam todos os aspectos da instalação e configuração. É possível deixar os valores padrão para muitos deles, pois eles se relacionam às nuances da configuração de um broker Kafka que não são aplicáveis ​​até que você trabalhe com um cenário específico que exija que eles sejam usados.

Configurações básicas do broker

Existem várias configurações do broker Kafka que você deve considerar ao implementar a plataforma em qualquer ambiente, exceto um broker independente em um servidor separado. Esses parâmetros estão relacionados às principais configurações do broker e a maioria deles deve ser alterada para que o broker possa trabalhar em um cluster com outros brokers.

broker.id

Cada intermediário Kafka deve ter um identificador inteiro especificado pelo parâmetro broker.id. Por padrão, esse valor é 0, mas pode ser qualquer número. O principal é que ele não se repete no mesmo cluster Kafka. A escolha do número pode ser arbitrária e, se necessário, para conveniência da manutenção, pode ser transferida de um corretor para outro. É desejável que esse número esteja de alguma forma conectado ao host, então a correspondência dos identificadores do broker para hosts com rastreamento será mais transparente. Por exemplo, se seus nomes de host contiverem números exclusivos (por exemplo, host1.exemplo.com, host2.exemplo.com etc.), esses números seriam uma boa opção para os valores de broker.id.

porta

Um arquivo de configuração típico inicia o Kafka com um ouvinte na porta TCP 9092. Essa porta pode ser alterada para qualquer outra disponível, alterando a porta do parâmetro de configuração. Lembre-se de que, ao escolher uma porta com um número menor que 1024, o Kafka deve ser executado como root. Executar o Kafka como root não é recomendado.

zookeeper.connect

O caminho que o ZooKeeper usa para armazenar os metadados do broker é definido usando o parâmetro de configuração zookeeper.connect. Na configuração de amostra, o ZooKeeper é executado na porta 2181 no host local, indicado como host local: 2181. O formato desse parâmetro é uma lista de linhas separadas por ponto e vírgula no formato nome do host: porta / caminho, incluindo:

• nome do host - nome do host ou endereço IP do servidor ZooKeeper;
• port - número da porta do cliente para o servidor;
• / path - um caminho opcional do ZooKeeper usado como o novo caminho raiz (chroot) do cluster Kafka. Se não for especificado, o caminho raiz será usado.

Se o caminho chroot especificado não existir, ele será criado quando o broker iniciar.

log.dirs

O Kafka salva todas as mensagens no disco rígido e esses segmentos do log são armazenados nos diretórios especificados na configuração log.dirs. É uma lista de caminhos separados por vírgula no sistema local. Se vários caminhos forem especificados, o broker salvará seções neles de acordo com o princípio dos menos utilizados, com a preservação dos segmentos de log de uma seção ao longo de um caminho. Observe que o broker colocará a nova seção no diretório em que, no momento, menos partições são armazenadas e não menos espaço é usado, para que a distribuição uniforme de dados entre as seções não seja garantida.

num.recovery.threads.per.data.dir

Kafka usa um conjunto de encadeamentos personalizado para processar segmentos de log. Atualmente é aplicado:

• durante a inicialização normal - para abrir os segmentos de log de cada seção;
• iniciar após uma falha - para verificar e truncar os segmentos de log de cada seção;
• Parar - para fechar suavemente os segmentos de log.

Por padrão, apenas um encadeamento é usado por diretório de log. Como isso acontece apenas ao iniciar e parar, faz sentido usar mais deles para paralelizar operações. Ao se recuperar de um desligamento incorreto, os benefícios do uso dessa abordagem podem chegar a várias horas se o broker com um grande número de partições for reiniciado! Lembre-se de que o valor desse parâmetro é determinado com base em um diretório de log do número especificado usando log.dirs. Ou seja, se o valor do parâmetro num.recovery.threads.per.data.dir for 8 e três caminhos forem especificados em log.dirs, o número total de encadeamentos será 24.

auto.create.topics.enable

De acordo com a configuração padrão do Kafka, o broker deve criar automaticamente um tema quando:

• o fabricante começa a escrever na linha de assunto;
• o consumidor começa a ler o tópico da mensagem;
• qualquer cliente solicita metadados do tópico.

Em muitos casos, esse comportamento pode ser indesejável, principalmente devido ao fato de que não há como verificar a existência de um tópico usando o protocolo Kafka sem fazer com que ele seja criado. Se você controlar a criação disso explicitamente, manualmente ou por meio do sistema de inicialização, poderá definir o parâmetro auto.create.topics.enable como false.

Configurações de tema padrão

A configuração do servidor Kafka define muitas configurações padrão para os temas criados. Alguns desses parâmetros, incluindo o número de seções e os parâmetros de salvamento de mensagens, podem ser definidos para cada tópico separadamente, usando as ferramentas do administrador (discutidas no Capítulo 9). Os valores padrão na configuração do servidor devem ser definidos iguais aos valores de referência adequados para a maioria dos tópicos do cluster.

partições num.

O parâmetro num.partitions determina com quantas seções um novo tópico é criado, principalmente quando a criação automática por temas é ativada (que é o comportamento padrão). O valor padrão deste parâmetro é 1. Lembre-se de que o número de seções de um tópico só pode ser aumentado, mas não reduzido. Isso significa que, se exigir menos partições do que as indicadas em partições num., você precisará criá-las cuidadosamente manualmente (isso é discutido no Capítulo 9).

Conforme discutido no Capítulo 1, as seções são uma maneira de escalar tópicos em um cluster Kafka, por isso é importante que você tenha o número necessário para equilibrar a carga nas mensagens em todo o cluster à medida que os agentes forem adicionados. Muitos usuários preferem que o número de partições seja igual ou o número de intermediários no cluster. Isso possibilita a distribuição uniforme de seções entre os intermediários, o que levará a uma distribuição uniforme da carga entre as mensagens. No entanto, esse não é um requisito obrigatório, porque a presença de vários tópicos permite equilibrar a carga.

log.retention.ms

Na maioria das vezes, o armazenamento de mensagens em Kafka é limitado no tempo. O valor padrão é especificado no arquivo de configuração usando o parâmetro log.retention.hours e é igual a 168 horas ou 1 semana. No entanto, você pode usar dois outros parâmetros - log.retention.minutes e log.retention.ms. Todos esses três parâmetros determinam a mesma coisa - o período de tempo após o qual as mensagens são excluídas. Mas é recomendável usar o parâmetro log.retention.ms, porque se vários parâmetros forem especificados, a prioridade pertencerá à menor unidade de medida, portanto, o valor de log.retention.ms será sempre usado.

log.retention.bytes

Outra maneira de limitar a validade das mensagens é baseada no tamanho total (em bytes) das mensagens armazenadas. O valor é definido usando o parâmetro log.retention.bytes e é aplicado separadamente. Isso significa que, no caso de um tópico de oito seções e igual a 1 GB do valor de log.retention.bytes, a quantidade máxima de dados armazenados para este tópico será de 8 GB. Observe que a quantidade de armazenamento depende das seções individuais e não do tópico. Isso significa que, se o número de seções do tópico aumentar, a quantidade máxima de dados salvos ao usar log.retention.bytes também aumentará.

log.segment.bytes

As configurações de log mencionadas dizem respeito a segmentos de log, não a mensagens individuais. À medida que as mensagens são geradas pelo broker Kafka, elas são adicionadas ao final do segmento de diário atual da seção correspondente. Quando o segmento de log atinge o tamanho especificado pelo parâmetro log.segment.bytes e é igual a 1 GB por padrão, esse segmento é fechado e um novo é aberto. Após o fechamento, o segmento do diário pode ser retirado. Quanto menor o tamanho dos segmentos de log, mais frequentemente é necessário fechar arquivos e criar novos, o que reduz a eficiência geral das gravações em disco.

O dimensionamento dos segmentos de log é importante quando os tópicos são caracterizados por uma baixa frequência de geração de mensagens. Por exemplo, se um tópico receber apenas 100 MB de mensagens por dia e o parâmetro log.segment.bytes estiver definido como o valor padrão, leva 10 dias para preencher um segmento. E como as mensagens não podem ser declaradas inválidas até o segmento de log ser fechado, com o valor de 604,8 milhões (1 semana) do parâmetro log.retention.ms, as mensagens podem acumular-se em 17 dias antes que o segmento de log fechado seja retirado de circulação. Isso ocorre porque quando você fecha um segmento com mensagens acumuladas por 10 dias, é necessário armazená-lo por mais 7 dias antes de poder retirá-lo de acordo com as regras temporárias adotadas, pois o segmento não pode ser excluído antes que a última mensagem nele expire. .

log.segment.ms

Outra maneira de controlar o fechamento dos segmentos de log é usar o parâmetro log.segment.ms, que especifica o período de tempo após o qual o segmento de log é fechado. Como os parâmetros log.retention.bytes e log.retention.ms, os parâmetros log.segment.bytes e log.segment.ms não são mutuamente exclusivos. Kafka fecha o segmento de log quando o tempo acabar ou o limite de tamanho especificado for atingido, dependendo de qual desses eventos ocorrer primeiro. Por padrão, o valor do parâmetro log.segment.ms não está definido e, como resultado, o fechamento dos segmentos de log é determinado pelo tamanho.

message.max.bytes

O broker Kafka permite usar o parâmetro message.max.bytes para limitar o tamanho máximo das mensagens geradas. O valor padrão para este parâmetro é 1.000.000 (1 MB). Um fabricante que tentar enviar uma mensagem maior receberá uma notificação de erro do broker, mas a mensagem não será aceita. Como no caso de todos os outros tamanhos em bytes especificados nas configurações do broker, estamos falando sobre o tamanho da mensagem compactada, para que os fabricantes possam enviar mensagens, cujo tamanho não compactado seja muito maior se puderem ser compactados nos limites especificados por message.max.bytes .

Aumentar o tamanho da mensagem pode afetar seriamente o desempenho. Um tamanho de mensagem maior significa que os threads do broker que processam as conexões e solicitações de rede levarão mais tempo para cada solicitação. Mensagens maiores também aumentam a quantidade de dados gravados no disco, o que afeta a taxa de transferência de E / S.

Seleção de hardware

Escolher o hardware certo para o corretor Kafka é mais uma arte do que uma ciência. A plataforma Kafka em si não possui requisitos rígidos de hardware; funcionará sem problemas em nenhum sistema. Mas se falamos de desempenho, ele é influenciado por vários fatores: capacidade e taxa de transferência de discos, RAM, rede e CPU.

Primeiro, você precisa decidir quais tipos de desempenho são mais importantes para o seu sistema; depois disso, você pode escolher a configuração ideal de hardware que se encaixa no orçamento.

Taxa de transferência do disco

A taxa de transferência dos discos do broker, usados ​​para armazenar segmentos de log, afeta diretamente o desempenho dos clientes de fabricação. As mensagens Kafka devem ser confirmadas no armazenamento local que confirma sua gravação. Somente então a operação de envio pode ser considerada bem-sucedida. Isso significa que, quanto mais rápido as operações de gravação no disco forem realizadas, menor será o atraso na geração de mensagens.

A ação óbvia em caso de problemas com a largura de banda dos discos é usar discos rígidos com placas giratórias (HDD) ou unidades de estado sólido (SSD). Os SSDs têm ordens de magnitude menor tempo de pesquisa / acesso e maior desempenho. Os HDDs são mais econômicos e têm uma capacidade relativa mais alta. O desempenho do HDD pode ser aprimorado devido ao seu maior número no broker, ou ao usar vários diretórios de dados ou à instalação de discos em uma matriz de discos independentes com redundância (RAID). Outros fatores influenciam a taxa de transferência, por exemplo, a tecnologia de fabricação de um disco rígido (por exemplo, SAS ou SATA), bem como as características do controlador de disco rígido.

Capacidade de disco

A capacidade é outro aspecto do armazenamento. A quantidade necessária de espaço em disco é determinada por quantas mensagens precisam ser armazenadas ao mesmo tempo. Se o corretor receber 1 TB de tráfego por dia, com 7 dias de armazenamento, ele precisará de armazenamento disponível para segmentos de log de pelo menos 7 TB. Você também deve considerar uma saturação de pelo menos 10% para outros arquivos, sem contar o buffer para possíveis flutuações de tráfego ou seu crescimento ao longo do tempo.

A capacidade de armazenamento é um dos fatores que devem ser considerados ao determinar o tamanho ideal do cluster Kafka e decidir sua expansão. O tráfego total do cluster pode ser balanceado por várias seções para cada tópico, o que permite o uso de intermediários adicionais para aumentar a capacidade disponível nos casos em que a densidade de dados por intermediário não é suficiente. A decisão sobre quanto espaço em disco é necessário também é determinada pela estratégia de replicação selecionada para o cluster (discutida em mais detalhes no Capítulo 6).

A memória

No modo normal de operação, o consumidor Kafka lê no final da seção e consome constantemente o tempo perdido e apenas um pouco atrás dos fabricantes, se é que o faz. , , . , , -.

Kafka JVM . , X X , 5 . Kafka . Kafka , , , Kafka.

, Kafka, . ( ) . Kafka ( ) . 1 , , . , (. 6) ( 8). , .

CPU

, , . . Kafka, , . . Kafka ' . .

Kafka

Kafka , , Amazon Web Services (AWS). AWS , CPU, . Kafka. , . / SSD. (, AWS Elastic Block Store). CPU .
, AWS m4 r3. m4 , , . r3 SSD-, . i2 d2.

Kafka

Kafka , (. 2.2). — . — . Kafka . Kafka. 6.

?

Kafka . — . 10 , 2 , — . , 100 % ( ) (. 6). , .

, , — . , ( ). 80 % , , . , , . , , .

Kafka. — zookeeper.connect. ZooKeeper . — broker.id. broker.id , . , , , .

Linux , , Kafka. , , . /etc/sysctl.conf, Linux, .

Linux . , «» , Kafka.
, , , () . , , Kafka. , Kafka , , .

— . — , - . . vm.swappiness , 1. ( ) , . , .

, «» , , . Kafka /. : (, SSD), NVRAM (, RAID). «» , . vm.dirty_background_ratio , ( 10). ( ), 5. 0, .

«» , , vm.dirty_ratio , — 20 ( ). , 60 80. , / . vm.dirty_ratio Kafka, .

«» Kafka . /proc/vmstat:

 # cat /proc/vmstat | egrep "dirty|writeback" nr_dirty 3875 nr_writeback 29 nr_writeback_temp 0 # 

Drive

, RAID- , . , EXT4 (fourth extended file system — ) XFS (Extents File System — ). EXT4 , . , (5), . EXT4 , . XFS , , EXT4. XFS Kafka , , . , /.

, , noatime. /: (ctime), (mtime) (atime). atime . . atime , , , ( realtime). Kafka atime, . noatime /, ctime mtime.

Linux — , , . Kafka , - . ( ) , . . net.core.wmem_default net.core.rmem_default , 2 097 152 (2 ). , , .

TCP net.ipv4.tcp_wmem net.ipv4.tcp_rmem. , , . — 4096 65536 2048000 — , 4 , — 64 , — 2 . , net.core.wmem_max net.core.rmem_max. Kafka .

. TCP 1 net.ipv4.tcp_window_scaling, . net.ipv4.tcp_max_syn_backlog , 1024, . net.core.netdev_max_backlog, 1000, , , , .

Kafka , .

Java , , . , Java 7 Garbage First (G1). G1 . , , .

G1 . .

• MaxGCPauseMillis. . — G1 . 200 . , G1 , , , , 200 .
• InitiatingHeapOccupancyPercent. , . 45. , G1 , 45 % , (Eden), .

Kafka , . 64 , Kafka 5 . 20 MaxGCPauseMillis. InitiatingHeapOccupancyPercent 35, , .

Kafka G1, . . :

 # export JAVA_HOME=/usr/java/jdk1.8.0_51 # export KAFKA_JVM_PERFORMANCE_OPTS="-server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true" # /usr/local/kafka/bin/kafka-server-start.sh -daemon /usr/local/kafka/config/server.properties # 

Kafka , . - , . Kafka (. 6), . Kafka, .

Kafka , , ( , , AWS), , . . , «» (. 6).

: Kafka , , , . ( ) . , , .

ZooKeeper

Kafka ZooKeeper , . ZooKeeper Kafka. , ZooKeeper Kafka . ZooKeeper Kafka ( ZooKeeper , ).

ZooKeeper . ZooKeeper, Kafka, . ZooKeeper , ZooKeeper . — 1 , . ZooKeeper, , . ZooKeeper , . , Kafka Kafka ZooKeeper.

Kafka, , . Kafka ZooKeeper, . ZooKeeper, . , , , . , , .

Sumário

, Apache Kafka. , , . , Kafka, Kafka. Kafka ( 3), ( 4).

»Mais informações sobre o livro podem ser encontradas no site do editor
» Conteúdo
» Trecho

20% — Apache Kafka