Názory k článku Použití nástroje RQ (Redis Queue) pro správu úloh zpracovávaných na pozadí

Díky.

Já se právě snažím hledat alternativu k SQS, které má svoje problémy a myslím si, že Redis (Sentinel) + RQ by mohlo být elegantní a dost minimalistické řešení ve stylu "kdo nic nedělá, nic nezkazí".

Tak na Sentinel pozor. Z principu návrhu může Redis přijmout a zahodit data v případě Split-brainu. Protokol Sentinelu je race condition, někde se na to dál vygooglit článek "Redis sentinel: call me maybe", ale píšu z mobilu, takže vám teď odkaz nebo přesný název nedám.

Tak nakonec jsem to z mobilu našel. Je to staršího data, tak dávám rovnou odkaz na komentář, který tvrdí, že problém stále trvá: https://aphyr.com/posts/283-jepsen-redis#comment-2591

Díky. Ano, to může být problém. Situace, kdy by se task vykonal vícekrát, vlastně nevadí (stejně se při problémech zařadí zpátky na konec fronty s nějakým sníženým TTL), ale ztráta by se hledala hůř.

Ještě se dívám, že autor toho blogpostu používá Clojure - můj člověk :D

Jj díky za doplnění.

uwsgi má funkcionalitu spooler, funguje podobně, ale místo do redisu ukládá čekající úlohy do souborů.

RabbitMQ je overkill, zbytečná závislost navíc. To stejné redis, pokud ho nepotřebujete na nic jiného než message queue. Podle mě se dá ve většině aplikací s message queue vystačit s SQL jako backendem.

Při větší zátěži je fronta implementovaná SQL bottleneck - pokud se bavíme třeba nad 2000 insert/delete za sec. Datové struktury, formáty relačních databází nejsou pro implementaci front optimalizované. Pro menší zátěž je to samozřejmě jedno.

Typické použití je na joby, které trvají dlouho a dělají něco náročného. Tam je režie se správou fronty zanedbatelná.

Pokud tam není intenzivní zátěž, tak je to ok - tj pro déletrvající joby. Mám zákazníka, kterému fronty implementované v SQL fungovaly 5 let, ale s tím jak intenzivně zvyšoval zátěž musel přejít na nativní message queue sw. Jejich joby oscilují mezi stovkami milisec a několika sec, problémem jsou několika minutové peaky, kde se takových jobů může protočit desítek tisíc - navíc v systému citlivém na latence.

Jinak, pokud by se používalo SQL řešení pro zátěž do cca 500-1000 tps, tak dost možná bych si nekomplikoval život a použil SQL db, u větší zátěže spíš asi ne.

Jezdím po zákaznících a mám docela problém říct, co je typické použití - alespoň u mých zákazníků nic typického nevidím.

Předpokládám, že to bylo nad MyISAM nebo in memory. Dost možná, že za pár let to bude jedno - jakmile budou k dispozici inmemory ACID SQL databáze - ale i tak - relační tabulka je halda, a nemůže se výkonnostně srovnávat s čímkoliv, co má frontu opravdu implementovanou interně jako frontu. U msg queue systémů dost často nemáte implementovaný UPDATE -- pouze něco jako INSERT, a SELECT + DELETE. Pokud vím, že nebude UPDATE, tak si mohu dovolit mnohem jednodušší formát - navíc fronty mají typicky relativně málo záznamů - což mohu zase využít pro výkonnostní optimalizace - např. mohu pracovat se záznamem jako s větou fixní velikosti, atd.