Le livre "Apache Kafka. Traitement des flux et analyse des données »

Pendant le travail de toute application d'entreprise, des données sont générées: ce sont des fichiers journaux, des métriques, des informations sur l'activité des utilisateurs, des messages sortants, etc. Une manipulation correcte de toutes ces données n'est pas moins importante que les données elles-mêmes. Si vous êtes un architecte, un développeur ou un ingénieur diplômé qui souhaite résoudre de tels problèmes, mais qui n'est pas encore familier avec Apache Kafka, alors, dans ce merveilleux livre, vous apprendrez à travailler avec cette plate-forme de streaming gratuite qui vous permet de traiter les files d'attente de données en temps réel.

À qui s'adresse ce livre?

«Apache Kafka. Stream processing and data analysis »a été écrit pour les développeurs qui utilisent l'API Kafka dans leur travail, ainsi que les ingénieurs de processus (également appelés SRE, DevOps ou administrateurs système) qui sont impliqués dans l'installation, la configuration, la configuration et la surveillance de son fonctionnement pendant l'exploitation industrielle. Nous n'avons pas non plus oublié les architectes de données et les ingénieurs analytiques - ceux qui sont responsables de la conception et de la création de l'ensemble de l'infrastructure de données de l'entreprise. Certains chapitres, en particulier 3, 4 et 11, sont destinés aux développeurs Java. Pour les comprendre, il est important que le lecteur soit familiarisé avec les bases du langage de programmation Java, y compris les problèmes tels que la gestion des exceptions et la concurrence.

D'autres chapitres, en particulier 2, 8, 9 et 10, supposent que le lecteur a une expérience avec Linux et est familier avec la configuration du réseau et du stockage Linux. Le reste du livre et les architectures logicielles de Kafka sont discutés en termes plus généraux, donc aucune connaissance particulière n'est requise des lecteurs.

Une autre catégorie de personnes susceptibles d'être intéressées par ce livre sont les gestionnaires et les architectes qui travaillent non pas directement avec Kafka, mais avec ceux qui y travaillent. Il est tout aussi important qu’ils comprennent quelles sont les garanties de la plate-forme et quels compromis leurs subordonnés et collègues devront faire lors de la création de systèmes basés sur Kafka. Ce livre sera utile aux gestionnaires qui souhaitent former leurs employés à travailler avec Kafka ou à s'assurer que l'équipe de développement possède les informations nécessaires.

Chapitre 2. Installer Kafka

Apache Kafka est une application Java qui peut s'exécuter sur de nombreux systèmes d'exploitation, y compris Windows, MacOS, Linux et autres. Dans ce chapitre, nous nous concentrerons sur l'installation de Kafka sur Linux, car c'est la plate-forme qui est le plus souvent installée sur ce système d'exploitation. Linux est également le système d'exploitation recommandé pour le déploiement Kafka à usage général. Pour plus d'informations sur l'installation de Kafka sur Windows et MacOS, voir l'annexe A.

Installer Java

Avant d'installer ZooKeeper ou Kafka, vous devez installer et configurer l'environnement Java. Il est recommandé d'utiliser Java 8, et il peut s'agir d'une version, soit incluse dans votre système d'exploitation, soit téléchargée directement sur java.com. Bien que ZooKeeper et Kafka fonctionnent avec Java Runtime Edition, il est plus pratique d'utiliser le kit de développement Java (JDK) complet lors du développement d'utilitaires et d'applications. Ces étapes d'installation supposent que JDK version 8.0.51 est installé dans le répertoire /usr/java/jdk1.8.0_51.

Installez ZooKeeper

Apache Kafka utilise ZooKeeper pour stocker des métadonnées sur le cluster Kafka, ainsi que des détails sur les clients consommateurs (Fig. 2.1). Bien que ZooKeeper puisse également être lancé à l'aide de scripts inclus dans la distribution Kafka, l'installation de la version complète du référentiel ZooKeeper à partir de la distribution est très simple.


Kafka a été soigneusement testé avec la version stable 3.4.6 du référentiel ZooKeeper, qui peut être téléchargée depuis apache.org.

Serveur autonome

L'exemple suivant illustre l'installation de ZooKeeper avec les paramètres de base dans le répertoire / usr / local / zookeeper et l'enregistrement des données dans le répertoire / 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 # 

Vous pouvez maintenant vérifier que ZooKeeper est censé fonctionner hors ligne en se connectant au port client et en envoyant la commande srvr à quatre lettres:

 # 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

Le cluster ZooKeeper est appelé un ensemble. En raison de la nature de l'algorithme lui-même, il est recommandé que l'ensemble comprenne un nombre impair de serveurs, par exemple 3, 5, etc., car pour que ZooKeeper puisse répondre aux demandes, la majorité des membres de l'ensemble doivent fonctionner (quorum). Cela signifie qu'un ensemble de trois nœuds peut fonctionner avec un nœud inactif. Si l'ensemble a trois nœuds, il peut y en avoir deux.

Pour configurer le fonctionnement des serveurs ZooKeeper dans l'ensemble, ils doivent avoir une configuration unique avec une liste de tous les serveurs, et chaque serveur du répertoire de données doit avoir un fichier myid avec l'identifiant de ce serveur. Si les hôtes de l'ensemble sont nommés zoo1.example.com, zoo2.example.com et zoo3.example.com, le fichier de configuration peut ressembler à ceci:

 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 

Dans cette configuration, initLimit est la durée pendant laquelle les nœuds esclaves peuvent se connecter au maître. La valeur syncLimit limite le décalage des nœuds esclaves par rapport au maître. Les deux valeurs sont spécifiées en unités tickTime, c'est-à-dire initLimit = 20 · 2000 ms = 40 s. La configuration répertorie également tous les serveurs d'ensemble. Ils sont au format server.X = hostname: peerPort: leaderPort avec les paramètres suivants:

• X est l'identifiant du serveur. Ce doit être un entier, mais le compte peut ne pas être de zéro et ne pas être séquentiel;
• nom d'hôte - nom d'hôte ou adresse IP du serveur;
• peerPort - Port TCP par lequel les serveurs d'ensemble communiquent entre eux;
• leaderPort - Port TCP par lequel l'hôte est sélectionné.

Il suffit que les clients puissent se connecter à l'ensemble via le port clientPort, mais les membres de l'ensemble doivent pouvoir échanger des messages entre eux sur les trois ports.

En plus d'un fichier de configuration unique, chaque serveur du répertoire dataDir doit avoir un fichier myid. Il doit contenir l'identifiant du serveur correspondant à celui donné dans le fichier de configuration. Après avoir terminé ces étapes, vous pouvez démarrer les serveurs et ils interagiront les uns avec les autres dans l'ensemble.

Installation de Kafka Broker

Après avoir terminé la configuration de Java et ZooKeeper, vous pouvez procéder à l'installation d'Apache Kafka. La dernière version d'Apache Kafka peut être téléchargée sur kafka.apache.org/downloads.html .

Dans l'exemple suivant, installez la plate-forme Kafka dans le répertoire / usr / local / kafka, configurez-la pour utiliser le serveur ZooKeeper précédemment lancé et enregistrez les segments du journal des messages dans le répertoire / 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 # 

Après avoir lancé le courtier Kafka, vous pouvez tester son fonctionnement en effectuant des opérations simples avec le cluster, notamment en créant une rubrique de test, en générant des messages et en les consommant.

Création et vérification de 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 # 

Génération de messages pour le sujet de test:

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

Consommation de messages du sujet de test:

 # /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 # 

Configuration du courtier

L'exemple de configuration de courtier fourni avec la distribution Kafka est tout à fait approprié pour une version d'essai d'un serveur autonome, mais pour la plupart des installations, ce ne sera pas suffisant. Il existe de nombreuses options de configuration de Kafka qui régissent tous les aspects de l'installation et de la configuration. Vous pouvez laisser les valeurs par défaut pour bon nombre d'entre elles, car elles se rapportent aux nuances de la configuration d'un courtier Kafka qui ne s'appliquent pas tant que vous ne travaillez pas avec un scénario spécifique nécessitant leur utilisation.

Paramètres de base du courtier

Il existe plusieurs paramètres du courtier Kafka que vous devez prendre en compte lors du déploiement de la plate-forme dans n'importe quel environnement, à l'exception d'un courtier autonome sur un serveur distinct. Ces paramètres se rapportent aux paramètres principaux du courtier et la plupart d'entre eux doivent être modifiés pour que le courtier puisse travailler en cluster avec d'autres courtiers.

broker.id

Chaque courtier Kafka doit avoir un identifiant entier spécifié par le paramètre broker.id. Par défaut, cette valeur est 0, mais peut être n'importe quel nombre. L'essentiel est qu'il ne se répète pas au sein du même cluster Kafka. Le choix du numéro peut être arbitraire et, si nécessaire, pour la commodité de la maintenance, il peut être transféré d'un courtier à un autre. Il est souhaitable que ce numéro soit en quelque sorte connecté à l'hôte, la correspondance des identifiants de courtier avec les hôtes avec suivi sera plus transparente. Par exemple, si vos noms d'hôtes contiennent des nombres uniques (par exemple, host1.example.com, host2.example.com, etc.), ces nombres seraient un bon choix pour les valeurs broker.id.

port

Un fichier de configuration typique démarre Kafka avec un écouteur sur le port TCP 9092. Ce port peut être changé en tout autre disponible en changeant le port du paramètre de configuration. Gardez à l'esprit que lorsque vous choisissez un port avec un nombre inférieur à 1024, Kafka doit être exécuté en tant que root. Il n'est pas recommandé d'exécuter Kafka en tant que root.

zookeeper.connect

Le chemin utilisé par ZooKeeper pour stocker les métadonnées du courtier est défini à l'aide du paramètre de configuration zookeeper.connect. Dans l'exemple de configuration, ZooKeeper s'exécute sur le port 2181 sur l'hôte local, qui est indiqué comme localhost: 2181. Le format de ce paramètre est une liste de lignes séparées par un point-virgule de la forme nom d'hôte: port / chemin, y compris:

• nom d'hôte - nom d'hôte ou adresse IP du serveur ZooKeeper;
• port - numéro de port client pour le serveur;
• / path - un chemin ZooKeeper facultatif utilisé comme nouveau chemin racine (chroot) du cluster Kafka. S'il n'est pas spécifié, le chemin racine est utilisé.

Si le chemin de chroot spécifié n'existe pas, il sera créé au démarrage du courtier.

log.dirs

Kafka enregistre tous les messages sur le disque dur et ces segments du journal sont stockés dans les répertoires spécifiés dans le paramètre log.dirs. Il s'agit d'une liste de chemins séparés par des virgules dans le système local. Si plusieurs chemins sont spécifiés, le courtier y enregistrera des sections selon le principe du moins utilisé, avec conservation des segments de journal d'une section le long d'un chemin. Notez que le courtier placera la nouvelle section dans le répertoire dans lequel au moins les partitions sont actuellement stockées, et non le moindre espace est utilisé, de sorte que la distribution uniforme des données entre les sections n'est pas garantie.

num.recovery.threads.per.data.dir

Kafka utilise un pool de threads personnalisé pour traiter les segments de journal. Actuellement, il est appliqué:

• pendant le démarrage normal - pour ouvrir les segments de journal de chaque section;
• commencer après un échec - pour vérifier et tronquer les segments de journal de chaque section;
• Stop - pour fermer doucement les segments de journal.

Par défaut, un seul thread est utilisé par répertoire de journaux. Étant donné que cela ne se produit qu'au démarrage et à l'arrêt, il est logique d'en utiliser davantage afin de paralléliser les opérations. Lors de la récupération d'un arrêt incorrect, les avantages de l'utilisation de cette approche peuvent atteindre plusieurs heures si le courtier avec un grand nombre de partitions est redémarré! N'oubliez pas que la valeur de ce paramètre est déterminée en fonction d'un répertoire de journaux à partir du numéro spécifié à l'aide de log.dirs. En d'autres termes, si la valeur du paramètre num.recovery.threads.per.data.dir est 8 et que trois chemins d'accès sont spécifiés dans log.dirs, le nombre total de threads est de 24.

auto.create.topics.enable

Selon la configuration par défaut de Kafka, le courtier doit créer automatiquement un thème lorsque:

• le fabricant commence à écrire dans la ligne d'objet;
• le consommateur commence à lire le sujet du message;
• tout client demande des métadonnées de rubrique.

Dans de nombreux cas, ce comportement peut être indésirable, notamment en raison du fait qu'il n'y a aucun moyen de vérifier l'existence d'un sujet à l'aide du protocole Kafka sans provoquer sa création. Si vous contrôlez la création de cela explicitement, manuellement ou via le système d'initialisation, vous pouvez définir le paramètre auto.create.topics.enable sur false.

Paramètres de thème par défaut

La configuration du serveur Kafka définit de nombreux paramètres par défaut pour les thèmes créés. Certains de ces paramètres, notamment le nombre de sections et les paramètres d'enregistrement des messages, peuvent être définis séparément pour chaque rubrique à l'aide des outils d'administration (abordés au chapitre 9). Les valeurs par défaut dans la configuration du serveur doivent être définies égales aux valeurs de référence qui conviennent à la plupart des rubriques de cluster.

num.partitions

Le paramètre num.partitions détermine avec combien de sections un nouveau sujet est créé, principalement lorsque la création automatique par thèmes est activée (ce qui est le comportement par défaut). La valeur par défaut de ce paramètre est 1. Gardez à l'esprit que le nombre de sections pour un sujet ne peut être augmenté, mais pas réduit. Cela signifie que s'il nécessite moins de partitions que ce qui est indiqué dans num.partitions, vous devrez le créer soigneusement manuellement (cela est expliqué au chapitre 9).

Comme indiqué au chapitre 1, les sections sont un moyen de mettre à l'échelle des sujets dans un cluster Kafka, il est donc important que vous en ayez autant que nécessaire pour équilibrer la charge des messages sur l'ensemble du cluster à mesure que des courtiers sont ajoutés. De nombreux utilisateurs préfèrent que le nombre de partitions soit égal ou le nombre de courtiers dans le cluster. Cela permet de répartir uniformément les sections entre les courtiers, ce qui conduira à une répartition uniforme de la charge entre les messages. Cependant, ce n'est pas une exigence obligatoire, car la présence de plusieurs rubriques vous permet d'équilibrer la charge.

log.retention.ms

Le plus souvent, le stockage des messages à Kafka est limité dans le temps. La valeur par défaut est spécifiée dans le fichier de configuration à l'aide du paramètre log.retention.hours et est égale à 168 heures ou 1 semaine. Cependant, vous pouvez utiliser deux autres paramètres - log.retention.minutes et log.retention.ms. Ces trois paramètres déterminent la même chose - la période de temps après laquelle les messages sont supprimés. Mais il est recommandé d'utiliser le paramètre log.retention.ms, car si plusieurs paramètres sont spécifiés, la priorité appartient à la plus petite unité de mesure, donc la valeur de log.retention.ms sera toujours utilisée.

log.retention.bytes

Une autre façon de limiter la validité des messages est basée sur la taille totale (en octets) des messages stockés. La valeur est définie à l'aide du paramètre log.retention.bytes et est appliquée séparément. Cela signifie que dans le cas d'un sujet de huit sections et égal à 1 Go de la valeur de log.retention.bytes, la quantité maximale de données stockées pour ce sujet sera de 8 Go. Notez que la quantité de stockage dépend des sections individuelles et non du sujet. Cela signifie que si le nombre de sections de la rubrique augmente, la quantité maximale de données enregistrées lors de l'utilisation de log.retention.bytes augmentera également.

log.segment.bytes

Les paramètres de journalisation mentionnés concernent des segments de journal et non des messages individuels. Au fur et à mesure que les messages sont générés par le courtier Kafka, ils sont ajoutés à la fin du segment de journal actuel de la section correspondante. Lorsque le segment de journal atteint la taille spécifiée par le paramètre log.segment.bytes et est égal à 1 Go par défaut, ce segment se ferme et un nouveau s'ouvre. Après la fermeture, le segment de journal peut être retiré. Plus la taille des segments de journal est petite, plus vous devez souvent fermer des fichiers et en créer de nouveaux, ce qui réduit l'efficacité globale des écritures sur disque.

Le dimensionnement des segments de journal est important lorsque les sujets sont caractérisés par une faible fréquence de génération de messages. Par exemple, si une rubrique ne reçoit que 100 Mo de messages par jour et que le paramètre log.segment.bytes est défini sur la valeur par défaut, il faut 10 jours pour remplir un segment. Et comme les messages ne peuvent pas être déclarés invalides tant que le segment de journal n'est pas fermé, alors avec la valeur de 604,8 millions (1 semaine) du paramètre log.retention.ms, les messages peuvent s'accumuler en 17 jours avant que le segment de journal fermé ne soit retiré de la circulation. En effet, lorsque vous fermez un segment avec des messages qui se sont accumulés sur 10 jours, vous devez le stocker pendant 7 jours supplémentaires avant de pouvoir le retirer conformément aux règles temporaires adoptées, car le segment ne peut pas être supprimé avant l'expiration du dernier message qu'il contient. .

log.segment.ms

Une autre façon de contrôler la fermeture des segments de journal consiste à utiliser le paramètre log.segment.ms, qui spécifie la durée après laquelle le segment de journal est fermé. Comme les paramètres log.retention.bytes et log.retention.ms, les paramètres log.segment.bytes et log.segment.ms ne s'excluent pas mutuellement. Kafka ferme le segment de journal lorsque le temps est écoulé ou que la taille limite spécifiée est atteinte, selon lequel de ces événements se produit en premier. Par défaut, la valeur du paramètre log.segment.ms n'est pas définie, de sorte que la fermeture des segments de journal est déterminée par leur taille.

message.max.bytes

Le courtier Kafka permet d'utiliser le paramètre message.max.bytes pour limiter la taille maximale des messages générés. La valeur par défaut de ce paramètre est 1 000 000 (1 Mo). Un fabricant qui essaie d'envoyer un message plus volumineux recevra une notification d'erreur du courtier, mais le message ne sera pas accepté. Comme dans le cas de toutes les autres tailles en octets spécifiées dans les paramètres du courtier, nous parlons de la taille du message compressé, afin que les fabricants puissent envoyer des messages, dont la taille non compressée est beaucoup plus grande s'ils peuvent être compressés dans les limites spécifiées par message.max.bytes .

L'augmentation de la taille du message peut sérieusement affecter les performances. Une taille de message plus importante signifie que les threads de courtier qui traitent les connexions et les demandes réseau prendront plus de temps pour chaque demande. Les messages plus volumineux augmentent également la quantité de données écrites sur le disque, ce qui affecte le débit d'E / S.

Sélection du matériel

Choisir le bon matériel pour le courtier Kafka est plus un art qu'une science. La plate-forme Kafka elle-même n'a pas d'exigences matérielles strictes; elle fonctionnera sans problème sur n'importe quel système. Mais si nous parlons de performances, elles sont influencées par plusieurs facteurs: capacité et débit des disques, RAM, réseau et CPU.

Vous devez d'abord décider quels types de performances sont les plus importants pour votre système, après quoi vous pouvez choisir la configuration matérielle optimale qui correspond au budget.

Débit du disque

Le débit des disques du courtier, qui sont utilisés pour stocker des segments de journal, affecte directement les performances des clients de fabrication. Les messages Kafka doivent être enregistrés dans un stockage local qui confirme leur enregistrement. Ce n'est qu'alors que l'opération d'envoi peut être considérée comme réussie. Cela signifie que plus les opérations d'écriture sur le disque sont rapides, moins le délai de génération des messages sera long.

L'action évidente en cas de problèmes avec la bande passante des disques est d'utiliser des disques durs avec des plaques tournantes (HDD) ou des disques SSD. Les SSD ont des temps de recherche / d'accès inférieurs et des performances supérieures. Les disques durs sont plus économiques et ont une capacité relative plus élevée. Les performances des disques durs peuvent être améliorées en raison de leur plus grand nombre dans le courtier, ou en utilisant plusieurs répertoires de données, ou en installant des disques dans une matrice de disques indépendants avec redondance (matrice redondante de disques indépendants, RAID). D'autres facteurs influencent le débit, par exemple, la technologie de fabrication d'un disque dur (par exemple, SAS ou SATA), ainsi que les caractéristiques du contrôleur de disque dur.

Capacité disque

La capacité est un autre aspect du stockage. La quantité d'espace disque requise est déterminée par le nombre de messages qui doivent être stockés en même temps. Si le courtier doit recevoir 1 To de trafic par jour, alors avec un stockage de 7 jours, il aura besoin d'un stockage disponible pour des segments de journal d'au moins 7 To. Vous devez également envisager un dépassement d'au moins 10% pour les autres fichiers, sans compter la mémoire tampon pour les éventuelles fluctuations du trafic ou sa croissance dans le temps.

La capacité de stockage est l'un des facteurs à prendre en compte pour déterminer la taille optimale du cluster Kafka et décider de son expansion. Le trafic total du cluster peut être équilibré par plusieurs sections pour chaque rubrique, ce qui vous permet d'utiliser des courtiers supplémentaires pour augmenter la capacité disponible dans les cas où la densité de données par courtier n'est pas suffisante. La décision sur la quantité d'espace disque nécessaire est également déterminée par la stratégie de réplication sélectionnée pour le cluster (discutée plus en détail au chapitre 6).

La mémoire

Dans le mode de fonctionnement normal, le consommateur Kafka lit à partir de la fin de la section, et le consommateur rattrape constamment le temps perdu et seulement légèrement derrière les fabricants, voire pas du tout. , , . , , -.

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 # 

Conduire

, 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, . , , , . , , .

Résumé

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

»Plus d'informations sur le livre sont disponibles sur le site Web de l'éditeur
» Contenu
» Extrait

20% — Apache Kafka