Essayez de comprendre la maintenance de la cohérence dans Kafka. Veuillez trouver le scénario et aider à comprendre.
Number of partition = 2
Replication factor = 3
Number of broker in the cluster = 4
Dans ce cas, pour obtenir la cohérence forte, combien de nœuds doivent reconnaître. Soit ack = all ou ack = 3 ou toute autre valeur. Veuillez confirmer la même chose.
3 Réponses :
Si vous recherchez la cohérence comme dans le domaine de la propriété ACID, toutes les répliques doivent être reconnues. Puisque vous avez 3 répliques, tous ces 3 nœuds doivent être reconnus.
Dans votre cadre, ce que vous avez est
Cela signifie que chaque message d'une partition donnée sera répliqué vers 3 courtiers sur 4, y compris le leader de cette partition.
Afin d'obtenir de solides garanties de cohérence, vous devez définir min.insync.replicas sur 2 et utiliser acks = all . De cette façon, vous avez la garantie que chaque écriture va à au moins 2 courtiers sur 3 qui détiennent les données, devant lesquelles elles sont reconnues.
La définition d'acks to all offre la meilleure garantie de cohérence au détriment des écritures plus lentes dans le cluster.
Si vous utilisez des versions plus anciennes de Kafka où l'élection de chef impur est true par défaut, vous devriez également envisager de définir cela sur false explicitement. De cette façon, un désynchronisation. le courtier ne sera pas élu en tant que leader en cas de crash du leader (compromettant effectivement la disponibilité).
De plus, Kafka est un système où toutes les lectures passent par le leader. Ceci est un peu différent de certains autres systèmes distribués tels que zookeeper qui prend en charge les répliques en lecture. Vous n'avez donc pas de situation où un client finit par lire directement auprès d'un courtier périmé. Leader s'assure que les écritures sont ordonnées et répliquées vers le nombre désigné de répliques synchronisées et acquittées en fonction de votre paramètre acks .
Vous voudrez peut-être voir Quand c'est absolument, Positivement, doit être là parler du sommet de Kafka.
Ce qui a été donné par un ingénieur de Cloudera, et Cloudera a leur propre documentation sur la disponibilité de Kafka
Pour résumer, plus d'une réplique et plus d'une réplique synchronisée est un bon début. Ensuite, sur le producteur, si vous êtes d'accord pour sacrifier le débit pour la disponibilité des données, ce qui signifie que vous devez avoir écrit tous les réplicas avant de continuer, alors acks = all . Sinon, si vous faites confiance au courtier leader pour être hautement disponible avec une élection de leader impur est faux, alors acks = 1 devrait être correct dans la plupart des cas.
acks = 3 n'est pas une configuration valide, d'ailleurs. Je pense que vous recherchez min.insync.replicas = 2 et acks = all avec un facteur de réplication de 3 ; à partir du lien ci-dessus
Si
min.insync.replicasest défini sur2etacksest défini surall, chaque message doit être écrit avec succès sur au moins deux répliques. Cela garantit que le message ne sera pas perdu à moins que les deux hôtes ne plantent
En outre, vous pouvez activer le producteur transactionnel, à partir de Kafka 0.11, pour travailler à un traitement exactement une fois
enable.idempotence=true
N'hésitez pas à fournir votre propre réponse, Pete