Ну т.е. сама обработка, как я упомянул - синхронно идет (в параллель само считывание и обработка, но не обработка отдельно взятых сообщений)? Нет гонки между обработкой сообщений одной партиции? (в ином случае, ронять приложение по некому таймауту не избавит от "неудачи по середине" и при следующем поднятии либо утеряется сообщение, либо повторно считаются уже обработанные)
Но spring-kafka нам обеспечивает схожее поведение при использовании ConcurrentKafkaListenerContainerFactory, с встроенной очередью сообщений на обработку и кэлбеком об успехе/неудаче.
Ручной коммит вполне себе хорошо контролируемый и явный процесс.
Ну и в целом повторное чтение можно не боятся при обеспечении идемпотентности, но все же оптимальный ли это путь - остается вопросом профиля использования.
Ну зависит все же от количества партиций, если запись слишком быстрая - их можно и разнести.
А как нет проблем с атомарностью? Если вы вынесете в асинхронную обработку, то у вас сообщения пришедшие позже могут быть обработаны раньше и успешно, а те что пришли раньше - упасть. Как контролируете коммиты в таких случаях?
Вот пришло 3 сообщения с следующими оффсетами: 35: успешно 36: ошибка 37: успешно (раньше 36)
Просто масштабировать "минимальную единицу масштабирования" - выглядит не очень корректно.
Мне просто действительно интересен ваш опыт :)
Корректный способ, разве что, отдельная очередь самой обработки (но синхронно обрабатываемая). Т.е параллелится сама вычитка и обработка, но это в целом подразумевает ручной коммит оффсета.
Далеко не всегда можно инициализировать чекбокс по умолчанию.
Можно привести кучу примеров, полностью зависимых от конечного пользователя (скажем пол/раса/ориентация/вероисповедание по умолчанию могут вовсе задеть чувства и стать причиной исков).
Все же, null/optional, выглядят вполне оправданно в определенных моментах.
Это, как мне кажется, также может быть куда прозрачнее, чем связь с дополнительным полем.
Вероятно, там должна быть запятая:
Ну т.е. сама обработка, как я упомянул - синхронно идет (в параллель само считывание и обработка, но не обработка отдельно взятых сообщений)?
Нет гонки между обработкой сообщений одной партиции?
(в ином случае, ронять приложение по некому таймауту не избавит от "неудачи по середине" и при следующем поднятии либо утеряется сообщение, либо повторно считаются уже обработанные)
Но spring-kafka нам обеспечивает схожее поведение при использовании
ConcurrentKafkaListenerContainerFactory, с встроенной очередью сообщений на обработку и кэлбеком об успехе/неудаче.Ручной коммит вполне себе хорошо контролируемый и явный процесс.
Ну и в целом повторное чтение можно не боятся при обеспечении идемпотентности, но все же оптимальный ли это путь - остается вопросом профиля использования.
Ну зависит все же от количества партиций, если запись слишком быстрая - их можно и разнести.
А как нет проблем с атомарностью? Если вы вынесете в асинхронную обработку, то у вас сообщения пришедшие позже могут быть обработаны раньше и успешно, а те что пришли раньше - упасть. Как контролируете коммиты в таких случаях?
Вот пришло 3 сообщения с следующими оффсетами:
35: успешно
36: ошибка
37: успешно (раньше 36)
Просто масштабировать "минимальную единицу масштабирования" - выглядит не очень корректно.
Мне просто действительно интересен ваш опыт :)
Корректный способ, разве что, отдельная очередь самой обработки (но синхронно обрабатываемая). Т.е параллелится сама вычитка и обработка, но это в целом подразумевает ручной коммит оффсета.
Управлять контейнерами действительно будет проще.
Но на деле, одной машиной читать несколько партиций не сильно сложнее.
Конечно, bottleneck может быть в другом месте, потому и решения нужно выбирать соответствующие профилю использования :)
Ну это можно организовать и в одном приложении, при желании (1 поток на 1 партицию)
Но ведь единицей масштабирования в kafka принято считать партицию.
При необходимости масштабирования - всегда можно выделить больше партиций с соответствующим числом обработчиков (где свои смещения)
А расспараллеливать обработку из одной очереди/партиции выглядит некорректным (by design), т.к обеспечить атомарное выполнение операции проблематично.
После просшествия триала в 30 дней - создаёте инстанс который будет работать дальше.
В моем случае этого, к слову, не потребовалось - работает все по прошествии месяца. Просто дополнительные лимиты триала исчезли.
Все пометки "Always Free" остались и лимиты описанные в статье. В целом это все документировано
Я не спорю в том, что это было бы лучше/хуже.
Но бизнес диктует правила не редко и иногда подобные вещи обязательны. Я лишь привел горстку примеров.
Т.е. запретить "отсутствие значения" в чекбоксах совсем — выглядит слабо аргументированно.
Далеко не всегда можно инициализировать чекбокс по умолчанию.
Можно привести кучу примеров, полностью зависимых от конечного пользователя (скажем пол/раса/ориентация/вероисповедание по умолчанию могут вовсе задеть чувства и стать причиной исков).
Все же, null/optional, выглядят вполне оправданно в определенных моментах.
Это, как мне кажется, также может быть куда прозрачнее, чем связь с дополнительным полем.
А за статью спасибо :)