Я не захваті від ідеї використовувати БД як queue._______________________________________________
Одна з причин - у черги операція "взяв в обробоку" атомарна, тобто як тільки воркер забрав повідомлення, воно зникає й, відповідно, не попаде нікому іншому в обробку. У випадку з БД це процедура з щонайменше з двох кроків - "взяв в обробку, видалив з БД", тобто одне повідомлення може бути взято в обробку одразу декількома воркерами.
On 9/12/24 17:44, Mykola Ulianytskyi wrote:
Привіт
> - якщо хтось юзає ребіт під навантаженням - що думає?
Дико тормозить при великої кількості (десятки тисяч) queues / streams / channels да так, що API лежить повністю.Vertical scaling не вирішив проблему (32 ядра, 64GB RAM).
Переписали мікросервіс на MongoDB InMemory (Percona Memory Engine) та забули про всі проблеми з перфомансом.
--
Best regards,
Mykola
On Thu, Sep 12, 2024 at 6:30 PM Volodymyr Litovka via UANOG <uanog@uanog.one> wrote:
Привіт,
порадьте менеджер черг для високонавантажених систем, окрім RabbitMQ.
Про цього чувака я знаю, але колеги з розробки кажуть, що він косячить
під високим навантаженням. Я не можу ані підтвердити, ані спростувати це
твердження - я його користував тіко в комплекті з опенстеком, де у мене
не було ані навантаження, ані проблем.
Тому, насправді, питання два:
- порадьте менеджер черг для високонавантажених систем, окрім RabbitMQ
- якщо хтось юзає ребіт під навантаженням - що думає?
Дякую.
--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison
_______________________________________________
UANOG mailing list -- uanog@uanog.one
To unsubscribe send an email to uanog-leave@uanog.one
-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
UANOG mailing list -- uanog@uanog.one
To unsubscribe send an email to uanog-leave@uanog.one