Привет, Хабр! Представляю вам вторую часть из серии статей, посвященных оптимизации развертывания Kafka кластера (ссылка на первую часть). Это перевод руководства от Confluent. Сегодняшняя статья посвящена тому, как уменьшить задержку и повысить надежность и доступность.

Заключительная третья часть будет посвящена мониторингу и бенчмаркингу.

Оптимизация настроек Kafka кластера для уменьшения задержки

Многие параметры конфигурации Kafka, рассмотренные в разделе о пропускной способности, имеют настройки по умолчанию, оптимизированные для уменьшения задержки. Таким образом, эти параметры конфигурации обычно не требуют настройки, но мы рассмотрим ключевые параметры, чтобы укрепить понимание того, как они работают.

У Confluent есть рекомендации по выбору количества партиций. Поскольку партиция - это единица параллелизма в Kafka, увеличение количества партиций может повысить пропускную способность. Однако есть и компромисс: увеличение количества партиций может привести к увеличению времени ожидания. Брокер по умолчанию использует один поток для репликации данных от другого брокера, поэтому репликация большого количества партиций, разделяемых между каждой парой брокеров, может занять больше времени, и, соответственно, потребуется больше времени для того, чтобы сообщения считались зафиксированными. Ни одно сообщение не может быть потреблено, пока оно не зафиксировано, поэтому в конечном итоге это может привести к увеличению задержек при передаче сообщений из конца в конец.

Чтобы решить проблему потенциальной задержки выборки, можно ограничить количество партиций на каждом конкретном брокере. Для этого можно либо ограничить количество партиций во всем кластере (т. е. не устанавливать количество партиций для топиков произвольно высоким), либо увеличить количество брокеров в кластере, чтобы каждый брокер имел меньше партиций.

Для приложений, работающих в режиме реального времени, которые требуют очень низких задержек, но при этом требуют большого количества партиций, вы можете настроить количество fetcher-потоков, используемых для репликации сообщений от брокера-источника. Чтобы увеличить степень параллелизма ввода-вывода в брокере-последователе, настройте параметр конфигурации num.replica.fetchers, который представляет собой количество fetcher-потоков на брокер-источник. Начните ваши бенчмарк тесты со значения по умолчанию 1, а затем увеличьте его, если последователи не могут угнаться за лидером.

Продюсеры автоматически отправляют сообщения пакетами, то есть собирают сообщения для совместной отправки. Чем меньше времени уходит на ожидание заполнения этих пакетов, тем, как правило, меньше задержка при передаче данных в кластер Kafka. По умолчанию продюсер настроен на низкую задержку, и параметр конфигурации linger.ms установлен в 0, что означает, что продюсер будет отправлять данные, как только они появляются. В этом случае нельзя сказать, что пакетная обработка отключена - сообщения всегда отправляются пакетами, но иногда в пакете может быть только одно сообщение (если только сообщения не передаются продюсеру быстрее, чем он успевает их отправить).

Подумайте, нужно ли включать сжатие. Включение сжатия обычно требует больше циклов CPU для выполнения сжатия, но это снижает нагрузку на пропускную способность сети. Поэтому отключение сжатия обычно экономит циклы процессора, но увеличивает загрузку сети. В зависимости от производительности сжатия, вы можете рассмотреть возможность отключения сжатия с параметром compression.type=none, чтобы сэкономить циклы процессора, хотя хороший кодек сжатия может также уменьшить задержку.

Вы можете настроить количество подтверждений, которые продюсер должен получить от брокера-лидера, прежде чем считать запрос завершенным. Обратите внимание, что это подтверждение для продюсера отличается от того, когда сообщение считается зафиксированным - подробнее об этом в следующем разделе. Чем быстрее брокер-лидер ответит, тем быстрее продюсер сможет продолжить отправку следующей партии сообщений, что в целом сокращает время ожидания продюсера. Установите количество необходимых подтверждений с помощью параметра конфигурации продюсера acks. По умолчанию acks=1, что означает, что брокер-лидер ответит продюсеру раньше, чем все реплики получат сообщение. В зависимости от требований вашего приложения вы можете даже установить acks=0, чтобы продюсер не ждал ответа на запрос от брокера, но тогда сообщения могут быть потеряны, и продюсер об этом даже не узнает.

Аналогично концепции пакетной обработки данных для продюсеров, вы можете настроить консьюмеров на более низкую задержку, регулируя количество данных, получаемых ими при каждой выборке от брокера-лидера. По умолчанию параметр конфигурации консьюмера fetch.min.bytes установлен в 1, что означает, что запросы на выборку будут выполняться, как только будет доступен хотя бы один байт данных или запрос на выборку затянется в ожидании поступления данных, т. е. параметр конфигурации fetch.max.wait.ms. Совместное рассмотрение этих двух параметров конфигурации позволит вам определить подходящий размер запроса на выборку, т.е. fetch.min.bytes, а также время ожидания запроса, т.е. fetch.max.wait.ms.

Если у вас есть приложение для потоковой передачи событий Kafka или вы используете ksqlDB, вы также можете добиться некоторых улучшений производительности в приложении. Для сценариев, в которых необходимо выполнять поиск в таблицах в очень больших масштабах и с низкой задержкой обработки, можно использовать локальную потоковую обработку. Популярным шаблоном является использование Kafka Connect для того, чтобы сделать удаленные базы данных доступными локально для Kafka. Тогда вы можете использовать Kafka Streams API или ksqlDB для выполнения очень быстрых и эффективных локальных объединений таких таблиц и потоков, а не требовать от приложения делать запрос к удаленной базе данных по сети для каждой записи. Вы можете отслеживать последнее состояние каждой таблицы в локальном хранилище состояний, что значительно сокращает время задержки обработки, а также снижает нагрузку на удаленные базы данных при выполнении таких потоковых соединений.

Kafka Streams-приложения основаны на топологии процессоров, это граф узлов потоковых процессоров, которые могут работать с партиционированными данными для параллельной обработки. В зависимости от приложения, может быть консервативная, но ненужная перетасовка данных на основе repartition-топиков, которая не приведет к проблемам с корректностью, но может привести к снижению производительности. Чтобы избежать снижения производительности, вы можете включить оптимизацию топологии для своих стриминг-приложений, установив конфигурационный параметр topology.optimization. Включение оптимизации топологии может уменьшить количество перетасованных потоков, которые хранятся и проходят через repartition-топики.

Сводка конфигураций для оптимизации задержки

Продюсер:

• linger.ms=0 (по умолчанию 0)

• compress.type=none (по умолчанию none, т.е. без сжатия)

• acks=1 (по умолчанию 1)

Консьюмер:

• fetch.min.bytes = 1 (по умолчанию 1)

Streams:

• StreamsConfig.TOPOLOGY_OPTIMIZATION: StreamsConfig.OPTIMIZE (по умолчанию StreamsConfig.NO_OPTIMIZATION)

• Streams-приложения имеют встроенных продюсеров и консьюмеров, поэтому также проверьте рекомендации по конфигурации и для них

Брокер:

• num.replica.fetchers: увеличить, если последователи не успевают за лидером (по умолчанию 1).

Оптимизация настроек Kafka кластера для повышения надёжности

Надежность - это снижение вероятности потери сообщения. Наиболее важной функцией, обеспечивающей надежность, является репликация, которая гарантирует, что сообщения будут скопированы на несколько брокеров. Если брокер вышел из строя, данные доступны по крайней мере еще у одного брокера. Топики с высокими требованиями к надежности должны иметь параметр конфигурации replication.factor, установленный на 3, что гарантирует, что кластер сможет выдержать потерю двух брокеров без потери данных. Кроме того, если в кластере Kafka включена функция автоматического создания топиков (параметр конфигурации auto.create.topics.enable), то вам следует изменить параметр конфигурации default.replication.factor на 3, чтобы автоматически создаваемые топики создавались с репликацией. Или полностью отключите автоматическое создание топиков, установив auto.create.topics.enable=false, чтобы вы всегда контролировали фактор репликации и настройки партиций для каждого топика.

Надежность важна не только для пользовательских топиков, но и для внутренних топиков Kafka. Убедитесь, что для всех внутренних топиков настроен соответствующий фактор репликации. К этим топикам относятся:

• Топик, содержащий смещения консьюмеров: Этот топик, по умолчанию называемый __consumer_offsets, отслеживает смещения сообщений, которые были потреблены. Если вы используете версию Kafka с KIP-115, то при автоматическом создании топика, содержащего смещения консьюмеров, к нему будет применяться параметр offsets.topic.replication.factor.

• Внутренние топики Kafka Streams: Эти топики создаются Kafka Streams приложением и используются для внутренних целей во время выполнения, например, топики журнала изменений (changelog) для хранилищ состояний и repartition-топики. Их конфигурационный параметр replication.factor по умолчанию имеет значение 1, поэтому вам может потребоваться его увеличить.

• Топик журнала состояний транзакций EOS: Если вы используете семантику "точно один раз" (exactly once semantics - EOS), топик журнала состояний транзакций хранит последнее состояние транзакции, например, "Выполняется", "Готовится к коммиту" и "Завершена", а также связанные с ними метаданные. Его конфигурационный параметр transaction.state.log.replication.factor по умолчанию настроен на 3.

Продюсеры могут контролировать уровень надежности доставки сообщений, записываемых в Kafka, с помощью параметра конфигурации acks. Этот параметр обсуждался в контексте оптимизации пропускной способности и задержки, но в основном он используется в контексте надежности. Для обеспечения высокой надежности мы рекомендуем установить значение acks=all (эквивалентно acks=-1), что означает, что лидер будет ждать, пока весь набор синхронизированных реплик подтвердит сообщение и будет считать его зафиксированным. Это дает самые надежные гарантии того, что запись не будет потеряна до тех пор, пока жива хотя бы одна синхронизированная реплика. Компромисс заключается в более высокой задержке, поскольку брокер-лидер ожидает подтверждений от реплик, прежде чем ответить продюсеру.

Продюсеры также могут повысить надежность, пытаясь повторно отправлять сообщения в случае неудачной отправки, чтобы гарантировать, что данные не будут потеряны. Продюсер автоматически пытается повторно отправить сообщения до количества попыток, заданного параметром конфигурации retries (по умолчанию MAX_INT), и до истечения времени, заданного параметром конфигурации delivery.timeout.ms (по умолчанию 120000), последний из которых был введен в KIP-91. Вы можете настроить delivery.timeout.ms в соответствии с желаемой верхней границей общего времени между отправкой сообщения и получением подтверждения от брокера, что должно отражать требования бизнеса к сроку действия сообщения.

При автоматических повторных попытках отправки сообщений продюсером следует учитывать два момента: дублирование и порядок сообщений.

1. Дублирование: Если в кластере происходят кратковременные сбои, вызывающие повторные попытки продюсера, он может отправлять дублирующие сообщения брокеру.

2. Порядок: Несколько попыток отправки могут находиться "в пути" одновременно, и повторная попытка отправки ранее неудавшегося сообщения может произойти после успешной отправки более нового сообщения.

Чтобы решить обе эти проблемы, мы обычно рекомендуем настроить продюсер на идемпотентность, т. е. enable.idempotence=true, для чего брокеры отслеживают сообщения с помощью возрастающих номеров последовательности, аналогично протоколу TCP. Идемпотентные продюсеры могут обрабатывать дублирующиеся сообщения и сохранять порядок сообщений даже при конвейерной обработке запросов - дублирование сообщений отсутствует, поскольку брокер игнорирует дублирующиеся порядковые номера, а порядок сообщений сохраняется, поскольку при сбоях продюсер временно ограничивается одним сообщением "в пути", пока последовательность не будет восстановлена. Если гарантии идемпотентности не могут быть выполнены, продюсер выдаст фатальную ошибку и отклонит все дальнейшие отправки, поэтому при настройке продюсера на идемпотентность разработчику приложения необходимо перехватить фатальную ошибку и обработать ее соответствующим образом.

Однако если вы не настраиваете продюсер на идемпотентность, но бизнес-требования обязывают к этому, вам нужно решить проблему дублирования сообщений и проблему упорядочивания другими способами. Чтобы справиться с возможным дублированием сообщений в случае временных сбоев в кластере, обязательно предусмотрите логику приложения-консьюмера для обработки дублирующихся сообщений. Чтобы сохранить порядок сообщений и одновременно разрешить повторную отправку неудачных сообщений, установите параметр конфигурации max.in.flight.requests.per.connection=1, чтобы гарантировать, что только один запрос может быть отправлен брокеру за один раз. Чтобы сохранить порядок сообщений при конвейерной обработке запросов (request pipelining), установите параметр конфигурации retries=0, если приложение способно выдержать некоторую потерю сообщений.

Вместо того чтобы позволять продюсеру автоматически повторять отправку неудачных сообщений, вы можете предпочесть вручную описать действия для исключений, возвращаемых клиенту продюсера, например, метод onCompletion() в интерфейсе Callback в Java-клиенте. Если вам нужна ручная обработка повторных попыток, отключите автоматические повторные попытки, установив retries=0. Обратите внимание, что идемпотентность продюсера отслеживает порядковые номера сообщений, что имеет смысл только при включенных автоматических повторных попытках. В противном случае, если вы установите retries=0 и приложение вручную попытается повторно отправить неудачное сообщение, то оно просто сгенерирует новый порядковый номер, поэтому обнаружение дублирования не сработает. Отключение автоматических повторных попыток может привести к пробелам в сообщениях из-за отдельных сбоев отправки, но брокер сохранит порядок получаемых записей.

Кластер Kafka обеспечивает надежность, реплицируя данные между несколькими брокерами. Каждая партиция будет иметь список назначенных реплик (т. е. брокеров), которые должны иметь копии данных, и список реплик, которые "догоняют" лидера, называется синхронизированными репликами (in-sync replicas, ISRs). Для каждой партиции брокеры-лидеры будут автоматически реплицировать сообщения другим брокерам, которые находятся в их списке ISR. Когда продюсер устанавливает acks=all (или acks=-1), параметр конфигурации min.insync.replicas задает минимальный порог для количества реплик в списке ISR. Если это минимальное количество не может быть достигнуто, то продюсер выдаст исключение. Совместное использование min.insync.replicas и acks позволяет обеспечить большую надежность. Типичным сценарием будет создание топика с replication.factor=3, параметром брокера min.insync.replicas=2 и параметром продюсера acks=all, что гарантирует, что продюсер вызовет исключение, если большинство реплик не получат запись.

Kafka может расширить гарантии, предоставляемые при отказе брокера, и распространить их на отказы стоек (рэков). Функция информирования о рэках распределяет копии одной и той же партиции по разным рэкам. Это снижает риск потери данных в случае одновременного отказа всех брокеров в стойке. Эта функция также может быть применена к облачным решениям, таким как Amazon EC2, путем назначения брокеров в различные зоны доступности. Вы можете указать, к какой стойке принадлежит брокер, задав конфигурационный параметр broker.rack, и тогда Kafka будет автоматически следить за тем, чтобы реплики охватывали столько стоек, сколько возможно.

При сбоях в работе брокеров кластер Kafka может автоматически обнаруживать сбои и выбирать новых лидеров партиций. Новые лидеры партиций выбираются из действующих реплик. Брокеры в списке ISR имеют самые свежие сообщения, и если один из них становится новым лидером, он может продолжить работу с того места, где остановился предыдущий брокер-лидер, копируя сообщения тем репликам, которым еще нужно догнать его. Конфигурационный параметр unclean.leader.election.enable указывает, могут ли брокеры в списке ISR, которые не догнали лидера (т.е. "нечистые"), сами стать лидерами. Для большей надежности эту функцию следует отключить, установив unclean.leader.election.enable=false, чтобы гарантировать, что новые лидеры будут выбираться только из списка ISR. Это предотвращает потерю сообщений, которые были зафиксированы, но не реплицированы. Компромисс заключается в том, чтобы терпеть большее время простоя, пока другие реплики не придут в синхронизацию.

Поскольку мы рекомендуем использовать репликацию Kafka для обеспечения надежности и позволяем операционной системе контролировать выгрузку данных из кэша на диск, обычно вам не нужно изменять настройки выгрузки. Однако для критически важных топиков с крайне низкой пропускной способностью может потребоваться более длительный период времени, прежде чем ОС выполнит сброс данных на диск. Для таких топиков вы можете настроить log.flush.interval.ms или log.flush.interval.messages на небольшие значения. Например, если вы хотите сохранять на диск синхронно каждое сообщение, вы можете установить log.flush.interval.messages=1.

Также необходимо продумать, что произойдет с сообщениями в случае непредвиденного отказа консьюмера, чтобы не допустить потери сообщений в процессе их обработки. Консьюмеры отслеживают, какие сообщения уже были потреблены, поэтому то, как и когда консьюмеры фиксируют смещения сообщений, имеет решающее значение для надежности. Необходимо избежать ситуации, когда консьюмер фиксирует смещение сообщения, начинает его обрабатывать, а затем неожиданно выходит из строя. Это связано с тем, что последующий консьюмер, начинающий читать из той же партиции, не будет перерабатывать сообщения со смещениями, которые уже были зафиксированы. Вы можете настроить процесс фиксации с помощью параметра конфигурации enable.auto.commit. По умолчанию смещения настроены на автоматическую фиксацию во время вызова poll() консьюмера через периодический интервал. Но если консьюмер является частью цепочки транзакций и вам нужны надежные гарантии доставки сообщений, вы хотите, чтобы смещения фиксировались только после того, как консьюмер полностью завершит обработку сообщений. Поэтому для обеспечения надежности отключите автоматическую фиксацию, установив enable.auto.commit=false, и явно вызовите один из методов фиксации в коде консьюмера (например, commitSync() или commitAsync()).

Для получения еще более надежных гарантий вы можете настроить свои приложения на транзакции EOS, которые позволяют осуществлять атомарную запись в несколько топиков и партиций Kafka. Поскольку некоторые сообщения в журнале могут находиться в разных состояниях транзакции, консьюмеры могут установить конфигурационный параметр isolation.level, чтобы определить типы сообщений, которые они должны получать. Если установить isolation.level=read_committed, консьюмеры будут получать только нетранзакционные или зафиксированные транзакционные сообщения, и не будут получать сообщения от открытых или прерванных транзакций. Чтобы использовать транзакционную семантику в шаблоне "consume-process-produce" и гарантировать, что каждое сообщение обрабатывается ровно один раз, клиентское приложение должно установить enable.auto.commit=false и не фиксировать смещения вручную, а использовать метод sendOffsetsToTransaction() в интерфейсе KafkaProducer. Вы также можете включить функцию "ровно один раз" для своих стриминговых приложений, установив конфигурационный параметр processing.guarantee.

Сводка конфигураций для оптимизации надежности

Продюсер:

• replication.factor=3 (доступно переопределение для топика)

• acks=all (по умолчанию 1)

• enable.idempotence=true (по умолчанию false), для обработки дублирования и упорядочения сообщений

• max.in.flight.requests.per.connection=1 (по умолчанию 5), чтобы предотвратить появление сообщений не по порядку, если не используется идемпотентный продюсер

Консьюмер:

• enable.auto.commit=false (по умолчанию true)

• isolation.level=read_committed (при использовании транзакций EOS)

Streams:

• StreamsConfig.REPLICATION_FACTOR_CONIG: 3 (по умолчанию 1)

• StreamsConfig.PROCESSING_GUARANTEE_CONFIG: StreamsConfig.EXACTLY_ONCE (по умолчанию StreamsConfig.AT_LEAST_ONCE)

• Streams-приложения имеют встроенных продюсеров и консьюмеров, поэтому также проверьте рекомендации по конфигурации и для них

Брокер:

• default.replication.factor=3 (по умолчанию 1)

• auto.create.topics.enable=false (по умолчанию true)

• min.insync.replicas=2 (по умолчанию 1); доступно переопределение для топика

• unclean.leader.election.enable=false (по умолчанию false); доступно переопределение для топика

• broker.rack: стойка брокера (по умолчанию null).

• log.flush.interval.messages, log.flush.interval.ms: для топиков с очень низкой пропускной способностью установите интервал между сообщениями или временной интервал (по умолчанию позволяет ОС управлять сбросом); доступно переопределение для топика

Оптимизация настроек Kafka кластера для повышения доступности

Чтобы обеспечить высокую доступность, необходимо настроить Kafka на максимально быстрое восстановление после сбоев.

Большее количество партиций может увеличить параллелизм, но наличие большего количества партиций также может увеличить время восстановления в случае сбоя брокера. Все запросы продюсера и консьюмера приостанавливаются до завершения выбора лидеров, и эти выборы лидера происходят для каждой партиции. Поэтому учитывайте это время восстановления при выборе количества партиций.

Когда продюсер устанавливает acks=all (или acks=-1), параметр конфигурации min.insync.replicas определяет минимальное количество реплик, которые должны подтвердить запись, чтобы запись считалась успешной. Если это минимальное количество не может быть достигнуто, то продюсер выдаст исключение. В случае уменьшения ISR, чем выше это минимальное значение, тем больше вероятность сбоя при отправке сообщения продюсером, что снижает доступность партиции. С другой стороны, если установить это значение низким (например, min.insync.replicas=1), система будет выдерживать больше отказов реплик. Пока минимальное количество реплик удовлетворено, запросы продюсеров будут выполняться, что повышает доступность партиции.

Сбои в работе брокеров приводят к выборам лидеров партиций. Хотя это происходит автоматически, вы можете контролировать, какие брокеры получают право стать лидерами. Чтобы обеспечить оптимальную надежность, новые лидеры должны избираться только из списка ISR, чтобы исключить вероятность потери сообщений, которые были зафиксированы, но не реплицированы. И наоборот, чтобы обеспечить высокую доступность, можно разрешить избрание новых лидеров, даже если они были исключены из списка ISR. Чтобы это произошло, установите параметр конфигурации unclean.leader.election.enable=true. Благодаря этому выборы лидера происходят быстрее, что повышает общую доступность.

Когда брокер запускается, он сканирует свои файлы журнальных данных, готовясь к синхронизации с другими брокерами. Этот процесс называется журнальным восстановлением. Количество потоков на каталог данных, используемых для журнального восстановления при запуске и выгрузки журнала при завершении работы, определяется параметром конфигурации num.recovery.threads.per.data.dir. Брокеры с тысячами сегментов журнала будут иметь большое количество индексных файлов, что может привести к медленному процессу загрузки журнала при запуске брокера. Если вы используете RAID-массив (высокая производительность с отказоустойчивостью), то увеличение num.recovery.threads.per.data.dir до количества дисков может сократить время загрузки журнала.

Что касается консьюмеров, то они могут разделить нагрузку на обработку данных, объединившись в группу консьюмеров. Если один из консьюмеров неожиданно выходит из строя, Kafka может обнаружить этот сбой и перераспределить партиции между оставшимися консьюмерами в группе. Сбои в работе консьюмера могут быть жесткими (например, SIGKILL) или мягкими (например, таймаут истекшей сессии), и их можно обнаружить либо когда консьюмер не отправляет heartbeats, либо когда он не отправляет вызовы poll(). Активность консьюмера отслеживается с помощью сигналов heartbeat, которые теперь выполняются в фоновом потоке, начиная с KIP-62, а таймаут, используемый для обнаружения неудачных сигналов heartbeat, определяется параметром конфигурации session.timeout.ms. Чем меньше таймаут сеанса, тем быстрее будет обнаружен сбойный консьюмер, что сократит время восстановления в случае сбоя. Установите это значение как можно ниже, чтобы обнаруживать жесткие сбои, но не настолько, чтобы вызывать мягкие сбои. Мягкие сбои чаще всего происходят при двух сценариях: когда пакет сообщений, возвращаемых poll(), обрабатывается слишком долго, или когда пауза в JVM GC длится слишком долго. Если цикл poll() тратит слишком много времени на обработку сообщений, вы можете решить эту проблему, увеличив верхнюю границу времени, в течение которого консьюмер может простаивать перед получением новых записей, с помощью параметра max.poll.interval.ms или уменьшив максимальный размер возвращаемых пакетов с помощью параметра конфигурации max.poll.records.

В заключение, при ребалансировке рабочих нагрузок путем перераспределения задач между инстансами приложений потоковой передачи событий вы можете сократить время восстановления состояния обработки задач прежде, чем инстанс приложения возобновит обработку. В Kafka Streams восстановление состояния обычно выполняется путем воспроизведения соответствующего топика журнала изменений (changelog топик) для восстановления хранилища состояний. Приложение может реплицировать локальные хранилища состояния, чтобы минимизировать время восстановления на основе журнала изменений, установив параметр конфигурации num.standby.replicas. Таким образом, когда потоковая задача инициализируется или повторно инициализируется на инстансе приложения, ее хранилище состояния восстанавливается до самого последнего снапшота:

• Если локального хранилища состояния не существует, т. е. num.standby.replicas=0, журнал изменений воспроизводится с самого раннего смещения.

• Если локальное хранилище существует, т.е. num.standby.replicas больше 0, журнал изменений воспроизводится с прошлого смещения контрольной точки. Этот метод занимает меньше времени, поскольку применяется меньшая часть журнала изменений.

Сводка конфигураций для оптимизации доступности

Консьюмер:

• session.timeout.ms: минимально возможный (по умолчанию 10000)

Streams:

• StreamsConfig.NUM_STANDBY_REPLICAS_CONFIG: 1 или более (по умолчанию 0)

• Streams-приложения имеют встроенных продюсеров и консьюмеров, поэтому также проверьте рекомендации по конфигурации и для них

Брокер:

• unclean.leader.election.enable=true (по умолчанию false); доступно переопределение для топика

• min.insync.replicas=1 (по умолчанию 1); доступно переопределение для топика

• num.recovery.threads.per.data.dir: количество каталогов в log.dirs (по умолчанию 1).