Répertoire d'articles
Concepts importants
courtier
Un courtier est une instance Kafka, responsable de la réception, du transfert et du stockage des messages. Un cluster Kafka est composé de plusieurs courtiers.
sujet
Le sujet de Kafka est un concept logique, c'est-à-dire le regroupement et la catégorisation des messages pour faciliter le traitement de différents messages de logique métier. Le concept d'index dans topic et Elasticsearch est similaire.
cloison
La partition de kafka est un concept physique, qui correspond à un dossier dans le système de fichiers. La partition est pour le sujet. Elle sert principalement à considérer la grande quantité de données de sujet. Elle peut être traitée en parallèle en fractionnant les données de sujet en partitions. , Améliorez le niveau de concurrence.
La partition dans kafka est similaire au fragment d'Elasticsearch, qui divisent tous deux physiquement les données de la classification logique unifiée.
segment
La partition de kafka correspond à un dossier. Après un peu de réflexion, vous constaterez que le stockage des messages doit être un fichier. Alors quel est le nom du fichier où Kafka stocke le message?
La réponse est segment, qui est traduit en segments dans de nombreux endroits.
Le segment est une autre division physique du sujet de Kafka.En configurant la taille du segment de manière raisonnable en fonction de la situation réelle de la machine et en coopérant avec le mécanisme d'indexation de Kafka, les opérations de lecture et d'écriture peuvent être effectuées plus rapidement.
décalage
offset est le décalage du message, ce décalage est le nombre de messages, pas d'octets
réplique
La réplique est une copie, essentiellement tous les middlewares distribués ont le concept de copie
La copie de Kafka est pour la partition, pas pour le sujet
Dans le cluster Kafka, la disponibilité est améliorée en distribuant différentes copies de la partition sur différents courtiers. Lorsqu'un courtier est en panne, d'autres copies sont disponibles.
La copie a deux attributs importants: LEO et HW
Log End Offset (LEO): le décalage du message suivant dans le journal
High Watermark (HW): le plus petit LEO de toutes les copies
Pourquoi le plus petit LEO parmi tous les exemplaires s'appelle-t-il à la place le high water mark (HW)?
Principalement parce que Kafka ne permet pas aux consommateurs de consommer plus que le plus petit message LEO dans toutes les répliques, il est donc appelé High Water Mark (HW)
Ceci est principalement dû aux incohérences de données. Par exemple, le LEO dans le leader est relativement grand, puis il se bloque, et d'autres copies deviennent le leader.
producteur
Générateur de messages, un service qui publie des messages sur le cluster Kafka
consommateur
Consommateur de messages, un service qui consomme les messages du cluster Kafka
Groupe de consommateurs
Le groupe de consommateurs est un concept de l'API de consommateurs de haut niveau. Chaque consommateur appartient à un groupe de consommateurs, et chaque message ne peut être consommé que par un seul consommateur du groupe de consommateurs, mais peut être consommé par plusieurs groupes de consommateurs.
En définissant le groupe Consommateur, un message peut être consommé par différents groupes, ce qui est très pratique. Par exemple, un message de connexion peut être requis à la fois pour l'entreprise de statistiques de données et l'activité commerciale. Il vous suffit ensuite de configurer différents groupes de consommateurs pour utiliser la même connexion. nouvelles.
leader 与 suiveur
La copie a 2 rôles, l'un est leader et l'autre est suiveur.
Il n'y a qu'un seul leader dans la même copie et les autres copies sont des suiveurs.
Le producteur et le consommateur n'interagissent qu'avec le leader, puis le leader et le suiveur interagissent.
Par exemple, le producteur envoie un message au leader, et le leader transmet le message au suiveur, et exécutera différentes réponses selon la configuration d'accusé de réception du producteur, qui sera décrite en détail plus loin.
manette
Le contrôleur est pour le courtier. Les courtiers du cluster Kafka éliront un chef pour contrôler l'élection du chef de la partition, le basculement et les autres opérations. Le chef élu par le courtier est le contrôleur.
L'élection des courtiers dépend de Zookeeper. Les nœuds de courtier vont à Zookeeper pour enregistrer un nœud temporaire. Étant donné qu'un seul courtier s'enregistrera avec succès, les autres échoueront. Le courtier qui a enregistré avec succès le nœud temporaire sur Zookeeper deviendra le contrôleur, et les autres courtiers seront appelés courtier suiveur. .
Le contrôleur surveillera toutes les informations des autres courtiers. Si le contrôleur tombe en panne, le nœud temporaire sur zookeeper disparaîtra. À ce stade, tous les courtiers iront à Zookeeper pour enregistrer un nœud temporaire ensemble, car un seul courtier s'enregistrera avec succès , Tout le reste échouera, donc le courtier qui a enregistré avec succès le nœud temporaire sur Zookeeper deviendra le nouveau contrôleur.
Une fois qu'un courtier tombe en panne, le contrôleur lira l'état de toutes les partitions sur le courtier en panne sur le gardien de zoo et sélectionnera une réplique dans la liste ISR en tant que chef de partition.
Si les répliques de la liste ISR sont toutes en panne, choisissez une réplique survivante comme chef de file;
si toutes les répliques de la partition sont en panne, définissez le nouveau chef de file sur -1, attendez la récupération et attendez que toute réplique de l’ISR se rétablisse. , Et choisissez-le comme chef; ou choisissez la première réplique à survivre, pas nécessairement le chef des ISR.
Lorsque le courtier est en panne, le contrôleur informera également le gardien de zoo et le gardien de zoo en informera les autres courtiers.
Problème de fractionnement du cerveau du courtier: une fois que le
contrôleur est enregistré avec succès sur Zookeeper, la valeur par défaut du délai d'expiration pour la communication avec Zookeeper est de 6 s, c'est-à-dire que si le contrôleur n'a pas de battement de cœur avec Zookeeper dans 6 s, Zookeeper pense que le contrôleur est mort.
Ce nœud temporaire sera supprimé sur Zookeeper, puis les autres courtiers penseront que le contrôleur est parti et se précipiteront pour enregistrer à nouveau le nœud temporaire, et le courtier enregistré avec succès deviendra le contrôleur.
Ensuite, le contrôleur précédent a besoin de divers arrêts pour arrêter la surveillance de divers nœuds et événements. Mais lorsque le trafic de lecture et d'écriture de Kafka est très important, le message provenant du producteur à ce moment ne peut pas être reçu en raison de la présence de deux contrôleurs dans le cluster Kafka, ce qui entraîne une accumulation de données.
coordinateur
Le coordinateur de groupe est un service, et chaque courtier démarrera un service lorsqu'il démarrera.
La fonction du coordinateur de groupe est de stocker les méta-informations associées du groupe et d'enregistrer les informations de décalage de la partition correspondante dans la rubrique __consumer_offsets de Kafka.
Avant la version 0.9, Kafka était basé sur Zookeeper pour stocker les informations de décalage de la partition (consumer / {group} / offsets / {topic} / {partition}), car ZK ne convient pas aux opérations d'écriture fréquentes, donc après la version 0.9, via le Topic intégré Manière d'enregistrer le décalage de la partition correspondante.
Configuration importante de Kafka
lié au boker
#在集群中的唯一标识broker，非负数
broker.id=1
#broker server服务端口
port=9091
#kafka数据的存放地址，多个地址的话用逗号分割D:\\data11，D:\\data12
log.dirs=D:\\kafkas\\datas\\data1
#ZK集群的地址，可以是多个，多个之间用逗号分割hostname1:port1,hostname2:port2
zookeeper.connect=localhost:2181
#ZK连接超时时间
zookeeper.connection.timeout.ms=6000
#ZK会话超时时间
zookeeper.session.timeout.ms=6000
#segment日志的索引文件大小限制，会被topic创建时的指定参数覆盖
log.index.size.max.bytes =10*1024*1024
#segment的大小，达到指定大小会新创建一个segment文件，会被topic创建时的指定参数覆盖
log.segment.bytes =1024*1024*1024
# broker接受的消息体的最大大小
message.max.bytes = 1000012
#broker处理消息的最大线程数
num.network.threads=3
#broker处理磁盘IO的线程数
num.io.threads=8
#socket的发送缓冲区
socket.send.buffer.bytes=102400
#socket的接受缓冲区
socket.receive.buffer.bytes=102400
#socket请求的最大数值，message.max.bytes必然要小于socket.request.max.bytes
socket.request.max.bytes=104857600
#topic默认分区个数，会被topic创建时的指定参数覆盖
num.partitions=1
#partition副本数量配置，默认1，表示没有副本，2表示除了leader还有一个follower
default.replication.factor =1
#是否允许自动创建topic，若是false，就需要手动创建topic
auto.create.topics.enable =true
producteur (lié au producteur)
# 0不管消息是否写入成功，1只需要leader写入消息成功，all需要leader和ISR中的follower都写入成功
acks = 1
#设置生产者内存缓冲区的大小，生产者用它缓冲要发送到服务器的消息。
#如果应用程序发送消息的速度超过发送到服务器的速度，会导致生产者空间不足。这个时候，send()方法调用要么被阻塞，要么抛出异常
buffer.memory = 10240
# 当buffer.memory不足，阻塞多久抛出异常
max.block.ms = 3000
# 默认消息发送时不会被压缩。可设置为snappy、gzip、lz4
compression.type = snappy
# 重试次数
retries = 0
# 重试时间间隔
retry.backoff.ms = 100
# 发向相同partition每个批次的大小,默认16384
batch.size = 10240
# batch.size要产生消息比发送消息快才会出现
# linger.ms可以控制让发送等n毫秒再发送，以达到批量发送的目的
linger.ms = 0
# 控制生产者每次发送的请求大小，默认1M
max.request.size = 1048576
# 指定了生产者在收到服务器响应之前可以发送多少个消息
max.in.flight.requests.per.connection = 1
# tcp缓冲区大小
receive.buffer.bytes = 4096
send.buffer.bytes = 4096
L'algorithme de compression rapide occupe moins de CPU, a de meilleures performances et un meilleur taux de compression. L'
algorithme de compression gzip occupe plus de CPU, mais il fournira un taux de compression plus élevé.
max.in.flight.requests.per.connection provoque des problèmes de séquence de messages. Si: retries> 0 && max.in.flight.requests.per.connection> 1:
alors, si le premier lot de messages ne parvient pas à être écrit, et Si le deuxième lot est correctement écrit, il réessayera d'écrire le premier lot. Si le premier lot est également écrit correctement à ce moment, l'ordre des deux lots est inversé.
max.in.flight.requests.per.connection = 1, même si une nouvelle tentative se produit, il peut être garanti que le message est écrit dans l'ordre dans lequel il a été envoyé.
consommateur (lié au consommateur)
# broker服务器列表
bootstrap.servers=localhost:9092,localhost:9093,localhost:9094
# 消费者每次poll数据时的最大数量
max.poll.records = 500
# 为true则自动提交偏移量
enable.auto.commit = true
# 自动提交偏移量周期(时间间隔)
auto.commit.interval.ms = 5000
# 如果该配置时间内consumer没有响应Coordinator的心跳检测，就认为consumer挂了，rebalance
session.timeout.ms = 10000
# Coordinator的心跳检测周期
heartbeat.interval.ms = 2000
# 当没有初始偏移量时，怎么办，默认latest
# earliest: 自动重置为最早的offset
# latest: 自动重置为最后的offset
# none: 如果在消费者组中没有前置的offset，抛异常
auto.offset.reset=latest
# 一次最小拉取多少字节，默认1字节
fetch.min.bytes=1
# 一次最多拉取多少字节数据，默认50M
fetch.max.bytes=52428800
# 一次拉取最多等待多少毫秒，默认500
fetch.max.wait.ms=500
réplique (liée à la réplique)
#leader等待follower的最常时间，超过就將follower移除ISR(in-sync replicas)
replica.lag.time.max.ms =10000
#follower最大落后leader多少条消息，把此replicas迁移到其他follower中，在broker数量较少,或者网络不足的环境中,建议提高此值
replica.lag.max.messages =4000
#follower与leader之间的socket超时时间
replica.socket.timeout.ms=30*1000
#leader复制时候的socket缓存大小
replica.socket.receive.buffer.bytes=64*1024
#replicas每次获取数据的最大大小
replica.fetch.max.bytes =1024*1024
#replicas同leader之间通信的最大等待时间，失败了会重试
replica.fetch.wait.max.ms =500
#fetch的最小数据尺寸,如果leader中尚未同步的数据小于该值,将会阻塞,直到满足条件
replica.fetch.min.bytes =1
#leader进行复制的线程数，增大这个数值会增加follower的IO
num.replica.fetchers=1
journal (lié au journal)
#segment文件大小，会被topic创建时的指定参数覆盖
log.segment.bytes =1024*1024*1024
#segment滚动时间，没有达到log.segment.bytes也会强制新建一个segment，topic参数覆盖
log.roll.hours =24*7
#日志清理策略选择有：delete和compact主要针对过期数据的处理
log.cleanup.policy = delete
#数据存储的最大时间超过这个时间会根据log.cleanup.policy设置的策略处理数据
log.retention.minutes=6000
#topic每个分区大小，一个topic的大小限制=分区数*log.retention.bytes，-1没有大小
log.retention.bytes=-1
#文件大小检查的周期时间
log.retention.check.interval.ms=50000
#是否开启日志清理，默认true
log.cleaner.enable=true
#日志清理的线程数
log.cleaner.threads = 2
#日志清理时候处理的最大大小
log.cleaner.io.max.bytes.per.second=None
#日志清理去重时候的缓存空间，在空间允许的情况下，越大越好
log.cleaner.dedupe.buffer.size=500*1024*1024
#日志清理时候用到的IO块大小一般不需要修改
log.cleaner.io.buffer.size=512*1024
#值越大一次清理越多，hash冲突也越严重
log.cleaner.io.buffer.load.factor=0.9
#检查是否有需要清理的日志间隔
log.cleaner.backoff.ms =15000
#日志清理的频率控制，越大意味着更高效的清理，同时会存在一些空间上的浪费，topic参数覆盖
log.cleaner.min.cleanable.ratio=0.5
#对于压缩的日志保留的最长时间，会被topic创建时的指定参数覆盖
log.cleaner.delete.retention.ms =100000
#对于segment日志的索引文件大小限制，会被topic创建时的指定参数覆盖
log.index.size.max.bytes =10*1024*1024
#索引的offset间隔，设置越大，扫描速度越快，但是也更吃内存
log.index.interval.bytes =4096
#多少条消息，执行一次刷新到磁盘操作
log.flush.interval.messages=9223372036854775807
#多少毫秒之后刷新到磁盘一次，没有设置使用log.flush.scheduler.interval.ms
log.flush.interval.ms = null
#检查是否需要刷新到磁盘的时间间隔
log.flush.scheduler.interval.ms =3000
#文件在索引中清除后保留的时间一般不需要去修改
log.delete.delay.ms =60000
#控制上次落盘的时间点，以便于数据恢复
log.flush.offset.checkpoint.interval.ms =60000
Le paramètre log.cleanup.policy contrôle clairement le journal, la valeur par défaut est de supprimer, vous pouvez définir le paramètre log.cleanup.policy sur "delete, compact"
Le compact ici n'est pas de compresser, mais d'intégrer la clé de chaque message. Pour différentes valeurs de valeurs avec la même clé, seule la dernière version est conservée.
Faites attention à la différence entre compact et compression. Compact ressemble plus au marquage et au tri de la récupération de la mémoire. La compression signifie la compression. La compression dans kafka est pour le contenu du message.
La suppression de Kafka peut être basée sur 3:
- Basé sur le temps
- Basé sur la taille
- Basé sur le décalage
Log.retention.hours, log.retention.minutes et log.retention.ms sont configurés, et la
configuration temporelle a la priorité de haut en bas:
- log.retention.ms
- log.retention.minutes
- log.retention.hours
Par défaut, seul le paramètre log.retention.hours est configuré et sa valeur est 168. Par conséquent, la durée de rétention du fichier de segment journal est de 7 jours par défaut.
La suppression basée sur la taille est contrôlée par le paramètre log.retention.bytes, la valeur par défaut est -1 et il n'y a pas de limite de taille.
Si l'un des log.retention.bytes et log.retention.minutes répond aux exigences, il sera supprimé et écrasé par les paramètres spécifiés lors de la création de la rubrique.
Kafka fusionnera les segments à chaque fois après le nettoyage du journal. Après la fusion, la taille ne dépassera pas la configuration log.segments.bytes et la valeur par défaut est 1 Go.
manette
#是否允许关闭broker,若是设置为true,会关闭所有在broker上的leader，并转移到其他broker
controlled.shutdown.enable=false
#控制器关闭的尝试次数
controlled.shutdown.max.retries=3
#每次关闭尝试的时间间隔
controlled.shutdown.retry.backoff.ms=5000
#partition leader与replicas之间通讯时,socket的超时时间
controller.socket.timeout.ms =30000
#partition leader与replicas数据同步时,消息的队列尺寸
controller.message.queue.size=10
control.shutdown.enable = true est principalement pour un arrêt progressif:
- Peut accélérer le redémarrage
- Laissez le leader changer plus rapidement et réduisez l'indisponibilité de chaque partition à quelques millisecondes
Pour résumer
