Апацхе Кафка је платформа за пренос података која је одговорна за струјање података са више њих извори на пуно мете. Називају се и извори произвођачи. Произведени подаци потребни су потпуно другој групи тзв потрошачи у разне сврхе. Кафка је слој који се налази између произвођача и потрошача и агрегира податке у употребљив цевовод. Такође је и сама Кафка дистрибуирана платформа, па се слој Кафка састоји од различитих сервера који покрећу кафку, па су ови сервери или чворови познати као Кафка Брокери.

Тај преглед је помало апстрактан, па хајде да га утемељимо у стварном сценарију, замислите да треба да надгледате неколико веб сервера. Свака има своју веб страницу и у свакој од њих се сваке секунде дана непрестано генеришу нови дневници. Поврх тога постоји низ сервера е-поште које такође треба да надгледате.

Можда ће бити потребно да те податке сачувате за потребе вођења евиденције и обрачуна, што је пакетни посао који не захтева тренутну пажњу. Можда ћете желети да покренете аналитику на подацима да бисте доносили одлуке у реалном времену, што захтева тачан и непосредан унос података.  Одједном се нађете у потреби за рационализацијом података на разуман начин за све различите потребе. Кафка делује као онај слој апстракције на који више извора може објавити различите токове података и дато потрошач може да се претплати на токове које сматра релевантним. Кафка ће се побринути да подаци буду добро уређени. То су унутрашњости Кафке које морамо да разумемо пре него што пређемо на тему Партиционирање и кључеви.

Кафка теме, брокер и партиције

Кафка Теме су попут табела базе података. Свака тема састоји се од података из одређеног извора одређеног типа. На пример, здравље вашег кластера може бити тема која се састоји од информација о коришћењу процесора и меморије. Слично томе, долазни саобраћај преко кластера може бити друга тема.

Кафка је дизајниран да буде хоризонтално скалабилан. То ће рећи, појединачна инстанца Кафке састоји се од вишеструке Кафке брокери трчећи се кроз више чворова, сваки може да обрађује токове података паралелно другом. Чак и ако неколико чворова не успије, ваш цјевовод података може наставити да функционише. Тада се одређена тема може поделити на неколико преграде. Ова подела је један од пресудних фактора хоризонталне скалабилности Кафке.

Вишеструко произвођачи, извори података за дату тему, могу истовремено писати на ту тему, јер сваки уписује на другу партицију, у било којој датој тачки. Сада се партицији обично подаци додељују насумично, осим ако јој не дамо кључ.

Преграђивање и наручивање

Да резимирамо, произвођачи пишу податке на задату тему. Та тема је заправо подељена на више партиција. И свака партиција живи независно од осталих, чак и за задату тему. То може довести до велике забуне када је редослед података битан. Можда су вам потребни подаци у хронолошком редоследу, али постојање више партиција за ваш ток података не гарантује савршено наручивање.

Можете користити само једну партицију по теми, али то поништава целу сврху Кафкине дистрибуиране архитектуре. Дакле, потребно нам је неко друго решење.

Кључеви за партиције

Подаци произвођача се насумично шаљу на партиције, као што смо већ поменули. Поруке су стварни делови података. Произвођачи могу осим слања порука да додају кључ који иде уз њега.

Све поруке које долазе са одређеним кључем ићи ће на исту партицију. Тако се, на пример, активност корисника може хронолошки пратити ако су подаци тог корисника означени кључем и тако увек завршавају на једној партицији. Назовимо ову партицију п0, а корисника у0.

Партиција п0 ће увек покупити поруке повезане са у0 јер их тај кључ повезује. Али то не значи да је п0 везан само за то. Такође може заузимати поруке од у1 и у2 ако има капацитет за то. Слично томе, друге партиције могу трошити податке других корисника.

Поента да се подаци датог корисника не шире на различитим партицијама, што осигурава хронолошко поређење за тог корисника. Међутим, укупна тема кориснички подаци, још увек може да искористи дистрибуирану архитектуру Апацхе Кафке.

Закључак

Док дистрибуирани системи попут Кафке решавају неке старије проблеме попут недостатка скалабилности или постојања једне тачке неуспеха. Долазе са низом проблема који су јединствени за њихов властити дизајн. Предвиђање ових проблема је суштински посао сваког системског архитекте. И не само то, понекад заиста морате да направите анализу трошкова и користи да бисте утврдили да ли су нови проблеми достојна замена за решавање старијих. Наручивање и синхронизација само су врх леденог брега.

Надамо се да вам чланци попут овог и званична документација могу помоћи на том путу.