Мина лекцията във вторник, има запис и може да си свалите пълния архив с презентацията и парчетата псевдокод.
Отделно ето я и самата презентация.
Става въпрос за тип задача, която не намерих в design patterns, и за която има различни парчета софтуер, които правят нещо подобно (rabbitmq, gearman). Основната причина да се пише от нулата, вместо да се ползва нещо готово е, че се интегрира много по-добре в съществуващата система и така е доста по-просто, отколкото да се добавя още някакво парче код.
(и е интересна задача :) ).
Имам в практиката си три реализации, като това, което показвам прилича най-вече на една от тях, система за encode-ване в няколко формата на видео. Имаме много сървъри, които се занимават с encode-ването (cli.*) и които си взимат задачи от централен диспечер (srv.*), който има някакъв вариант да пази persistent state (в моя случай – база данни). Задачите са индемпотентни, т.е. могат да бъдат изпълнени повече от един път, ако се наложи.
Езикът, който съм ползвал в примерите е в общи линии псевдокод, който прилича на смесица от perl и php. Странните неща в него са, че има мнoжествено връщане (т.е. конструкция от типа $a, $b = f()) и че respond в srv.* връща отговор на клиента и излиза, т.е. прилича малко на return. man pages описват семантиката на fork и wait.
Начален вариант на решението би бил с този диспечер и този клиент.
Първият проблем, който се вижда е, че ако сървърът не успее да свърши задачата, няма как да го съобщи на диспечера. Това лесно се коригира с добавяне още на един тип заявка към диспечера:
Версия 1: диспечер и diff от предишната версия, клиент и diff от предишната версия.
Вторият проблем е какво става, ако заявим, че искаме задача, диспечера ни я задели, но не получим отговора? Ако нямаме обработка на този случай, в такива ситуации ще се натрупват задачи, които се водят, че се обработват и реално никой не ги е взел. Решението, до което аз стигнах е да добавя на всеки сървър transaction id и при заделяне на задача диспечерът да отбелязва сървъра и transaction id. Ако клиентската част подаде заявка за нова задача и не получи отговор, трябва специално да подаде обратно заявка за “cancel”, за да сме сигурни, че неполучената задача е върната в pool-а на свободните задачи.
Версия 2: диспечер и diff от предишната версия, клиент и diff от предишната версия.
Третият проблем е рестартирането на някой от сървърите, които обработват задачи – например поради спрял ток. Когато той се стартира отново, според диспечера ще има няколко задачи, които той обработва и за които той не знае. Решението е просто – добавя се тип заявка, която се подава при рестарт и почиства работещите задачи за даден сървър.
Версия 3: диспечер и diff от предишната версия, клиент и diff от предишната версия.
Четвъртият проблем (който би трябвало да е един от първите) е колко често и кога да се опитваме да повторим заявка към сървъра. Всяка заявка, която може да подадем може да стигне, но може и да не стигне до сървъра, или ако стигне, нямаме гаранция, че ще получим отговор. Съответно трябва да добавим към srv_request() в клиентската част логика колко пъти и как да опитва – само веднъж, много пъти или безкрайно. Заявяването на задача трябва да се изпълнява точно един път, останалите неща – докато се получи отговор.
(от “много пъти” смисъл в повечето случаи няма и би трябвало да го махна от кода)
Друг проблем, който се вижда доста бързо е, че ни трябва нещо от типа на exponential backoff, за да разредим честотата на опити от страна на сървърите към диспечера. Това се прави, за да се избегне ситуация от която след restart изведнъж се изсипват твърде много заявки в/у диспечера и има шанс да го претоварят. Същото нещо може да се види и в доста мрежови протоколи, например TCP.
Версия 4: клиент и diff от предишната версия.
Петият проблем е да ограничим колко товарим себе си (и донякъде сървъра), като ограничим броя задачи, които изпълняваме. Прави се сравнително просто, с брояч на вървящите в момента child процеси.
Версия 5: клиент и diff от предишната версия.
Шестата версия е основно дописване и доподреждане на кода, с оправяне на няколко проблема, които само ми хрумнаха и не съм виждал на живо. Едното нещо е валидация на state на определена задача, другото е един race condition м/у fetch и cancel (който по принцип не трябва да може да се случи).
Версия 6: диспечер и diff от предишната версия.
Има функционалност, която по различни причини не е дописана в този код:
– да връщаме на всеки сървър колко да изчака, преди пак да пита за задача, като метод за flow control.
– job timeout/job restart – да решаваме по някакъв начин кога да рестартираме определена задача (понеже е възможно сървърът и да е умрял и да не се е върнал повече). Това не пасва добре в текущия код, т.е. трябва да се напише отделен компонент, който се вика периодично или работи като демон при диспечера, който да изпълнява тази функционалност, а самата логика за това зависи твърде много от контекста.
– Log на всички събития – животоспасяващ при всякакво дебъгване.
– Monitoring и аларми при различни състояния, дефинирани като проблемни (твърде много чакащи задачи, твърде много обработвани и т.н.) – пак трябва да е в отделен от тези два компонента.