confluent-kafka-do tnet - фиксировать асинхронно - PullRequest
1 голос
/ 28 января 2020

Я использую confluent-kafka-do tnet в своем приложении и хочу контролировать фиксацию каждого сообщения, в моем случае дескриптор сообщения выполняет некоторую работу (asyn c) и фиксирует сообщение, я go над примером в проекте confluent-kafka-do tnet в GitHub и обратите внимание на то, что в документации отмечается, что

синхронизация сообщения syn c Это очень медленно по сравнению со скоростью, с которой потребитель способен потребляющие сообщения.

Поэтому я ищу в документации и замечаю, что в прошлом это был метод Asyn c, который фиксирует сообщение, но оно было изменено только на Syn c (можно увидеть Pu sh здесь ).

Итак, вопрос в том, есть ли у меня другая лучшая альтернатива, если я хочу контролировать фиксацию для каждого сообщения?

1 Ответ

0 голосов
/ 31 марта 2020

В коммите, который вы связали с confluent-kafka-dotnet, вы можете заметить следующую строку:

Task.Run(() => kafkaHandle.CommitSync(null));

Это было изменено на:

kafkaHandle.Commit(null);

И реализацию kafkaHandle.CommitSync, которая был использован внутри, фактически не изменился. Другими словами, предыдущий CommitAsync не был быстрее от текущего Commit метода. Он был заключен только в Task.Run(), который потенциально запускал коммит в отдельном потоке.

Запуск CommitAsync в отдельном потоке не делает его быстрее, он только позволяет запустить его параллельно (не блокирует основная ветка приложения). Таким образом, вы можете продолжать принимать сообщения от Кафки в основном потоке и выполнять коммиты в фоновом потоке. Поскольку они удалили CommitAsync, вы можете создать свою собственную асин c обертку для метода Commit и просто обернуть ее в Task.Run() и выполнить синхронизацию потоков в соответствии с потребностями вашего приложения.

Но вам нужно подумать, принесет ли это вам пользу и позволит ли это выполнить требование, которое вы описали как:

хотите контролировать фиксацию каждого сообщения

By "контролируя «Вы имеете в виду, что вам нужно убедиться, что фиксация произошла до того, как перейдет и будет использовать следующее сообщение? Если это так, то параллелизм, вероятно, не является решением для вашего сценария.

...