Ну что, самое время отправить каких-нибудь данных через Apache Kafka. Но сначала, разумеется, его нужно установить.
Установка Кафки настолько простая, что в этот раз я отойду от своего обычного правила и в самом деле объясню, как его устанавливать. Итак, четыре шага:
- Установить Java Development Kit (почему-то часто уже оказывается установленным)
- Скачать архив с Кафкой
- Распаковать ( tar -xzf kafka_2.11-0.10.1.0.tgz в *nix системах)
- Всё. Кафка готов.
Честно, это действительно всё. Но прежде, чем мы пойдём дальше, стоит осмотреться:
1 2 3 4 5 6 7 |
root@da8d9e484df3:~/kafka_2.11-0.10.1.0$ ls -1 #LICENSE #NOTICE #bin #config #libs #site-docs |
В комплекте с Кафкой идёт не так много папок, и нам понадобятся всего две их них: bin , где хранятся шелл-скрипты и config , где скрываются файлы конфигурации сервисов.
Как запустить Kafka
Как я упоминал в прошлый раз, даже одинокий кафкианский брокер — это кластер, так что его запуск немного отличается от запуска того же RabbitMQ. В отличие от кролика, Кафке нужен вспомогательный сервис для того, чтобы координировать работу зоопарка брокеров в кластере, и имя тому сервису — ZooKeeper. Когда создаётся новый топик, или добавляется новый брокер, или удаляется старый, ZooKeeper — это тот, кто будет со всем этим разбираться. Он решит, куда положить новый топик, чем загрузить нового брокера, и даже как сбалансировать набор реплик, если часть из них ушла вместе с павшим сервисом. Он надсмотрщик и координатор, и его запускают первым.
Как запустить Apache ZooKeeper
Инсталлер Кафки идёт в комплекте с ZooKeeper, так что поиски закончились, не успев начаться. Скрипт для запуска лежит в bin папке, а конфигурация — в config , и, собственно, больше ничего не нужно:
1 2 3 4 |
$ bin/zookeeper-server-start.sh config/zookeeper.properties #[2016-12-03 22:49:06,368] INFO Reading configuration from: config/zookeeper.properties... #[2016-12-03 22:49:06,380] INFO autopurge.snapRetainCount set to 3... #... |
Кстати, я запускаю всё это в openjdk контейнере в Docker, где последовательность действий такая же, как и на маке или линуксе. Счастливым обладателям Windows нужно заменить bin папку на bin\windows\ , а .sh расширение на .bat , и будет им счастье.
Запускаем Kafka-сервер
Всего лишь еще один шелл-файл:
1 2 3 4 5 6 |
$ bin/kafka-server-start.sh config/server.properties #.... # zookeeper.connect = localhost:2181 #.... #[2016-12-04 04:18:32,414] INFO Connecting to zookeeper on localhost:2181... #.... |
На выходе получается много текста, но в нём видно, что одно из первых действий сервера — подключиться к ZooKeeper на localhost:2181 . Адрес пришёл из сonfig/server.properties.
Теперь, когда сервер работает, пора бы и отправить ему чего.
Отправка и получение сообщений
Чтобы отправить и получить хоть что-нибудь, нужно еще три шага (маленьких): создать топик, где будут храниться сообщения, создать продюсера, чтобы было что хранить, и консьюмера, чтобы было зачем. И для всего этого есть свой шелл-скрипт.
Создаём топик
1 2 3 4 5 6 7 |
$ bin/kafka-topics.sh \ --create \ --zookeeper localhost:2181 \ --replication-factor 1 \ --partitions 1 \ --topic mytopic #Created topic "mytopic". |
Создание топика выглядит более сложным, чем можно было бы подумать, но на самом деле всё разумно. Зачем нужны --create и --topic mytopic , по идее, понятно сразу. А про остальных стоит поговорить особо.
- Во-первых, мы отправили команду ZooKeeper, не Кафке: --zookeeper localhost:2181 . Это поначалу может показаться немного странным. Но ведь с другой стороны, мы же не всегда знаем, сколько в кластере брокеров, и кто из них может взять на себя топик, который на самом деле не просто имя, а вполне себе осязаемое хранилище. А ZooKeeper всё знает, так что разговаривать с ним имеет смысл.
- Во-вторых, мы указали коэффициент репликации: --replication-factor 1 . «Один» значит, что будет только одна копия топика, и если хранящий его хост уйдёт в никуда, данные пойдут следом. С другой стороны, если бы у нас было два хоста, и коэффициент тоже выбрали «2», то каждый хост получил бы свою копию топика. Мелочь, а жить спокойнее.
- Наконец, количество разделов — partitions — тоже единица. То есть наш топик будет храниться в одном монолитном хранилище. Если вдруг топик будет большим — больше, чем позволяет файловая система, и/или хост, который его держит, может и справиться со всеми входящими запросами, то его можно разбить на несколько разделов, которые, скорее всего, окажутся на разных хостах. Если еще включить репликацию, то получится удивительной неубиваемости кластер.
Отправка сообщений
Очередной шелл-файл:
1 2 3 4 |
$ bin/kafka-console-producer.sh --broker-list localhost:9092 --topic mytopic # Uno # Dos # Tres |
Продюсеру нужно знать, где находится хотя бы один брокер из кластера, чтобы отправить сообщение. Причём, не важно, «тот» ли это брокер — они договорятся и продюсеру дадут правильный адрес. После запуска скрипт держит сессию открытой и отправляет всё, что ему введут, в качестве сообщений.
Получение сообщений
Конечно, еще один скрипт:
1 2 3 4 5 6 |
$ bin/kafka-console-consumer.sh \ --bootstrap-server localhost:9092 \ --topic mytopic # Uno # Dos # Tres |
Как и продюсер, получатель должен указать хоть какую-нибудь точку входа в кластер через параметр — --bootstrap-server . Он тоже держит открытой сессию и выводит в терминал всё, что удалось получить от Кафки.
И всё! Каким-то непостижимым образом, без единой строчки кода мы получили работающий кластер с одним хостом, через который пропустили парочку сообщений.
Заключение
Запустить Kafka-сервер и пропустить через него сообщение, в общем-то, сложнее, чем сделать то же самое с RabbitMQ и тем более с ZeroMQ (в принципе, всё в этом мире сложнее, чем ZeroMQ). С другой стороны, для того, чтобы перейти от кластера с одним хостом к многохостовому кластеру с распределенными топиками, дополнительных усилий не требуется. Именно это мы и проверим в следующий раз.
Спасибо. Оказывается, kafka это не столь страшно.
Круто, реально спасибо. Кратко, доступно, по делу без лишних соплей и историй на 20 листов.