Вітаю. Підтверджую неадекватну поведінку кластеру кроля під суттєвим навантаженням. Нажаль про альтернативу йому, щоб архітектурно була 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 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 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

Передивився доки, бо давно то вже все було (і exactly once) схоже завезли з тих часів. Так, можна досягти, що буде прочитане лише раз. Але Кафку тре буде відповідно приготувати. Конс'юмера повинні бути в одній групі і слухати один торік. Також треба буде налаштувати партиції в топіку т.к. в Кафці одна партиція до одного конс'юмера. Якщо конс'юмер відвалиться, або з'являється новий, тоді відбувається реблансування задля уникнення дублікатів. - https://www.confluent.io/resources/ebook/kafka-the-definitive-guide/ - дуже корисна книжка від чуваків, що на Кафці гроші заробляють - https://medium.com/@aviksaha2007/exactly-once-processing-with-apache-kafka-4... - дядько пише куди дивитися в приготуванні Кафки для exactly once Сподіваюсь допоможе. чт, 12 вер. 2024 р., 18:53 користувач Volodymyr Litovka пише:

Привіт,

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

Хіба якщо СУБД вміє per-row lock. Якщо лочить таблицю, то краще вже кріль... сб, 14 вер. 2024, 22:04 користувач Taras Heichenko пише:

12.09.2024 19:08, Volodymyr Litovka via UANOG:

...

Я не захваті від ідеї використовувати БД як 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 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

-- tasic@

_______________________________________________ UANOG mailing list -- uanog@uanog.one To unsubscribe send an email to uanog-leave@uanog.one

Я про те, що це декілька операцій - select record_id, ... where lock_record = true update ... set lock_record=true where record_id = id а select ... for update, який типу атомарний, лочить таблицю. On 9/14/24 21:08, Taras Heichenko wrote:

14.09.2024 22:06, Vladimir A. Podgorny:

...

Хіба якщо СУБД вміє per-row lock. Якщо лочить таблицю, то краще вже кріль...

Ну звичайно лочка на рівні записів. Але оскільки з базою в цьому випадку працюють тільки твої тулзи, то лочкою запису може бути, наприклад, true в полі lock_record ;)

...

сб, 14 вер. 2024, 22:04 користувач Taras Heichenko пише:

    12.09.2024 19:08, Volodymyr Litovka via UANOG:     > Я не захваті від ідеї використовувати БД як 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     >> 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

    --     tasic@

    _______________________________________________     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

Я не знаю, наскільки воно може бути великим. Задача - обробляти події від 40+ мільйонів пристроїв, які періодично (деякі - раз на добу, деякі - раз на декілька хвилин) будуть щось слати. Ну й можуть виникати пікові навантаження у випадку outage на мережах. Гадаю, шо варто підстрахуватися та від початку не використовувати софт, який може склеїти ласти :) On 9/13/24 15:18, Oleksii Radetskyi wrote:

Привіт!

Якщо у тебе дійсно супер велике навантаження, то варто глянути в сторону ZeroMQ. Kafka як можлива альтернатива.

А може варто просто правильно приготувати RabbitMQ ?

On Thu, Sep 12, 2024 at 9:01 PM Maksym Tulyuk wrote:

Привіт

Можна спробувати: ZeroMQ/Kafka/Mosquitto.

Макс

> On 12 Sep 2024, at 17:30, Volodymyr Litovka via UANOG 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

_______________________________________________ UANOG mailing list -- uanog@uanog.one To unsubscribe send an email to uanog-leave@uanog.one

_______________________________________________ UANOG mailing list --uanog@uanog.one To unsubscribe send an email touanog-leave@uanog.one

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

Дякую, а шо з навантаженням? Треба обробляти близько 10k messages per second :) On 9/13/24 15:57, Gregory Edigarov wrote:

On Thu, 12 Sep 2024 17:30:02 +0200 Volodymyr Litovka via UANOG wrote:

...

Привіт,

порадьте менеджер черг для високонавантажених систем, окрім RabbitMQ. Про цього чувака я знаю, але колеги з розробки кажуть, що він косячить під високим навантаженням. Я не можу ані підтвердити, ані спростувати це твердження - я його користував тіко в комплекті з опенстеком, де у мене не було ані навантаження, ані проблем.

Тому, насправді, питання два: - порадьте менеджер черг для високонавантажених систем, окрім RabbitMQ - якщо хтось юзає ребіт під навантаженням - що думає?

Дякую.

кроме тех, что уже посоветовали - как вариант NATS https://github.com/nats-io.

используется у нас много где.

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

Дякую за NATS, прекрасна система. Відтепер використовувати ребіт просто немає сенсу, ні за яких обставин :) On 9/27/24 11:06, Gregory Edigarov wrote:

On Wed, 25 Sep 2024 07:33:53 +0200 Volodymyr Litovka via UANOG wrote:

...

Дякую, а шо з навантаженням? Треба обробляти близько 10k messages per second :) даже не подавится :) когда я его тестил - получалось где-то миллион в секунду. это на не самом быстром железе, и мне больше нужно не было.

https://gcore.com/learning/nats-rabbitmq-nsq-kafka-comparison/ тут пишут, что 6 миллионов в секунду может пропустить, но повторюсь мне столько не было нужно.

...

On 9/13/24 15:57, Gregory Edigarov wrote:

...

On Thu, 12 Sep 2024 17:30:02 +0200 Volodymyr Litovka via UANOG wrote:

...

Привіт,

порадьте менеджер черг для високонавантажених систем, окрім RabbitMQ. Про цього чувака я знаю, але колеги з розробки кажуть, що він косячить під високим навантаженням. Я не можу ані підтвердити, ані спростувати це твердження - я його користував тіко в комплекті з опенстеком, де у мене не було ані навантаження, ані проблем.

Тому, насправді, питання два: - порадьте менеджер черг для високонавантажених систем, окрім RabbitMQ - якщо хтось юзає ребіт під навантаженням - що думає?

Дякую.

кроме тех, что уже посоветовали - как вариант NATS https://github.com/nats-io.

используется у нас много где.

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