Привіт,
вірно я розумію, що Кафка (згаданим offset'ом) все ж таки може робити, що будь-яке повідомлення буде прочитано тільки один раз?
Наскільки я зрозумів з твоїх слов - офсет оновлюється автоматично й щоб повернутись до старого повідомлення, треба явно відмотати офсет назад.
Дякую.
On 9/12/24 18:46, Illia Lavrovskyi wrote:
Вітаю.Підтверджую неадекватну поведінку кластеру кроля під суттєвим навантаженням.
Нажаль про альтернативу йому, щоб архітектурно була 1-до-1 я не знаю.
В якості черги є Kafka - https://kafka.apache.org/ (також є PaaS від Confluent), є Redpanda - https://github.com/redpanda-data/redpanda/, є клаунді рішення.Kafka - це one love.Redpanda виглядає дуже цікаво, але особисто так і не довелося з нею пожити.
Архітектурно у RabbitMQ бачу одну гарну річ - він може гарантувати шо певну повідомленні буде прочитане лише раз, не зважаючи скільки конс'юмерів слухають чергу.З Kafka доведеться робити яку логіку саме не боці конс'юмерів (якщо їх більше одного).
Але Kafka дурнюща в сенсі швидкості і пропускної здатності. І вона по суті є логом повідомлення. Це означає, що якщо певне повідомлення все ще в лозі, але вже давно було опрацьоване - до нього можна легко повернутися (offset) і переопрацювати, чи просто на нього подивитися. В купі разів це було дуже при нагоді, коли щось не спрацювало, ти виправляєш баг, а потім просто скидаєш offset до потрібного і все пробігає вже як треба.
On Thu, Sep 12, 2024 at 6:08 PM Volodymyr Litovka via UANOG <uanog@uanog.one> wrote:
Я не захваті від ідеї використовувати БД як 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
--
-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison