Толеранцијата на грешки и високата достапност се големи теми, па затоа ќе посветиме посебни написи на RabbitMQ и Kafka. Оваа статија е за RabbitMQ, а следната е за Кафка, во споредба со RabbitMQ. Ова е долга статија, затоа бидете пријатни.

Да ги погледнеме стратегиите за толеранција на грешки, конзистентност и висока достапност (HA) и компромисите што ги прави секоја стратегија. RabbitMQ може да работи на кластер од јазли - и потоа се класифицира како дистрибуиран систем. Кога станува збор за дистрибуирани системи, често зборуваме за доследност и достапност.

Овие концепти опишуваат како системот се однесува кога ќе пропадне. Неуспех на мрежната врска, неуспех на серверот, дефект на хард дискот, привремена недостапност на серверот поради собирање ѓубре, загуба на пакети или забавување на мрежната врска. Сето ова може да доведе до губење на податоци или конфликти. Излегува дека е практично невозможно да се постави систем кој е и целосно конзистентен (без загуба на податоци, без дивергенција на податоци) и достапен (ќе прифаќа читање и пишување) за сите сценарија на неуспех.

Ќе видиме дека конзистентноста и достапноста се на спротивните краеви на спектарот, а вие треба да изберете на кој начин да се оптимизирате. Добрата вест е дека со RabbitMQ овој избор е можен. Имате такви „лудни“ лостови за да ја преместите рамнотежата кон поголема конзистентност или поголема пристапност.

Ќе обрнеме посебно внимание на тоа кои конфигурации доведуваат до губење податоци поради потврдени записи. Постои синџир на одговорност помеѓу издавачите, брокерите и потрошувачите. Откако пораката ќе се пренесе до брокерот, негова работа е да не ја изгуби пораката. Кога брокерот ќе го потврди приемот на пораката од издавачот, не очекуваме таа да биде изгубена. Но, ќе видиме дека тоа всушност може да се случи во зависност од конфигурацијата на вашиот брокер и издавач.

Примитивци за еластичност на еден јазол

Еластични редици/рутирање

Постојат два вида редици во RabbitMQ: издржливи и неиздржливи. Сите редици се зачувани во базата на податоци Mnesia. Издржливите редици повторно се рекламираат при стартување на јазолот и на тој начин преживуваат рестартирање, паѓање на системот или паѓање на серверот (се додека податоците се опстојуваат). Ова значи дека сè додека декларирате рутирање (размена) и редицата за еластични, инфраструктурата за редици/рутирање ќе се врати онлајн.

Испарливите редици и насочувањето се отстрануваат кога јазолот се рестартира.

Постојани пораки

Само затоа што редот е издржлив не значи дека сите негови пораки ќе преживеат по рестартирање на јазолот. Само пораки поставени од издавачот како еластични (упорни). Постојаните пораки навистина создаваат дополнително оптоварување на брокерот, но ако загубата на пораката е неприфатлива, тогаш нема друга опција.

Ориз. 1. Матрица на одржливост

Кластерирање со пресликување на редици

За да ја преживееме загубата на брокер, ни треба технолошки вишок. Можеме да комбинираме повеќе RabbitMQ јазли во кластер, а потоа да додадеме дополнителен вишок со реплицирање на редици помеѓу повеќе јазли. На овој начин, ако еден јазол не успее, не губиме податоци и остануваме достапни.

Пресликување на редица:

• една главна редица (master), која ги прима сите наредби за пишување и читање
• едно или повеќе огледала што ги примаат сите пораки и метаподатоци од главната редица. Овие огледала не се таму за скалирање, туку чисто за вишок.

Ориз. 2. Пресликување на редица

Пресликувањето е поставено со соодветна политика. Во него можете да го изберете коефициентот на репликација, па дури и јазлите на кои треба да се наоѓа редицата. Примери:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (еден господар и едно огледало)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Потврда од издавачот

За да се постигне доследно снимање, потребни се Потврди од издавачот. Без нив, постои ризик од губење на пораките. Потврда се испраќа до издавачот откако пораката е напишана на дискот. RabbitMQ пишува пораки на дискот не по приемот, туку на периодична основа, во регионот од неколку стотици милисекунди. Кога се пресликува редица, потврдата се испраќа само откако сите ретровизори ќе ја напишат својата копија од пораката на дискот. Ова значи дека користењето потврди додава латентност, но ако безбедноста на податоците е важна, тогаш тие се неопходни.

Ред за неуспех

Кога брокерот ќе се откаже или ќе падне, сите лидери на редици (господари) на тој јазол паѓаат заедно со него. Кластерот потоа го избира најстарото огледало на секој господар и го промовира како нов господар.

Ориз. 3. Повеќекратни пресликани редици и нивните политики

Брокерот 3 оди надолу. Имајте предвид дека огледалото на редица C на Broker 2 се промовира во господар. Исто така, имајте предвид дека е создадено ново огледало за редот C на Broker 1. RabbitMQ секогаш се обидува да го задржи факторот на репликација наведен во вашите политики.

Ориз. 4. Брокерот 3 не успее, предизвикувајќи редицата C да пропадне

Следниот Брокер 1 паѓа! Ни остана само еден брокер. Огледалото на редица Б е промовирано во господар.

Сл. 5

Го вративме Брокер 1. Без оглед на тоа колку добро податоците ја преживуваат загубата и обновувањето на брокерот, сите пресликани пораки во редот се отфрлаат при рестартирање. Ова е важно да се забележи бидејќи ќе има последици. Ќе ги разгледаме овие импликации наскоро. Така, Брокер 1 сега повторно е член на кластерот, а кластерот се обидува да се усогласи со правилата и затоа создава огледала на Брокер 1.

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

Ориз. 6. Брокерот 1 се враќа на услуга

Брокер 3 е повторно онлајн, па редиците А и Б ги враќаат огледалата создадени на него за да ги задоволат нивните правила за HA. Но, сега сите главни редици се на еден јазол! Ова не е идеално, подобра е рамномерна дистрибуција помеѓу јазлите. За жал, тука нема многу опции за ребалансирање на мајсторите. Ќе се вратиме на ова прашање подоцна бидејќи прво треба да ја разгледаме синхронизацијата на редот.

Ориз. 7. Брокерот 3 се враќа на услуга. Сите главни редици на еден јазол!

Така, сега треба да имате идеја за тоа како огледалата обезбедуваат вишок и толеранција на грешки. Ова обезбедува достапност во случај на дефект на еден јазол и штити од губење на податоци. Но, сè уште не сме готови, бидејќи во реалноста е многу покомплицирано.

Синхронизација

Кога креирате ново огледало, сите нови пораки секогаш ќе се реплицираат на ова огледало и на сите други. Што се однесува до постоечките податоци во главниот ред, можеме да ги реплицираме во ново огледало, кое станува целосна копија на главниот. Исто така, можеме да избереме да не ги реплицираме постоечките пораки и да дозволиме главната редица и новото огледало да се спојуваат навреме, при што новите пораки пристигнуваат до опашката, а постоечките пораки ја напуштаат главата на главната редица.

Оваа синхронизација се врши автоматски или рачно и се управува со помош на политика за редици. Ајде да погледнеме на пример.

Имаме две огледални редици. Редот А се синхронизира автоматски, а Редот Б се синхронизира рачно. Двете редици содржат по десет пораки.

Ориз. 8. Две редици со различни начини на синхронизација

Сега го губиме Брокер 3.

Ориз. 9. Брокерот 3 падна

Брокерот 3 се враќа на услуга. Кластерот создава огледало за секоја редица на новиот јазол и автоматски ја синхронизира новата редица А со главниот. Сепак, огледалото на новиот Queue B останува празно. На овој начин имаме целосен вишок на редот А и само едно огледало за постоечките пораки од редот Б.

Ориз. 10. Новото огледало на редот А ги прима сите постоечки пораки, но новото огледало на редот Б не.

Во двете редици пристигнуваат уште десет пораки. Брокерот 2 потоа се урива и редицата А се враќа во најстарото огледало, кое е на Брокер 1. Нема загуба на податоци кога ќе пропадне. Во редот Б, има дваесет пораки во главниот и само десет во огледалото бидејќи оваа редица никогаш не ги реплицирала оригиналните десет пораки.

Ориз. 11. Редот А се враќа на Брокер 1 без губење на пораките

Во двете редици пристигнуваат уште десет пораки. Сега се урива Брокер 1. Редот А лесно се префрла на огледалото без да губи пораки. Сепак, редот Б има проблеми. Во овој момент можеме да ја оптимизираме или достапноста или конзистентноста.

Ако сакаме да ја оптимизираме пристапноста, тогаш политиката ха-промоција-на-неуспех треба да се инсталира во секогаш. Ова е стандардната вредност, така што едноставно не можете воопшто да ја наведете политиката. Во овој случај, ние во суштина дозволуваме дефекти во несинхронизираните ретровизори. Ова ќе предизвика губење на пораките, но редицата ќе остане читлива и запишувачка.

Ориз. 12. Редот А се враќа на Брокер 3 без губење на пораките. Редот Б се враќа на Брокер 3 со десет изгубени пораки

Можеме и да инсталираме ha-promote-on-failure во значење when-synced. Во овој случај, наместо да се врати назад во огледалото, редицата ќе чека додека Брокер 1 со неговите податоци не се врати во режим на интернет. Откако ќе се врати, главната редица се враќа на Брокер 1 без загуба на податоци. Достапноста е жртвувана за безбедноста на податоците. Но, ова е ризичен режим што дури може да доведе до целосна загуба на податоци, што ќе го разгледаме наскоро.

Ориз. 13. Редот Б останува недостапен по губењето на Брокерот 1

Може да прашате: „Дали е подобро никогаш да не се користи автоматска синхронизација? Одговорот е дека синхронизацијата е блокирачка операција. За време на синхронизацијата, главната редица не може да изврши никакви операции за читање или запишување!

Ајде да погледнеме на пример. Сега имаме многу долги редици. Како можат да пораснат до таква големина? Од неколку причини:

• Редиците не се користат активно
• Тоа се редици со голема брзина, а токму сега потрошувачите се бавни
• Тоа се редици со голема брзина, имаше дефект и потрошувачите се надополнуваат

Ориз. 14. Две големи редици со различни начини на синхронизација

Сега Брокер 3 паѓа.

Ориз. 15. Брокерот 3 паѓа, оставајќи по еден господар и огледало во секоја редица

Брокер 3 се враќа онлајн и се создаваат нови огледала. Главната редица А започнува со реплицирање на постоечките пораки на новото огледало и за тоа време Редот е недостапен. Потребни се два часа за да се реплицираат податоците, што резултира со два часа застој за оваа редица!

Сепак, редицата Б останува достапна во текот на целиот период. Таа жртвуваше некој вишок за пристапност.

Ориз. 16. Редот останува недостапен за време на синхронизацијата

По два часа, редицата А исто така станува достапна и може повторно да почне да прифаќа читање и пишување.

Надградби

Ова однесување на блокирање за време на синхронизацијата го отежнува ажурирањето на кластерите со многу големи редици. Во одреден момент, главниот јазол треба да се рестартира, што значи или префрлување на огледало или оневозможување на редот додека серверот се надградува. Ако избереме да преминеме, ќе изгубиме пораки ако огледалата не се синхронизираат. Стандардно, за време на прекин на брокерот, не се врши откажување на несинхронизирано огледало. Тоа значи дека штом брокерот се врати, ние не губиме никакви пораки, единствената штета беше обична редица. Правилата на однесување кога брокерот е исклучен се поставени од полисата ha-promote-on-shutdown. Можете да поставите една од двете вредности:

• always= преминот кон несинхронизирани огледала е овозможен
• when-synced= премин само на синхронизирано огледало, инаку редицата станува нечитлива и незапишувана. Редот се враќа на услуга веднаш штом брокерот се врати

На еден или друг начин, со големи редици треба да изберете помеѓу губење на податоци и недостапност.

Кога достапноста ја подобрува безбедноста на податоците

Има уште една компликација што треба да се разгледа пред да се донесе одлука. Додека автоматската синхронизација е подобра за вишок, како тоа влијае на безбедноста на податоците? Се разбира, со подобар вишок, RabbitMQ е помала веројатноста да ги изгуби постоечките пораки, но што е со новите пораки од издавачите?

Тука треба да го земете предвид следново:

• Дали може издавачот едноставно да врати грешка и да побара од услугата или корисникот да се обиде повторно подоцна?
• Може ли издавачот да ја зачува пораката локално или во базата на податоци за да се обиде повторно подоцна?

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

Така, мора да се бара баланс, а решението зависи од конкретната ситуација.

Проблеми со ha-promote-on-failure=when-synced

Идејата ха-промоција-на-неуспех= кога-синхронизирано е тоа што спречуваме префрлување на несинхронизирано огледало и со тоа избегнуваме губење на податоци. Редот останува нечитлив или може да се запише. Наместо тоа, се обидуваме да го вратиме паднатиот брокер со неговите податоци недопрени за да може да продолжи да функционира како главен без загуба на податоци.

Но (и ова е големо, но) ако брокерот ги изгубил своите податоци, тогаш имаме голем проблем: редот е изгубен! Сите податоци исчезнаа! Дури и ако имате огледала кои главно се снаоѓаат со главната редица, тие огледала исто така се отфрлаат.

За повторно да додадете јазол со истото име, му кажуваме на кластерот да го заборави изгубениот јазол (со командата rabbitmqctl harroni_кластер_јазол) и започнете нов брокер со истото име на домаќинот. Додека кластерот се сеќава на изгубениот јазол, се сеќава на старата редица и несинхронизираните огледала. Кога на кластерот ќе му се каже да заборави јазол без родители, таа редица исто така се заборава. Сега треба повторно да го објавиме. Ги загубивме сите податоци, иако имавме огледала со делумен сет на податоци. Подобро би било да се префрлите на несинхронизирано огледало!

Затоа, рачна синхронизација (и неуспех да се синхронизира) во комбинација со ha-promote-on-failure=when-synced, според мое мислење, доста ризично. Документите велат дека оваа опција постои за безбедност на податоците, но тоа е нож со две острици.

Мастер ребаланс

Како што ветивме, се враќаме на проблемот со акумулацијата на сите мајстори на еден или неколку јазли. Ова може да се случи дури и како резултат на ажурирање на тркалачкиот кластер. Во кластерот со три јазли, сите главни редици ќе се акумулираат на еден или два јазли.

Мајсторите за ребалансирање може да бидат проблематични поради две причини:

• Нема добри алатки за ребалансирање
• Синхронизација на редица

Има трето лице за ребаланс додаток, што не е официјално поддржано. Во врска со приклучоците од трети страни во прирачникот за RabbitMQ кажа: „Приклучокот обезбедува некои дополнителни алатки за конфигурација и известување, но не е поддржан или потврден од тимот на RabbitMQ. Користете на ваш сопствен ризик“.

Постои уште еден трик за преместување на главната редица преку политиките на HA. Во прирачникот се споменува скрипта за ова. Работи вака:

• Ги отстранува сите огледала користејќи привремена политика што има повисок приоритет од постоечката политика за HA.
• Ја менува привремената политика на HA за да користи режим на јазол, наведувајќи го јазолот на кој треба да се пренесе главниот ред.
• Ја синхронизира редицата за притисни миграција.
• Откако ќе заврши миграцијата, се брише привремената политика. Почетното правило за HA стапува на сила и се создава потребниот број на ретровизори.

Негативната страна е што овој пристап можеби нема да работи ако имате големи редици или строги барања за технолошки вишок.

Сега да видиме како кластерите RabbitMQ работат со мрежните партиции.

Губење на поврзување

Јазлите на дистрибуираниот систем се поврзани со мрежни врски, а мрежните врски може и ќе се исклучат. Фреквенцијата на прекини зависи од локалната инфраструктура или доверливоста на избраниот облак. Во секој случај, дистрибуираните системи мора да бидат способни да се справат со нив. Уште еднаш имаме избор помеѓу достапност и конзистентност, и повторно добрата вест е што RabbitMQ ги обезбедува двете опции (само не во исто време).

Со RabbitMQ имаме две главни опции:

• Дозволете логичка поделба (сплит-мозок). Ова обезбедува достапност, но може да предизвика губење на податоци.
• Оневозможи логичко одвојување. Може да резултира со краткорочно губење на достапноста во зависност од тоа како клиентите се поврзуваат со кластерот. Може да доведе и до целосна недостапност во кластер со два јазли.

Но, што е логично раздвојување? Ова е кога кластерот се дели на два дела поради губење на мрежните конекции. Од секоја страна, огледалата се промовираат во мајстор, така што на крајот има неколку мајстори по кривина.

Ориз. 17. Главна редица и две огледала, секое на посебен јазол. Потоа се јавува дефект на мрежата и едно огледало се откачува. Одделениот јазол гледа дека другите двајца паднале и ги промовира своите огледала на господарот. Сега имаме две главни редици, и запишување и за читање.

Ако издавачите испратат податоци до двата господари, завршуваме со две различни копии од редот.

Различните режими на RabbitMQ обезбедуваат или достапност или конзистентност.

Режим за игнорирање (стандардно)

Овој режим обезбедува пристапност. По губењето на поврзувањето, настанува логично раздвојување. Откако ќе се врати поврзувањето, администраторот мора да одлучи на која партиција да и даде приоритет. Страната што губи ќе се рестартира и сите акумулирани податоци од таа страна ќе бидат изгубени.

Ориз. 18. Тројца издавачи се поврзани со тројца брокери. Внатрешно, кластерот ги насочува сите барања до главната редица на Брокер 2.

Сега го губиме Брокер 3. Тој гледа дека другите брокери паднале и го промовира своето огледало на господарот. Така настанува логично раздвојување.

Ориз. 19. Логичка поделба (сплит-мозок). Записите одат во две главни редици и двете копии се разминуваат.

Поврзаноста е обновена, но логичното раздвојување останува. Администраторот мора рачно да ја избере страната што губи. Во случајот подолу, администраторот го рестартира Брокер 3. Сите пораки што не успеал да ги пренесе се изгубени.

Ориз. 20. Администраторот го оневозможува Брокер 3.

Ориз. 21. Администраторот го стартува Broker 3 и тој се приклучува на кластерот, губејќи ги сите пораки што останале таму.

За време на губењето на поврзувањето и по неговото обновување, кластерот и оваа редица беа достапни за читање и пишување.

Режим на автоматско заздравување

Работи слично како режимот Игнорирај, освен што самиот кластер автоматски ја избира страната што губи по разделувањето и враќањето на поврзувањето. Страната што губи се враќа во кластерот празна, а редицата ги губи сите пораки што биле испратени само на таа страна.

Паузирајте го малцинскиот режим

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

Ориз. 22. Тројца издавачи се поврзани со тројца брокери. Внатрешно, кластерот ги насочува сите барања до главната редица на Брокер 2.

Брокерите 1 и 2 потоа се делат од Брокер 3. Наместо да го промовираат нивното огледало во господар, Брокерот 3 суспендира и станува недостапен.

Ориз. 23. Брокерот 3 паузира, ги исклучува сите клиенти и ги одбива барањата за поврзување.

Откако ќе се врати поврзувањето, се враќа во кластерот.

Ајде да погледнеме друг пример каде главната редица е на Брокер 3.

Ориз. 24. Главна редица на Брокер 3.

Потоа се случува истото губење на поврзувањето. Брокерот 3 паузира бидејќи е на помалата страна. Од другата страна, јазлите гледаат дека Брокер 3 паднал, така што постарото огледало од Брокери 1 и 2 е промовирано во господар.

Ориз. 25. Премин кон Брокер 2 ако Брокерот 3 е недостапен.

Кога ќе се врати поврзувањето, Брокер 3 ќе се приклучи на кластерот.

Ориз. 26. Кластерот се врати во нормална работа.

Она што е важно да се разбере овде е дека добиваме конзистентност, но можеме да добиеме и достапност, ако Ние успешно ќе ги префрлиме клиентите во поголемиот дел од делот. За повеќето ситуации, јас лично би го избрал режимот Пауза на малцинствата, но тоа навистина зависи од индивидуалниот случај.

За да се обезбеди достапност, важно е да се осигура дека клиентите успешно се поврзуваат со домаќинот. Ајде да ги погледнеме нашите опции.

Обезбедување на поврзаност со клиентите

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

Нашите опции:

• До кластерот се пристапува со помош на балансерот на оптоварување кој едноставно кружи низ јазлите и клиентите се обидуваат повторно да се поврзат додека не успее. Ако некој јазол е исклучен или суспендиран, тогаш обидите за поврзување со тој јазол ќе пропаднат, но последователните обиди ќе одат на други сервери (на кружен начин). Ова е погодно за краткорочно губење на поврзувањето или за пад на серверот што брзо ќе се врати назад.
• Пристапете до кластерот преку балансерот на оптоварување и отстранете ги суспендираните/неуспешни јазли од списокот веднаш штом ќе бидат откриени. Ако го направиме ова брзо, и ако клиентите можат повторно да се обидат со врската, тогаш ќе постигнеме постојана достапност.
• Дајте му на секој клиент список со сите јазли и клиентот по случаен избор избира еден од нив кога се поврзува. Ако прими грешка при обидот да се поврзе, се преместува на следниот јазол во листата додека не се поврзе.
• Отстранете го сообраќајот од неуспешен/суспендиран јазол користејќи DNS. Ова е направено со користење на мал TTL.

Наоди

Кластерирањето RabbitMQ има свои предности и недостатоци. Најсериозните недостатоци се тоа:

• кога се приклучуваат на кластер, јазлите ги отфрлаат своите податоци;
• блокирањето на синхронизацијата предизвикува редицата да стане недостапна.

Сите тешки одлуки произлегуваат од овие две архитектонски карактеристики. Ако RabbitMQ би можел да зачува податоци кога кластерот е повторно споен, тогаш синхронизацијата би била побрза. Ако можеше да не блокира синхронизација, подобро ќе поддржува големи редици. Поправањето на овие два проблеми во голема мера ќе ги подобри перформансите на RabbitMQ како толерантна за грешки и високо достапна технологија за пораки. Јас би се двоумел да препорачам RabbitMQ со кластерирање во следниве ситуации:

• Несигурна мрежа.
• Несигурно складирање.
• Многу долги редици.

Кога станува збор за поставки за висока достапност, размислете за следново:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Или autoheal)
• постојани пораки
• осигурајте се дека клиентите се поврзуваат со активниот јазол кога некој јазол не успее

За конзистентност (безбедност на податоците), разгледајте ги следните поставки:

• Издавачот потврдува и рачно признанија на страната на потрошувачот
• ha-promote-on-failure=when-synced, ако издавачите можат да се обидат повторно подоцна и ако имате многу доверливо складирање! Во спротивно стави =always.
• ha-sync-mode=automatic (но за големи неактивни редици може да биде потребен рачен режим; исто така размислете дали недостапноста ќе предизвика губење на пораките)
• Паузирајте го Малцинскиот режим
• постојани пораки

Сè уште не сме ги опфатиле сите прашања за толеранција на грешки и висока достапност; на пример, како безбедно да се извршат административните процедури (како што се тековните ажурирања). Треба да зборуваме и за федерација и додатокот Shovel.

Ако пропуштив нешто друго, ве молам известете ме.

Видете го и мојот пост, каде што извршувам хаос на кластерот RabbitMQ користејќи Docker и Blockade за тестирање на некои од сценаријата за губење на пораки опишани во овој напис.

Претходни написи од серијата:
бр. 1 - habr.com/ru/company/itsumma/blog/416629
бр. 2 - habr.com/ru/company/itsumma/blog/418389
бр. 3 - habr.com/ru/company/itsumma/blog/437446

Извор: www.habr.com