Thank you for reading this post, don't forget to subscribe! 

Уста­нов­ка KAFKA

четы­ре шага:

• Уста­но­вить Java Development Kit (поче­му-то часто уже ока­зы­ва­ет­ся установленным)
• Ска­чать архив с Кафкой
• Рас­па­ко­вать ( tar -xzf kafka_2.11-0.10.1.0.tgz в *nix системах)
• Всё. Каф­ка готов.

посмот­рим что там в рас­па­ко­ван­ном виде:

root@da8d9e484df3:~/kafka_2.11-0.10.1.0$ ls -l
#LICENSE
#NOTICE
#bin
#config
#libs
#site-docs

В ком­плек­те с Каф­кой идёт не так мно­го папок, и нам пона­до­бят­ся все­го две их них: bin , где хра­нят­ся шелл-скрип­ты и  config , где скры­ва­ют­ся фай­лы кон­фи­гу­ра­ции сервисов.

Как запустить Kafka

В  отли­чие от RabbitMQ, Каф­ке нужен вспо­мо­га­тель­ный сер­вис для того, что­бы коор­ди­ни­ро­вать рабо­ту зоо­пар­ка бро­ке­ров в кла­сте­ре, и имя тому сер­ви­су — ZooKeeper. Когда созда­ёт­ся новый топик, или добав­ля­ет­ся новый бро­кер, или уда­ля­ет­ся ста­рый, ZooKeeper — это тот, кто будет со всем этим раз­би­рать­ся. Он решит, куда поло­жить новый топик, чем загру­зить ново­го бро­ке­ра, и даже как сба­лан­си­ро­вать набор реплик, если часть из них ушла вме­сте с пав­шим сер­ви­сом. Он над­смотр­щик и коор­ди­на­тор, и его запус­ка­ют первым.

Как запустить Apache ZooKeeper

Инстал­лер Каф­ки идёт в ком­плек­те с ZooKeeper, так что поис­ки закон­чи­лись, не успев начать­ся. Скрипт для запус­ка лежит в  bin  пап­ке, а кон­фи­гу­ра­ция — в  config , и, соб­ствен­но, боль­ше ниче­го не нужно:

$ 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, где после­до­ва­тель­ность дей­ствий такая же

Запускаем Kafka-сервер

Все­го лишь еще один шелл-файл:

$ 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.

Теперь, когда сер­вер рабо­та­ет, пора бы и отпра­вить ему что-нибудь.

Отправка и получение сообщений

Что­бы отпра­вить и полу­чить хоть что-нибудь, нуж­но еще три шага (малень­ких): создать топик, где будут хра­нить­ся сооб­ще­ния, создать про­дю­се­ра, что­бы было что хра­нить, и кон­сью­ме­ра, что­бы было зачем. И для все­го это­го есть свой шелл-скрипт.

Создаём топик

$ bin/kafka-topics.sh \
--create \
--zookeeper localhost:2181 \
--replication-factor 1 \
--partitions 1 \
--topic mytopic
#Created topic "mytopic".

Созда­ние топи­ка выгля­дит более слож­ным, чем мож­но было бы поду­мать, но на самом деле всё разум­но. Зачем нуж­ны  --create  и  --topic mytopic , по идее, понят­но сра­зу. А про осталь­ных сто­ит пого­во­рить особо.

1. Во-пер­вых, мы отпра­ви­ли коман­ду ZooKeeper, не Каф­ке:  --zookeeper localhost:2181 . Это пона­ча­лу может пока­зать­ся немно­го стран­ным. Но ведь с дру­гой сто­ро­ны, мы же не все­гда зна­ем, сколь­ко в кла­сте­ре бро­ке­ров, и кто из них может взять на себя топик, кото­рый на самом деле не про­сто имя, а вполне себе ося­за­е­мое хра­ни­ли­ще. А ZooKeeper всё зна­ет, так что раз­го­ва­ри­вать с ним име­ет смысл.
2. Во-вто­рых, мы ука­за­ли коэф­фи­ци­ент репли­ка­ции:   --replication-factor 1 . «Один» зна­чит, что будет толь­ко одна копия топи­ка, и если хра­ня­щий его хост уйдёт в нику­да, дан­ные пой­дут сле­дом. С дру­гой сто­ро­ны, если бы у нас было два хоста, и коэф­фи­ци­ент тоже выбра­ли «2», то каж­дый хост полу­чил бы свою копию топи­ка. Мелочь, а жить спокойнее.
3. Нако­нец, коли­че­ство раз­де­лов — partitions  — тоже еди­ни­ца. То есть наш топик будет хра­нить­ся в одном моно­лит­ном хра­ни­ли­ще. Если вдруг топик будет боль­шим — боль­ше, чем поз­во­ля­ет фай­ло­вая систе­ма, и/или хост, кото­рый его дер­жит, может и спра­вить­ся со все­ми вхо­дя­щи­ми запро­са­ми, то его мож­но раз­бить на несколь­ко раз­де­лов, кото­рые, ско­рее все­го, ока­жут­ся на раз­ных хостах. Если еще вклю­чить репли­ка­цию, то полу­чит­ся уди­ви­тель­ной неуби­ва­е­мо­сти кластер.

Отправка сообщений

Оче­ред­ной шелл-файл:

$ bin/kafka-console-producer.sh --broker-list localhost:9092 --topic mytopic
# Uno
# Dos
# Tres

Про­дю­се­ру нуж­но знать, где нахо­дит­ся хотя бы один бро­кер из кла­сте­ра, что­бы отпра­вить сооб­ще­ние. При­чём, не важ­но, «тот» ли это бро­кер — они дого­во­рят­ся и про­дю­се­ру дадут пра­виль­ный адрес.  После запус­ка скрипт дер­жит сес­сию откры­той и отправ­ля­ет всё, что ему вве­дут, в каче­стве сообщений.

Получение сообщений

Конеч­но, еще один скрипт:

$ bin/kafka-console-consumer.sh \
--bootstrap-server localhost:9092 \
--topic mytopic
# Uno
# Dos
# Tres

Как и про­дю­сер, полу­ча­тель дол­жен ука­зать хоть какую-нибудь точ­ку вхо­да в кла­стер через пара­метр — --bootstrap-server . Он тоже дер­жит откры­той сес­сию и выво­дит в тер­ми­нал всё, что уда­лось полу­чить от Кафки.

И всё! Каким-то непо­сти­жи­мым обра­зом, без еди­ной строч­ки кода мы полу­чи­ли рабо­та­ю­щий кла­стер с одним хостом, через кото­рый про­пу­сти­ли пароч­ку сообщений.

Заключение

Запу­стить Kafka-сер­вер и про­пу­стить через него сооб­ще­ние, в общем-то, слож­нее, чем сде­лать то же самое с RabbitMQ и тем более с ZeroMQ (в прин­ци­пе, всё в этом мире слож­нее, чем ZeroMQ). С дру­гой сто­ро­ны, для того, что­бы перей­ти от кла­сте­ра с одним хостом к мно­го­хо­сто­во­му кла­сте­ру с рас­пре­де­лен­ны­ми топи­ка­ми, допол­ни­тель­ных уси­лий не требуется