Въведение в групата на потребителите на Kafka
Потребителската група на Kafka е основно брой потребители на Kafka, които могат да четат данни паралелно от тема на Kafka. Потребителска група на Kafka има следните свойства:
- Всички потребители в дадена група имат една и съща group.id.
- Всеки дял в темата се чете само от един Потребител.
- Максималният брой потребители е равен на броя дялове в темата. Ако има повече потребители, отколкото дялове, тогава някои от потребителите ще останат бездействащи.
- Потребителят може да чете от повече от един дял.
Значение на Kafka Consumer Group
За организация на дребно ще има голям брой производители, които генерират данни с огромна скорост. Сега, за да четем голям обем от данни, се нуждаем от множество потребители, които работят паралелно. Сравнително по-лесно е от страна на производителя, където всеки производител генерира данни независимо от останалите. Но от страна на потребителите, ако имаме повече от един потребител, който чете от една и съща тема, има голям шанс всяко съобщение да бъде прочетено повече от веднъж. Kafka решава този проблем, като използва Consumer Group. Във всеки случай само един потребител може да чете данни от дял.
Прегради на Kafka Consumer Group
Да предположим, че имаме тема на Kafka и в нея има 4 дяла. Тогава можем да имаме следните сценарии:
1. Брой потребители = Брой дялове
В този случай всеки Потребител ще прочете данни от всеки дял и това е идеалният случай.
2. Брой потребители> Брой прегради
В този случай един потребител ще остане бездействащ и води до лошо използване на ресурса.
3. Брой потребители <Брой дялове
В този случай един от потребителите ще прочете данни от повече от един дял.
4. Брой на групата потребители> 1
В този случай темата е абонирана от повече от една потребителска група, която обслужва две различни приложения. Двете приложения могат да работят независимо едно от друго.
Предимства на Kafka Consumer Group
Потребителска група добавя следните предимства:
- Мащабируемост: Редица потребители паралелно четат данни определено увеличават скоростта на потребление на данни и правят системата способна да чете голям обем данни.
- Толерантност на грешките: Да предположим, че имахме само един Потребител (за четене на не толкова голям обем данни), какво би се случило, ако потребителят не успее по някаква причина? Целият тръбопровод ще се счупи.
- Балансиране на натоварването: Kafka споделя дяловете справедливо на всеки Потребител, като по този начин прави процеса на потребление на данни плавен и ефективен.
- Ребалансиране: Ако се добави нов Потребител или се прекрати съществуващ, Кафка балансира натоварването на наличните Потребители.
Как Кафка свързва двата модела?
Нека първо да обсъдим двата модела за съобщения.
1. Опашки за съобщения
В този модел поток от съобщения се изпраща от един производител до само един потребител. По този начин всяко съобщение се чете само веднъж и веднъж потребителят изтегли съобщение, то се изтрива от опашката. Типичен пример може да бъде издаване на ведомост, при която всяка ведомост трябва да бъде издадена само веднъж. Освен това този модел не гарантира, че съобщенията ще бъдат доставяни в ред. Мащабируемостта на обработката на съобщенията е ограничена до един домейн.
2. Публикуване-Абониране на съобщения
В този модел съобщенията, публикувани от Производител, могат да бъдат абонирани от повече от един Потребител. Производителят и Потребителят са отделени до голяма степен. Този модел гарантира, че всеки Потребител ще получава съобщения в тема в точния ред, генериран от производителя. Типичен пример може да бъде телевизор с чинии, който публикува различни канали като музика, филм, спорт и т.н., а потребителите могат да се абонират за повече от един канал. Тъй като има няколко абонати на дадена тема, мащабирането на обработката на потоци е предизвикателство.
Kafka е толкова популярна, защото макар да се основава на модела публикуване-абониране, тя има предимствата на системата от опашки за съобщения. Както бе обсъдено по-рано, ако имаме група потребители, Kafka гарантира, че всяко съобщение в дадена тема се чете само веднъж от потребител (което е подобно на система за опашка за съобщения). Допълнителните предимства са, че съобщенията се запазват от брокерите (за известно време, като по този начин го правят толерантни по вина) и ако имаме повече от една група потребители, те могат да четат съобщения от същата тема, но да ги обработват по различен начин.
Използвайте случай на приложение
Да приемем, че имаме обикновена облачна платформа, където допускаме следните операции на потребителите:
- Съхранявайте файлове в Cloud.
- Преглеждайте техните файлове в Облака.
- Изтеглете техните файлове от Облака.
В началото имахме много малка база от потребители. Искахме да извлечем различни статистически данни (на час) като активни потребители, брой заявки за качване, брой заявки за изтегляне и така нататък. За да отговорим на изискванията, ние настроихме клъстер Kafka, който създава регистрационните файлове (генерирани от нашето приложение) в тема и има приложение, което консумира темата (използвайки Потребител) и след това я обработва, за да генерира необходимите статистически данни и накрая да се покаже тези в уеб страница.
Тъй като хората започнаха да харесват нашите услуги, повече хора започнаха да я използват, като по този начин генерираха много трупи на час. Открихме, че приложението, което консумира темата, стана изключително бавно, тъй като използвахме само един потребител. За да разрешим проблема, добавихме някои потребители към групата и открихме значително подобрение в производителността.
Ние се натъкнахме на още едно изискване, при което трябваше да запишем регистрационните файлове в HDFS клъстер и този процес трябва да протича независимо от предишното приложение (Това е така, защото с по-нататъшно увеличаване на данните планирахме да извадим първото приложение и да извлечем всички статистически данни в HDFS среда). За да отговорим на това изискване, ние разработихме друго приложение, което се абонира за темата с помощта на различна потребителска група и записа данните в HDFS клъстера.
Препоръчителни статии
Това е ръководство за Kafka Consumer Group. Тук обсъждаме значението на потребителската група на Kafka и как Kafka преодолява два модела, заедно с тяхното приложение. Можете също да разгледате следните статии, за да научите повече-
- Кафка приложения
- Как да инсталирате Kafka?
- Въпроси за интервю с Kafka
- HDFS Архитектура
- Различни видове инструменти Kafka