В коммите, который вы связали с confluent-kafka-dotnet
, вы можете заметить следующую строку:
Task.Run(() => kafkaHandle.CommitSync(null));
Это было изменено на:
kafkaHandle.Commit(null);
И реализацию kafkaHandle.CommitSync
, которая был использован внутри, фактически не изменился. Другими словами, предыдущий CommitAsync
не был быстрее от текущего Commit
метода. Он был заключен только в Task.Run()
, который потенциально запускал коммит в отдельном потоке.
Запуск CommitAsync
в отдельном потоке не делает его быстрее, он только позволяет запустить его параллельно (не блокирует основная ветка приложения). Таким образом, вы можете продолжать принимать сообщения от Кафки в основном потоке и выполнять коммиты в фоновом потоке. Поскольку они удалили CommitAsync
, вы можете создать свою собственную асин c обертку для метода Commit
и просто обернуть ее в Task.Run()
и выполнить синхронизацию потоков в соответствии с потребностями вашего приложения.
Но вам нужно подумать, принесет ли это вам пользу и позволит ли это выполнить требование, которое вы описали как:
хотите контролировать фиксацию каждого сообщения
By "контролируя «Вы имеете в виду, что вам нужно убедиться, что фиксация произошла до того, как перейдет и будет использовать следующее сообщение? Если это так, то параллелизм, вероятно, не является решением для вашего сценария.