Эта статья возникла из вопроса интервью, на который я ходил ранее. Вопрос примерно такой: Потребители обращаются к Kafka, чтобы получить сообщения, но в Kafka нет нового сообщения, которое можно было бы предоставить, так как же Kafka справится с этим?
Как показано на рисунке ниже, обе реплики-последователи переместились на последнюю позицию ведущей реплики, а затем ведущей реплике был отправлен запрос на извлечение, но в ведущей реплике не записываются новые сообщения, поэтому что должна делать ведущая реплика? делать в это время?шерстяное сукно? Вы можете напрямую вернуть пустой пул-результат ведомой копии, но если ведущая копия не имеет новых сообщений, ведомая копия всегда будет отправлять пул-реквесты и всегда получать пустые пул-результаты, что потребляет ресурсы, что, очевидно, нецелесообразно.
Это связано с концепцией отсроченной операции Кафки. Когда Kafka обрабатывает запрос на включение, он сначала один раз читает лог-файл, и если он не соберет достаточное количество сообщений (fetchMinBytes, настраивается параметром fetch.min.bytes, значение по умолчанию равно 1), будет создан отложенный запрос на включение. Операция выборки (DelayedFetch) ожидает получения достаточного количества сообщений. Когда выполняется отложенная операция извлечения, файл журнала считывается снова, и результат извлечения возвращается на следующую реплику.
Операция задержки — это не только уникальная операция при извлечении сообщений, в Kafka существуют различные операции задержки, такие как отложенное удаление данных, отложенное производство и т. д.
Для отложенного производства (сообщений), если для параметра acks установлено значение -1 при использовании клиента производителя для отправки сообщения, это означает, что необходимо дождаться, пока все реплики в наборе ISR подтвердят получение сообщения, прежде чем оно может быть отправлено. получено правильно. Получите результат ответа или перехватите исключение тайм-аута.
Поскольку клиент устанавливает для acks значение -1, ему нужно дождаться, пока обе реплики Follower1 и Follower2 получат сообщение 3 и сообщение 4, чтобы сообщить клиенту, что отправленное сообщение было правильно получено. Если копии Follower1 или Follower2 не удается полностью получить сообщение 3 и сообщение 4 в течение определенного периода времени, клиенту необходимо вернуть исключение тайм-аута. Период ожидания для производственных запросов настраивается параметром request.timeout.ms, а значение по умолчанию — 30000, что составляет 30 секунд.
Итак, кто должен выполнять действия по ожиданию записи сообщения 3 и сообщения 4 в копии Follower1 и Follower2 и возвращать соответствующий результат ответа клиенту? После записи сообщения в локальный файл журнала ведущей реплики Kafka создаст отложенную производственную операцию (DelayedProduce) для обработки ситуации, когда сообщение обычно записывается во все реплики или время ожидания истекло, и возвращает соответствующий ответ клиенту.
Отложенная операция должна задерживать возврат результата ответа. Во-первых, она должна иметь период ожидания (delayMs). Если предопределенная задача не завершена в течение этого периода ожидания, ее необходимо принудительно завершить, чтобы вернуть результат ответа в клиент. Во-вторых, операция задержки отличается от операции синхронизации.Операция синхронизации относится к операции, выполняемой через определенное время, и операция задержки может быть завершена до установленного времени ожидания, поэтому операция задержки может поддерживать запуск внешних событий.
В случае отложенных производственных операций его внешним событием является увеличение HW (высокой отметки) раздела, в который должно быть записано сообщение. То есть, поскольку ведомая копия постоянно синхронизируется с ведущей копией, что еще больше способствует дальнейшему росту HW, каждый раз, когда HW увеличивается, она проверяет, может ли отложенная производственная операция быть завершена, и если да, она возвращает результат ответа на стороне клиента; применяется, если он никогда не завершается в течение периода ожидания.
Напомним, что отложенная операция pull в начале статьи тоже такая же, и она тоже выполняется по таймауту или внешнему событию. Триггер тайм-аута хорошо понятен, он должен запускать вторую операцию чтения файла журнала после периода тайм-аута. Запуск внешних событий немного сложнее, потому что запросы на вытягивание инициируются не только репликами-последователями, но и клиентами-потребителями, и внешние события, соответствующие этим двум случаям, также различаются. Если это отложенное получение копии-последователя, его внешнее событие состоит в том, что сообщение добавляется к локальному файлу журнала ведущей копии; если это отложенное получение клиента-потребителя, его внешнее событие может быть просто понято как рост ХВ.
За отсроченной операцией скрывается более глубокое содержание, такое как понимание "чистилища" и "комбайна", хе-хе~~ Все это содержание находится в "Глубокое понимание Кафки"середина
Приглашаем поддержать автора буклета: "Практическое руководство по иллюстрированию Кафки"и"Проиллюстрировать основные принципы Кафки》
Добро пожаловать в поддержку новых работ автора: «Углубленное понимание Kafka: основные принципы проектирования и практики» и «Практическое руководство по RabbitMQ», а также приглашаем обратить внимание на общедоступный аккаунт автора в WeChat: блог Zhu Xiaosi.