Интерлюдия: практика развертывания, эксплуатации и обслуживания кластера Kafka

Kafka

предисловие

Предыдущая статья о Кафке ---Интерлюдия: народный язык знакомит вас с КафкойМы должны были уже понять некоторые вопросы, связанные с базовыми ролями и архитектурой кластера.В настоящее время мы действительно должны знать, как построить кластер Kafka в производстве или какие-то связанные с ним инструменты эксплуатации и обслуживания, поэтому появилось следующее, с картинками В основном нет,

1. Развертывание производственного кластера Kafka

1.1 Предыстория схемы

Предположим, что кластеру необходимо передавать 1 миллиард данных в день. 24 часа в сутки, с 12 дня до 8 утра, данных почти нет.

Используя правило 28, подсчитано, что 80 % данных (800 миллионов) будут загружены за 16 часов, а 80 % из 800 миллионов данных (640 миллионов) будут получены за 20 % из 16 часов (3 часа). ) приток.

Формула расчета QPS: 640000000 ÷ (3x60x60) = 60000, значит, кластер Kafka должен выдерживать 60 000 concurrency в секунду в пиковый период.

Расчет дискового пространства, 1 млрд данных в сутки, каждые 50кб, то есть 46Т данных. Сохраните 2 копии (в предыдущей статье я также упоминал, что две копии были бы лучше,Поскольку для синхронизации данных ведомому необходимо перейти к ведущему, процесс синхронизации данных требует сетевого и дискового пространства, но это необходимо учитывать в соответствии с реальной ситуацией.), 46 * 2 = 92T, сохранить данные за последние 3 дня. Значит нужно 92*3=276Т

1.2 Аспект QPS

При развертывании основных распределенных систем, таких как Kafka, Hadoop, MySQL и т. д., обычно рекомендуется напрямую использовать физические машины и отказаться от идеи использования некоторых низкопрофильных виртуальных машин. При высоком параллелизме нельзя сказать, что вам нужно поддерживать 60 000 QPS, и ваш кластер просто убьет 60 000 параллельных карт. Если вы присоединитесь к какой-то активности в определенный день, объем данных сильно возрастет, и весь кластер рухнет.

Однако, если вам нужно поддерживать только 6 Вт QPS, одна физическая машина может выдержать от 40 000 до 50 000 параллелизма. Так что на данный момент 2-х физических машин вполне достаточно. Но здесь есть проблема: обычно мы рекомендуем компании иметь достаточный бюджет и стараться удерживать пиковый QPS на уровне около 30% от общего QPS, который может нести кластер (т.Вычислительная мощность кластера в 3-4 раза больше, чем в пиковый период.), поэтому общее количество запросов в секунду, которое может поддерживать созданный нами кластер kafka, составляет от 200 000 до 300 000, что безопасно. Поэтому, как правило, для развертывания требуется 5–7 физических машин, что в принципе очень безопасно.Каждая физическая машина требует пропускной способности от 40 000 до 50 000 данных в секунду, а конфигурация и производительность физических машин не должны быть очень высокими. .

1.3 Дисковые аспекты

1.3.1 Количество дисков

В случае 5 физических машин необходимо хранить 276 ТБ данных, что в среднем составляет около 56 ТБ данных. Это зависит от количества дисков и размера диска.

1.3.2 SAS или SSD

Теперь нам нужно рассмотреть вопрос: вам нужен твердотельный накопитель SSD или обычный механический жесткий диск?

SSD — это твердотельный накопитель, который быстрее механического жесткого диска, так где же он быстрее? фактическиСкорость SSD в основном высока при случайном чтении и записи на диск, когда необходимо читать и записывать в случайных местах на диске, SSD быстрее, чем механический жесткий диск.. Например, MySQL должен использовать SSD (для MySQL требуется произвольное чтение и запись). Например, когда мы планируем и развертываем кластер MySQL онлайн-системы, вообще говоря, мы должны использовать SSD, и производительность может быть значительно улучшена, так что количество одновременных запросов, которые может выполнять MySQL, будет намного выше, а производительность выполнения операторов SQL также будет улучшена.

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

1.4 Перспектива памяти

JVM очень боится полного GC. Собственный jvm Kafka не может использовать слишком много памяти кучи, потому что дизайн KafkaИзбегайте использования объектов jvm для сохранения данных и избегайте частого полного сбора мусора.Проблема вызвана, поэтому обычно собственной памяти кучи jvm kafka достаточно, чтобы выделить около 10G, а остальная часть памяти зарезервирована для кеша os.

Сколько памяти нужно серверу? По нашим оценкам, имеется около 100 тем, поэтому необходимо убедиться, что данные лидирующего раздела из 100 тем находятся в памяти операционной системы. 100 тем, в одной теме 5 разделов. Тогда всего будет 500 разделов. Размер каждого раздела 1G (вПредыдущийВ лог-сегменте в .log-файле указано, что .log-файл не может превышать 1 Г), у нас 2 копии, то есть 1000 Г памяти требуется для хранения данных лидирующего раздела 100 топиков в память.

Теперь у нас 5 серверов, поэтому в среднем серверу требуется 200 ГБ памяти в день, но на самом деле нам не нужно, чтобы все данные раздела находились в памяти, только 25% данных должны быть в памяти. , 200G * 0,25 = 50G просто отлично (потому что вПроизводители и потребители в кластере почти в режиме реального времени, задержки сообщений практически не будет). Таким образом, в общей сложности требуется 60 ГБ памяти (с сервисом Kafka 10 ГБ только сейчас), поэтому мы можем выбрать сервер с памятью 64 ГБ.Большое дело, что в памяти меньше данных о разделах.Конечно, было бы лучше, если он может обеспечить 128G памяти.

1.5 CPU core

Планирование ЦП в основном зависит от того, сколько потоков будет в вашем процессе.Потоки в основном выполняются на многоядерных ЦП.Если у вас много потоков, но мало ядер ЦП, загрузка ЦП будет очень высокой.Приведет к общему рабочему потоку эффективность исполнения не очень высока,ПредыдущийМодель брокера Кафки обсуждается в проекте сети Кафки. Поток-акцептор отвечает за доступ к запросу на соединение клиента, но после того, как он будет подключен, он фактически распределит соединение между несколькими процессорами, по умолчанию 3, но в общих производственных средах рекомендуется добавить еще несколько , что может повысить пропускную способность kafka в целом. Например, можно увеличить до 6 или 9. Другой поток отвечает за обработку запросов.Это пул потоков.По умолчанию 8 потоков.В рабочем кластере рекомендуется увеличить количество потоков в этом блоке в 2-3 раза.На самом деле это нормально 16 рабочих потоков, 24 рабочих потока.

В фоновом режиме будет много других потоков, таких как поток, который регулярно очищает данные 7 дней назад, Контроллер отвечает за обнаружение и управление потоком всего кластера, и поток, который синхронно реплицирует данные, поэтому каждый брокер будет иметь по крайней мере сотни потоков потока. По опыту, есть 4 процессорных ядра, как правило, десятки потоков, и в пиковый период процессор почти полностью загружен. 8 ядер процессора могут относительно щедро поддерживать напряженную работу десятков потоков. Поэтому для серверов Kafka обычно рекомендуется иметь 16 ядер, которые в основном могут поддерживать одну или две сотни рабочих потоков. Конечно, было бы лучше, если бы процессору дали 32 ядра.

1.6 Сетевая карта

Текущая сеть в основном представляет собой сетевую карту Gigabit (1 ГБ / с) и сетевую карту 10 Gigabit (10 ГБ / с). Между кластерами kafka выполняется синхронизация данных между брокерами и брокерами, потому что лидеру необходимо синхронизировать данные с последователями.Они находятся на разных машинах-брокерах.Между машинами-брокерами выполняется частая синхронизация данных, и передается большой объем данных. Сколько данных передается между двумя брокерскими машинами в секунду?

В пиковый период будет приходить около 60 000 единиц данных в секунду, каждый день обрабатывается около 10 000 запросов, каждый запрос составляет 50 КБ, поэтому каждую секунду будет поступать около 488 М данных, у нас также есть данные синхронизации реплик, поэтому 488 М * 2 = пропускная способность сети составляет 976 Мбит/с, поэтому в часы пик сеть по-прежнему сильно загружена при использовании гигабитной пропускной способности.

Подводя итог описанию

10亿数据,6w/s的吞吐量,276T的数据,5台物理机
硬盘:11(SAS) * 7T,7200转
内存:64GB/128GB,JVM分配10G,剩余的给os cache
CPU:16核/32核
网络:千兆网卡,万兆更好

2. Построение кластера Kafka

Войдя в папку конфигурации Kafka, вы обнаружите, что там много-много файлов конфигурации, но вам не нужно их изменять, вам просто нужно открыть файл с именем server.properties.

【broker.id】
每个broker都必须自己设置的一个唯一id,可以在0~255之间

【log.dirs】
这个极为重要,kafka的所有数据就是写入这个目录下的磁盘文件中的,如果说机器上有多块物理硬盘,那么可以把多个目录挂载到不同的物理硬盘上,然后这里可以设置多个目录,这样kafka可以数据分散到多块物理硬盘,多个硬盘的磁头可以并行写,这样可以提升吞吐量。ps:多个目录用英文逗号分隔

【zookeeper.connect】
连接kafka底层的zookeeper集群的

【Listeners】
broker监听客户端发起请求的端口号,默认是9092

【num.network.threads】默认值为3
【num.io.threads】默认值为8
细心的朋友们应该已经发现了,这就是上一篇我们在网络架构上提到的processor和处理线程池的线程数目。
所以说掌握Kafka网络架构显得尤为重要。
现在你看到这两个参数,就知道这就是Kafka集群性能的关键参数了

【unclean.leader.election.enable】
默认是false,意思就是只能选举ISR列表里的follower成为新的leader,1.0版本后才设为false,之前都是true,允许非ISR列表的follower选举为新的leader

【delete.topic.enable】
默认true,允许删除topic

【log.retention.hours】
可以设置一下,要保留数据多少个小时,这个就是底层的磁盘文件,默认保留7天的数据,根据自己的需求来就行了

【min.insync.replicas】
acks=-1(一条数据必须写入ISR里所有副本才算成功),你写一条数据只要写入leader就算成功了,不需要等待同步到follower才算写成功。但是此时如果一个follower宕机了,你写一条数据到leader之后,leader也宕机,会导致数据的丢失。

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

3. Простая кластерная работа Kafka

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

В предыдущей статье также упоминалось, что Kafka находится в версии 0.8.доЕсть большая проблема, 1.x — наиболее используемая версия в текущей производственной среде.

Вы можете увидеть связанные команды в quickStart, такие как

① Создать тему

bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test
将该命令修改一下

zookeeper localhost:2181 --replication-factor 2 --partitions 2 --topic tellYourDream
这时候就是zookeeper的地址为localhost:2181
两个分区,两个副本,一共4个副本,topic名称为“tellYourDream”了

Следует также отметить, что в целом рекомендуется устанавливать количество разделов кратным количеству узлов, что является мерой для балансировки распределения сервисных узлов.

② Посмотреть тему:

bin/kafka-topics.sh --list --zookeeper localhost:2181

③ Информация о производстве

 bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
This is a message
This is another message

④ Информация для потребителей

 bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning
This is a message
This is another message

Здесь нужно упомянуть одну деталь, то есть наша версия 0.8 kafka ищет zookeeper, и действительно есть метаданные о zookeeper.

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

⑤ Кластерный тест

Следующая команда предназначена для создания фрагментов данных объемом 50 Вт, каждый из которых имеет размер 200 байт. После выполнения этой команды будет создан отчет. Вы можете интуитивно увидеть производительность кластера. Если вы не понимаете этого, поисковая система также может помочь вам очень хорошо решить проблему

测试生产数据
bin/kafka-producer-perf-test.sh --topic test-topic --num-records 500000 --record-size 200 --throughput -1 --producer-props bootstrap.servers=hadoop03:9092,hadoop04:9092,hadoop05:9092 acks=-1

Каждый раз, когда вы потребляете 2000 штук, это безопасно, если кластер не работает и не зависает.

测试消费数据
bin/kafka-consumer-perf-test.sh --broker-list hadoop03:9092,hadoop04:9092,hadoop53:9092 --fetch-size 2000 --messages 500000 --topic test-topic 

4. КафкаМенеджер

KafkaManager использует проект, написанный на scala. Шаги установки могут относиться кИнструмент управления кластером Kafka развертывание и установка kafka-manager,очень хороший. Как им пользоваться можно узнать через поисковик.

После установки можно с помощью команды jps проверить, будет ли дополнительная служба с именем ProdServerStart

Функции

1. 管理多个kafka集群
2. 便捷的检查kafka集群状态(topics,brokers,备份分布情况,分区分布情况)
3. 选择你要运行的副本
4. 基于当前分区状况进行
5. 可以选择topic配置并创建topic(0.8.1.1和0.8.2的配置不同)
6. 删除topic(只支持0.8.2以上的版本并且要在broker配置中设置delete.topic.enable=true)
7. Topic list会指明哪些topic被删除(在0.8.2以上版本适用)
8. 为已存在的topic增加分区
9. 为已存在的topic更新配置
10. 在多个topic上批量重分区
11. 在多个topic上批量重分区(可选partition broker位置)

img

5. КафкаОфсетмонитор

KafkaOffsetMonitor — это просто пакет jar, инструмент для потребителей. Его можно использовать для мониторинга проблемы задержки потребления, но он не может решить проблему повторного потребления и потери сообщений, потому что этот инструмент будет использоваться, если вам нужно объяснить SparkStreaming, flink и другие потребительские практики, поэтому я не буду его расширять. теперь, чтобы узнать

Команда запуска:

java -cp KafkaOffsetMonitor-assembly-0.3.0-SNAPSHOT.jar \
 com.quantifind.kafka.offsetapp.OffsetGetterWeb \
 --offsetStorage kafka \
 --zk xx:2181,xx:2181,xx:2181/kafka_cluster \
 --port 8088 \
 --refresh 60.seconds \
 --retain 2.days

Есть также некоторые, такие как MirrorMaker, которые синхронизируют данные в компьютерном зале, используйте их по мере необходимости.

finally

Слов много, но надеюсь, вы терпеливо прочтете

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