2017-08-07 4 views
0

Nous utilisons actuellement un producteur par sujet. Nous envisageons de passer à un producteur pour plusieurs sujets pour des raisons évidentes.KafkaProducer (0.9): Un seul producteur plusieurs sujets. Problèmes potentiels?

Maintenant, y a-t-il un cas où un sujet pourrait être plus lent pour une raison quelconque, et pas les autres? Et s'il y a un tel cas, comment cela se passerait-il avec un seul producteur produisant plusieurs sujets? Cela affecterait-il le débit des autres sujets?

Existe-t-il d'autres cas où l'utilisation d'un seul producteur pour plusieurs sujets pourrait ne pas être une bonne idée?

Merci!

Mise à jour: Voici ce que nous avons essayé jusqu'à présent:

Nous avons brièvement examiné le code et voici ce que nous comprenons: serveur Kafka accepte un lot de messages pour chaque partition de sujet. Map [TopicAndPartition, MessageSet]

Il essaie de traiter le lot entier dans le délai d'attente configuré et renvoie une réponse contenant des enregistrements réussis et ayant échoué.

Maintenant, regardons ce qui peut mal tourner à un niveau de sujet, et comment cela aurait une incidence sur l'ensemble du lot:

1) Toutes les répliques disponibles pour un sujet: Disons un lot contient des données pour trois sujets : test1, test2, test3. Pour test3, toutes les répliques ne sont pas disponibles. Ce cas sera détecté par le leader instantanément, et il échouera les enregistrements. Dans ce cas, le lot ne sera pas retardé et le débit pour test1 et test2 ne seront pas affectés.

2) Les répliques d'un sujet sont lentes. Disons que les réplicas pour test3 seulement sont lents. Dans ce cas, la réplication des messages pour test3 prendra du temps, ce qui à son tour retardera l'ensemble du lot, affectant ainsi le débit des sujets test1 et test2.

Quoi d'autre peut mal tourner?

Merci!

Répondre

0

Je suppose que vous voulez dire de producteur multiple à un seul producteur dans la même application?

L'utilisation d'un seul producteur ne devrait pas avoir inconvénient

  • Vous disposez d'une connexion unique à chaque courtier (où vous avez n * pour n producteur)
  • Vous les messages par lots plus efficacement

Il peut y avoir quelques inconvénients, qui sont résolus par conf:

  • si vous avez des quotas sur côté courtier qui, lorsqu'il est configuré pour contrôler le débit du courtier, comme vous allez produire plus de données avec un seul producteur, vous pouvez atteindre le quota.
  • Vous devrez peut-être modifier votre conf un peu (cela dépend du client que vous utilisez) car vous produirez plus de données - buffer.memory sur le producteur java par exemple, et si vous voulez lot au mieux, max.request.size et batch.size.Cela dépend de vos données
+0

Merci pour la réponse @Treziac. Seriez-vous capable de commenter ceci: "Y at-il un cas où un sujet pourrait être plus lent pour une raison quelconque, et pas les autres". Cela affectera-t-il le débit pour d'autres sujets? – Ninad

+0

Je ne suis pas sûr de ce que vous voulez dire. (Modifier, après début) Vous voulez dire que, quand vous avez eu 'producer1 -> topic1' ' producer2 -> topic2' ... et passez à 'producteur -> sujet1, sujet2, topic3'? alors tout le rendement aux sujets sont au moins identiques? Si tous les producteurs étaient dans le même processus, il ne devrait pas y avoir de débit plus lent à l'exception des situations que j'ai mentionnées plus tôt (si vous atteignez un quota). – Treziac

+0

En outre, si vous améliorez le traitement par lots pour améliorer le débit, vous pouvez augmenter la latence (débit supérieur mais latence plus élevée). S'il est vital que vous receviez vos données dans 5 ms plutôt que 100 ms, vous devrez sacrifier un peu le batch (mais vous n'avez pas mentionné la latence, donc je suppose que c'est OK) Notez que le producteur est thread-safe pour la production. Utilisez-le au mieux. Dans votre cas, il suffit de remplacer simplement les anciennes instances multiples par une seule – Treziac