Привіт,

вірно я розумію, що Кафка (згаданим 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


--
Illia Lavrovskyi
e-mail: blackprowler@gmail.com

-- 
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison