я человек простой. бд + gearman + supervisord

Я "очереди" на БД стараюсь не делать, потому что скорее всего будет жопа или по коннектам, или слишком много optimistic concurrency ошибок, что приведет к деградации всей БД

А вот "job"-ы можно, но нам точно нужна именно "очередь"

Давид, наверное тут неправильно сформулирован вопрос.

Очередь понятия такое, что это может быть за алгоритм FIFO, а может быть целое приложение реализующее очередь задач как rmq c retry, dlq и другими фичами.
У тебя в списке всё в кучу.

Альтернативы rmq это pulsar.
Ещё есть решения очередей задач типа bullmq, redis-smq, asynq, kubemq и т.п. Они все поверх redis, nats и других брокеров сообщений и стриминговых протоколов.

И стриминга вроде нет в mqtt, но есть в nats jetstream, pulsar и т.п.

Стриминг всё же это тип протокола, как у Kafka и redpanda они абсолютно одинаковые с точки зрения протокола, но разные по реализации этого протокола.

Есть graphile на pg через pub/sub встроенный, много встречал что используют. Но я и pg не стал бы при выборе стэка)

Да, несомненно я утрировал:

Мне нужна FIFO с вариантами персистенции (none c fire-and-forget и cluster лучше log формата) и в идеале гарантией на эксклюзивность (только 1 читатель)

При определенных действиях этого можно достичь на каждой системе:

– RMQ с single active consumer (и потенциально exclusive, но от него больше проблем, лучше самому простой лок на redis сделать)
– Kafka с разбитием по топикам и 1 партицией + хранить курсор на оффсет + маленький TTL, чтобы не хранить долго данные
– Либы на Redis + использовать / написать лок на 1 топик = 1 консьюмер

Про redis: не доверяю JS библиотекам + это не кросстек (у нас в частности все больше появляется Go) + нам нужна иногда персистенция, а redis персистенции я не доверяю

Kafka / Redpanda: ненавижу zookeeper + очень толсто по ресурсам (но тот же RMQ в итоге тоже жрет немеренно при нагрузке) + не хотелось заниматься хранением курсора + сложно разворачивать отдельные "мини-кластера" (условно как мы можем просто и быстро иметь свои Redis / Nats серваки)

PG: итак в пределе коннектов (а мы еще даже не начинали давать реальную нагрузку)

MQTT: я использовал VerneMQ и у него есть возможность настроить FIFO, но это было 4 года назад, не смотрел что сейчас у них

Jetstream: давно слежу за их YouTube, вижу как последний год они оживились, но там были какие-то очень корневые проблемы почему я давно от них отказался (но сам NATS как message broker – замечательная технология)

RMQ: ну, сами видим

Про pulsar не слышал, посмотрю, спасибо)

Redis -> KeyDB с нормальной кластаризацией и персистентностью snapchat коммерчески поддерживает в продашене и у других крупных компаний тоже под капотом есть, альтреатива dragonfly ещё.

Redpanda это no-jvm и no-zookeeper, вообще, и в kafka последней уже отказались от zookeeper там есть raft версия kraft называется

nats jetstream ты абсолютно прав, они до сих пор в changelog говно фиксят, страшно смотреть, порой очень детские баги ведущие к фатальному завершению процесса, иногда с хардовым битьем данных. В продашен опасно такое.

pulsar это кафка для богатых в народе)

У нас на обоих проектах кластер KeyDB при проблемах с сетью просто делал split-brain и разъебывал всю консистентность

Мы перешли на практически ручной шардинг Redis

Вот на dragonfly смотрим, интересная штука, но опятьже логику очередей надо будет реализовать в виде отдельного сервиса, с которым будем общаться, а он уже будет давать нам функционал очереди

Repanda тоже заебись, если нужен будет kafka-like (звучит как darksouls-like) точно возьме Redpanda

Ахахах для меня "для богатых" звучит как "сожрет все деньги на инфру и зарплаты devops"

интересно было бы подробности как split-brain произошёл в raft log

На нашем проекте он просто давал 2 разные картины в 2-х сервисах (с учетом наличия 3-х инстансов) + скорость SCAN упала в сотни раз (знаю, что дорогостоящая операция, но на redis хотябы в какой-то адекватный период времени можно было пройтись по ключам и потоково обрабатывать, а в keydb просто жесть как было долго)

На стороннем проекте я усточню подробности, но ребята там в один момент чуть сума не сошли когда не понимали почему у них совершенно разная картина в разных сервисах

https://www.confluent.io/kafka-vs-pulsar/ тут про rmq тоже

А RAFT разве не способен сделать split-brain?

Представим сетевую проблему при которой 7 нод разделятся на 3 и 4, там где 4 Node просто не пройдет голосование?

Или они отрубят 4-ю ноду от голосвания?

Или там вообще majority это 5 нод?

не будет такой проблемы, там рандомный таймаут для голосования между нодами, и консенсус будет достигнут в 99.9% с первого раза на чётном количестве нод, иначе новый раунд запустят

А, я понял, 3 ноды просто не будут работать, а 4 будут

3 минимальное количество для консенсуса, так что будут, и 3, и 4 и любое количество больше, но не меньше

Тогда при разделе на 3 и 4 каждый кластер продолжит оперировать самостоятельно, что и создаст split-brain

Вроде как, если у тебя 7 нод, тебе нужно минимум 4, чтобы продолжать работать

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

минимум 3, но кластер может развалиться на 2 части, если это гео распределённый кластер, для этого нужно больше логики это более сложная задача супер кластера

создаётся отдельная рафт группа по гео и отдельные внутри каждого гео

можно почитать как это сделано у кокроуча например или эластика через бинарный лог

Ну, известен имеешь ввиду засчет рандомного таймаут? Но тут надо еще брать в учет, что какая-то нода раньше может увидеть отсутствие health check от leader и ее таймаут будет быстрее

Я знаю, что в Leader Paxos у каждой ноды есть порядковый номер, поэтому каждый следующий лидер известен заранее поскольку они идут просто по этому порядковому номеру

Это как я понимаю Multi-Raft (вот такую штуку недавно читал)

Короче, скажем так: как-будто бы было бы логичнее RAFT учитывать развал при котором существует как минимум большинство (Math.floor(N/2) + 1) и полностью вырубать набор нод, в которых меньше большинства

Но тут мне надо почитать еще

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

это так и называется фактор репликации N+1, что означает 2+1, 3+1 и т.п.

Но тогда на 7 нод фактор репликации это 4, верно?

фактор 3, значит 3+3 ноды +1 условия консенсуса

Ага, и получается если развалились на 3 и 4 ноды, то сет 3-х нод перестанет быть активным, верно?

3 всё ещё активны, но мы говорили про split brain, он может быть и 3 на 3, если кластеры получают изоляцию по сети, то механизм синхронизации при восстановлении может быть CRDT поверх raft log

Вот я и хочу уточнить: сам по себе ведь RAFT не гарантирует отсутствие split-brain?

Кстати, единственная база с CRDT с которой я работал это CouchDB и мне стало очень странно, почему их протокол так мало используют

Может, я не достиг тогда реальных проблем

ну скажем так, никакая система не сможет гарантировать на 100% ничего, учитывая количество вариаций разных проблем, которые могут в распределённой системе возникнуть)
но, рафт делает эти гарантии очень высокими

Понял

Ну, короче, мне кажется, что если в KeyDB нет жестокого отключения нод при развале 3 / 2 или 4 / 3, то наша проблема с split-brain вполне возможна

как раз вот я не просто так её советую, там хороший кластер с точки зрения реализации

поэтому я удивился, т.к. у меня много в проде под нагрузкой его

Короче, я схожу к тим лиду соседней команды и узнаю что там реально произошло

А пока ты здесь: а про Redis Streams что-нибудь слышал?

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

видел очереди задач на нём у китайцев

На нагрузке имеешь ввиду задержки из-за персистенции или кораптяться данные? А еще это как-то взаимодействует с кластеризацией?

не, просто не использовал на нагрузке

нет личного опыта

А, понял

Просто пробежался глазами и если это правда + есть нормальная поддержка кластера, то это то, что нужно:

– Redis Pub/Sub для none persistence + fire-and-forget
– Redis Streams для лог хранилища

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

redis проектировался изначально как In-memory storage, поэтому в таком кейсе стоит подумать, чтобы сделать слой между hot/cold хранением куда-то ещё, не думаю, что там оптимально в AOF это будет

Я надеюсь что персистенцию Stream они не на AOF сделали (вроде выглядит как отдельная пристройка), но надо посмотреть

я тоже, но учитывая сколько там лет 5 уже redis raft делает Antirez)

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

https://github.com/liftbridge-io/liftbridge вот твой любимый go посмотри)

https://github.com/hibiken/asynq тоже на go кстати

Господь всемогущий, еще и на Nats, ну все я готов продать свою мохнатую жопу за это

Ну job queue меня не удивишь (особенно на Redis), но go либам я доверяю больше, чем JS + выглядит реально симпотно, надо смотреть

было что-то ещё в закладках на го из такого популярненького, но не могу вспомнить, вроде kubemq тоже на go и там nats streaming

Больше всего в таких решениях у меня вопрос: и как там с аллокациями, господа

Если они норм смогли потоково сохранять на диск и не читаю в буфер отправлять на клиента по offset, то мое почтение, кажется, это рано или поздно попадет в наш продакшен

ну там у ребят большие амбиции были - https://github.com/liftbridge-io/liftbridge/issues/377

Вот такое пугает

это энтерпрайз поддержка, опенсорц под апач2

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

я когда-то следил и изучал каждый этот проект, но сейчас уже не уверен на сколько всё актуально

А, ну тогда норм

Я исключительно ЗА платить за технологии, но только если это четнастная оплата (за доп услугу)

И для меня это одна из главных причин не использовать CockroachDB – при всей ее крутости, закрывать CDC под лицензию, на мой взгляд, ублюдство

про CDC согласен, не самая энтерпрайз фича, я недавно узнал, что они настройки гео кластера вынесли из энтерпрайза, удивился)

То есть, гео теперь доступно без лицензии?

Хм, а кстати интересный вопрос: представим, что CDC доступен, стал бы ты делать очередь на Cockroach?

ну у меня была когда-то простая очередь задач на нём, я использовал лайфках 2 колоночные таблицы для задач и воркеров, и обычную таблицу с мета данными. Двухколоночные таблицы используют низкоуровневое kv api для работы с данными пропуская слой абстракции для преобразования в плоские данные, это работает достаточно быстро. Но это было скорее экспериментом, что так тоже работает и можно юзать)

ну не весь функционал, только вот этот https://www.cockroachlabs.com/docs/v23.1/create-table#create-a-table-in-a-multi-region-database

Для поддержки требований GDPR думаю открыли

Просто гипотетически:

- CDC дает fire-and-forget, но без эксклюзивности

- А пулл модель с локом («UPDATE … RETURNING”) с учетом гигантского кол-вы коннектов может сработать

Единственное, возможно, во 2-м подходе уровень консистентности убьет скорость в 0 или перегрузит CPU, тут сложно сказать

А ещё CDC может даже дать возможно использовать RPC… но это тоже экспериментаторство

Я просто мечтаю о БД, в которой будет возможность ещё реализовать EDA и RPC (я дрочу на асинхронные RPC с брокером как дискавери)

Для этого нужна атомарность в рамках query и subquery, множество коннектов, конкурентные локи на строки (чтобы транзакции на разные строки не мешали друг другу), быстрый batch delete (без глобального Vacuum), CDC ну и ещё некоторое кол-во условий, которые я на лету не придумаю

такой могла бы быть rethinkdb, но для node )

https://forum.cockroachlabs.com/t/how-to-implement-a-work-queue-without-skip-locked/3109/9 вот нашёл описание откуда я брал идею очереди и допиливал, тут хорошо описано

может тебе будет полезно с точки зрения паттерна, мне понравился лакончиный подход

Да да именно это, но на UPDATE, а не DELETE, потому что иначе Vacuum слишком часто будет триггерится

Это я из опыта PG говорю, на Cock не знаю так ли это будет

в 2 колонки всё как с kv + raft, нет издержек дополнительных

То есть и Delete, и Update оба сделают запись в raft лог и всё?

А индексы?

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

я бы очередь задач на такой бы архитектуре рассмотрел https://github.com/FireScroll/FireScroll

блин, а этот чел пошёл дальше https://github.com/danthegoodman1/icedb/blob/main/ARCHITECTURE.md интересные вещи делает
https://blog.danthegoodman.com/icedb-v3--third-times-the-charm

“serverless, multi-tenant, embedded data warehousing” - уфффф 🔥

То есть сам каталог файлов в формате Parquet хранится на S3, а процессинг Query происходит на серверлесс лямбдах…

Чувак увел в максимум концепцию разделения хранения и процессинга

Очень круто

Единственное, мне кажется до сих пор много проблем с организацией своего Serverless сервера

Из вариантов, которые я знаю, FaaS (но он жирный) и Firecracker, но его надо уметь готовить

Это я к тому что гигантское кол-во данных слишком сенситивный чтобы разворачивать люмбды на сторонних клаудах

И ответственно развернуть Clickhouse на своих серверах может быть все равно проще и дешевле

А ещё я задумался что это замечательная зона куда стоит расти Nomad, потому что он как раз про минимальный футпринт и запуск всего от контейнеров до бинарников

А ещё вместо S3 будет что-то типа своего Minio за которым тоже надо следить и тогда опять вопрос будет ли это лучше Clickhouse

у меня в серверлесс в последнем эксперименте ml-модельки на onnx и ничего норм)

В компаниях, в которых я работал, обычно не готовы были доверять даже криптографии, потому что +- если данные вскрываются можно было даже присесть (например, Мегафон)

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

сложно объяснять таким людям, что математические формулы нельзя обмануть, как и законы физики)

https://en.wikipedia.org/wiki/Zero-knowledge_proof есть просто факт математический

Погоди, а для чего именно cloudflare workers? Knative же должен спавнить и процессить лямбы или ты его для чего-то другого предлагаешь?

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

Чаще всего, был или необразованный, или слишком образованный безопасник, который говорил: "Храним только на этой железке, которая даже к интернету не подключена и точка"

Я видел на эту тему разработку: запускаешь node.js (WebKit / V8) runtime, все лямбды отправляешь туда как строчки, а потом делаешь условно "eval"

Так у тебя типа куча горячих runtime, которые запускают частные лямбды

Мне кажется это как раз про Cloudflare было

Вообще, смешно: по факту, такое можно из коробки сделать если писать на PHP )))

Наверное, и на Lua тоже

Да, я угадал https://developers.cloudflare.com/workers/learning/how-workers-works/

ООООООО ТАК ОНИ ЕЩЕ И В OPEN SOURCE ЕГО ВЫПУСТИЛИ

https://github.com/cloudflare/workerd