Как коннектор Kafka Sink обеспечивает упорядочение сообщений при получении сообщений из разделов. У меня несколько разделов, и я обеспечил порядок сообщений при публикации сообщений с хеш-ключами для каждого раздела. Теперь, когда несколько задач Sink (и их рабочих) масштабируются с нескольких JVM с ответственностью за выборку сообщений из одного раздела и уведомление целевой системы через HTTP, как я могу гарантировать, что конечная система получит сообщения по порядку? .
Заказ сообщений Kafka Connect
comment
Задачи приемника подключения Kafka можно рассматривать как потребителей, входящих в одну группу потребителей. Вы не можете одновременно использовать несколько задач из одного раздела. Это касается всего набора рабочих, выполняющих задачи. Обычно гарантии заказа в Kafka достигаются при наличии одной темы раздела.
- person dawsaw schedule 19.11.2016
comment
@dawsaw Я имею в виду рабочих. Рабочие - это процессы, и я предполагаю, что рабочие будут порождены (автоматически масштабированы). Давайте рассмотрим, что у каждого из этих воркеров один и тот же экземпляр коннектора (conn1). Я также хотел бы, чтобы рабочие (conn & tasks) читали из того же раздела, чтобы поддерживать порядок во время Fetch, однако существует риск уведомления Workers (в моем случае, вызывающего конечные точки HTTP) не в порядке выборки, как Workers. быть частью отдельных процессов JVM.
- person bhalochele schedule 19.11.2016
comment
Я рекомендую вам прочитать эту документацию о том, как распределенные работники масштабируют документы. confluent.io/3.1.1/connect/. У вас не будет сценария, в котором нескольким задачам, связанным с одним и тем же коннектором, будет разрешено взаимодействовать с одним и тем же разделом независимо от количества рабочих, которые у вас есть. Если я не понимаю твой сценарий
- person dawsaw schedule 20.11.2016
Ответы (1)
Каждая задача приемника будет получать упорядоченные события, доступные из назначенных им тем, но как только она покидает обработку протокола Kafka и отправляется в удаленное место назначения, будь то файл или конечная точка HTTP, порядок может быть гарантирован только на основе семантика упорядочивания этой системы.
Например, если вы пишете в Elasticsearch, вы можете «упорядочить» события (в Kibana), указав поле отметки времени для индексации. Аналогично для любой (нет) базы данных SQL
С другой стороны, файловая система будет упорядочивать файлы по времени модификации, но не гарантируется, что события в любом заданном файле будут упорядочены (если они не исходят из одного раздела).
Я считаю маловероятным, что конечная точка HTTP REST сможет понять, какие события порядка нужно собирать, и эта логика должна быть определена внутри этой конечной точки сервера. Один из вариантов - отправлять события в конечную точку, которая примет номер раздела и смещение, из которого пришла запись.
person
OneCricketeer
schedule
26.09.2018
