как этому поделию отправлять жобы? + у него причуды, лучше уж крон для простого шедулинга

крч, два стула, если джобсы в случае чего надо сохранить и возобновить обработку при поднятии сервиса, то либо MQ, либо городить свой велосипед на основе БД если похуй на потерянные задания, любой RPC без таймаута

как этому поделию отправлять жобы? + у него причуды, лучше уж крон для простого шедулинга

ну по идее тогда это https://github.com/Automattic/kue

хз

нахуй редис, если есть rabbitmq?

а если память кончится?

а если память кончится?

а если не кончится?

rabbitmq хотя бы на диск сохранит очередь

эмм

редис тоже может так

редис тоже может так

тогда удачи

если не кончится то похуй

вообще, мне сложно представить ситуация, когда средний сервер в районе 20 евро вдруг просядет по оперативке из-за редиса

прямо фантазии какие-то, не хайлоад же

редис в памяти целиком хранит всё, дамп на диск это просто плюшка

ну ещё он не каждую запись дампает, там в зависимости от настроек

на дефолтных можно будет проебать 15 заданий

есть ещё третий стул, это админка и либо делать единый REST endpoint (первый вариант), либо два (приватный и публичный, второй + первый)

ты бы еще спросил как параметр назвать

бля, тебе нечего сказать по дизайну, молчи

так, а авс лямбда позволяет через апи задачу зашедулить?

вообще, мне сложно представить ситуация, когда средний сервер в районе 20 евро вдруг просядет по оперативке из-за редиса

дудос

так, а авс лямбда позволяет через апи задачу зашедулить?

в cloudwatch есть крон

как по твоему, клиенту понравится, если все задания проебутся?

а потом ручками всё это перезапускать

дудос

обходится на уровне балансера и нджинкса

обходится на уровне балансера и нджинкса

удачи

никто не будет ддосить микросервис)

никто не будет ддосить микросервис)

так будешь говорить, пока не начнут ддосить

+ не составит никакой трудности вычислить что именно идет в очередь, а потом заспамить её

Парни, как вы решайте job queue

bull юзаю

мне одному кажется что редиска быстрее чем кролик

да дело не в скорости, кролик быстрее и лучше, но нужен когда гигантский поток задач. когда у тебя обычный проект, редис лучше и проще, вы думаете просто так kue, bee-queue, bull на редисе построили а не не кролике?

нет, блин, я вообще сейчас не понял - он быстрее или нет? не "для" "для" а сравним его поднятие, внедрение, все дела и т.д. и потом насколько он на обычных проектах будет быстрее

или просто тогда не сравниваем да и дело с концом

кролик конечно быстрее, но кого волнует?

я как бы тоже понимаю что они немного для разного, но дело-то не в этом

Job queue и message broker разные вещи и решают разный спектр задач. Редис первый, кролик второе, кафка третье

вооооооот

хотя и похоже иногда но все же

НО, если мы юзаем обе темы для одного и того же - редиску для паб-саба и кролика для очереди сообщений - кто быстрее доставит инфу из пункта А в пункт Б?

Теоретически редис бо нет накладных расходов на слой транспорта - amqp

лучше на гарантии смотри, скорость очереди не должна ботлнечить

а что гарантии если я на них смотрю как на udp?

Теоретически редис бо нет накладных расходов на слой транспорта - amqp

вооот

и не теоретически а у девопсов спроси, они тебе точно скажут что быстрее)

Согласен с мурзиком. месадж басы это больше о гарантии выполнения а не скорости выполнения

нахуй редис, если есть rabbitmq?

да я все к этому начал

я как бы не спорю с вами, коллеги

Нужна скорость - берите zeromq или nanomq или вообще сокеты

Девопсы скажут что редис курит в сравнении

да тут вообще вопрос не в скорости а в том что ты в предыдущем посте написал, в этом и суть. какие цели спрашивается

Верно. Полностью согласен с собой

и нахуй спрашивается сравнивать редиску и кролика

вооот

вот и я об этом

сорян за задержку у меня прокся херово работает сегодня

Согласен с мурзиком. месадж басы это больше о гарантии выполнения а не скорости выполнения

на самом деле я бы даже сказал что это даже не столько для гарантии сколько для того чтобы можно сущность сервис брокера как такового вводить) гарантию-то и задачи дают, если ставить им лимит попыток в бесконечность

Имелось в виду в сравнении с очередью в памяти без персистенции. Например пул запросов к серверу. Или тупая fifo в zeromq. Выключили свет и все, тушите сервера

В раббите можно задать время жизни сообщений для канала

это ты к чему? ну можно, круто

он именно этим круче редиски?

В раббите можно задать время жизни сообщений для канала

Круто ему

ERROR: S client not available

Редис может проебать сообщение

да я блять не понимаю как можно сравнивать DI и аргумент функции например. или SaltStack и Ansible. или restify и Feather. блять ну разные это вещи (админы простите за мат)

как можно сравнивать теплое и зеленое

Редис может проебать сообщение

А редис это вообще не mq и даже не job queue

редис - это БД)

А что?

и все

БД

не надо бд и сторадж сравнивать

редис это nosql

точнее даже сторадж, да, сорян

Не надо не надо

в любом случае это - Хранилище Данных

а mq это что

yep, key-value persistent data storage

Nosql это монга

...

который может быть бэком к mq если я не ошибаюсь

Редис кей-вал сторадж

который может быть бэком к mq если я не ошибаюсь

+

а mq это что

MQ синоним message broker'а чаще всего.

queue это брокер?

Толькот не доебывайте терминологией

MQ синоним message broker'а чаще всего.

я-то знаю)))

вроде ж очередь сообщений

Лучше к созидателям

да к праотцам сразу ху.е

Менеджер очередей

Менеджер очередей

огласи еще раз задачу, закончим этот фарс

Мне то нахуя задачу оглашать?