S tou konzumaci zprav, nevim jestli lze rucne potvrzovat zpravu, aniz bych potvrdil tu predchozi, ale tipl bych si ze ne.
V kazdem pripade se mi i libi, ze to polluje za me a nemusim mit smycku a vola to muj kod samo.
Na konferencich lide nadavaji na Kafku, protoze se spatne spravuje (coz potvrzuji) a pry prechazeji na Rabbit. Tohle se mi libi vic nez Kafka, takze to urcite stoji za vyzkouseni.
Jde to. Múžete si třeba vybrat 100 zpráv a acknout je později.
Spíš jsem narazil na jeden nepříjemný a dost neočekávaný bug/vlastnost: pokud si vybere proces správu a spadne před acknutím, tak sice správa je stále ve frontě (vidět jako unacked v management konzoli), ale následně ji dostane i proces, který se přihlásí s routing key, který to nematchuje. Chovalo se to takto pro direct i topic fronty.
To by se stávat nemělo. Stane se to vždycky jen po pádu konzumenta (resp. po uzavření kanálu - protože RabbitMQ neví nic o procesu, jen o kanálu IMHO) nebo i když jen pošle NACK?
Něco podobného jsem viděl kdysi u kombinace Celery+Rabbit, ale tam šlo o to, že Celery v té době špatně implementovalo nějakou sémantiku AMQP (on je ten protokol docela začmodrchaný :-)
Fakt ma Rabbit srovnatelne dobre resene HA a performance jako Kafka? A umi Rabbit seekovat v topicu, pamatovat si last committed offset consumera a pokracovat po restartu daneho consumera tam kde prestal? Zvlastni, me se naopak libi explicitni pollovani Kafky s timeoutem a nelibi callback.
Podle mě to neumí a je zapotřebí si vybrat, co přesně potřebujete pro práci. U nás máme RabbitMQ a SQS jako "obyčejné" message brokery, kde prostě zpráva buď přijde a je ACKovaná nebo není. Kafka je zase perfektní na zpracování výstupů od našich wannabe-AI lidí - to jsou mraky obrovských vektorů a tam Kafka vyhrává.