Парни, есть ли какой то инструмент для создания очереди на основе postgresql?

но зачем?

pgq

Я в свое время тыкал mbus

но зачем?

а почему нет? все инструменты очередей на самом деле так себе

https://wiki.postgresql.org/wiki/PGQ_Tutorial

Но чет все это так стремно выглядит.

Фанбои постгреса доставляют

Мы в итоге взяли RabbitMQ и не паримся

а почему нет? все инструменты очередей на самом деле так себе

чем рэббит плох?

кроме эрланга

Фанбои постгреса доставляют

Не фанбой, просто не хочу разводить зоопарк технологий.

Не фанбой, просто не хочу разводить зоопарк технологий.

Тот самый случай когда стоит добавить технологию.

чем рэббит плох?

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

За 3 года был только 1 network partition

Больше рпетензий нет

Тот самый случай когда стоит добавить технологию.

Быстрое изучение темы показало что postgres очень даже подходит для создания очереди, а т.к. основная БД postgres, то почему бы не воспользоваться этим?

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

рэббит монструозный? ну хз хз. а про претензии, так они к любой системе гуглятся :)

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

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

Быстрое изучение темы показало что postgres очень даже подходит для создания очереди, а т.к. основная БД postgres, то почему бы не воспользоваться этим?

Потому что чтобы из этой очереди читать "мгновернно" вам постоянно базу придется дрочить.

Блокирующего чтения в этих решениях нет.

рэббит монструозный? ну хз хз. а про претензии, так они к любой системе гуглятся :)

да монструозный.

Потому что чтобы из этой очереди читать "мгновернно" вам постоянно базу придется дрочить.

мой use case: один демон получает обновления из telegram bot API и пишет в очередь их, а второй эти обновления обрабатывает

А... ну так если это бот то можно и на простой таблице сделать.

Без всяких там pgq, mbus, rabbitmq и прочих.

/stat@comstatbot

comstatbot.xyz/chat/-1001030317489

/stat@comstatbot

comstatbot.xyz/chat/-1001030317489

Можно еще на редис листах очередь изобрести ))

А... ну так если это бот то можно и на простой таблице сделать.

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

Звучит как "Я собираюсь купить Oracle, на моем сайте будет 100 пользователей в сутки. Мне надо тратить 10миллионов на лицензию?"

Вообще да короче.

Звучит как "Я собираюсь купить Oracle, на моем сайте будет 100 пользователей в сутки. Мне надо тратить 10миллионов на лицензию?"

Возможно:)

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

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

Понял, спасибо!

Сейчас кстати вот думаю, как хорошо что мы в свое время выкинул на помойку поделие именуемое mbus. Потому что проектов стало 6 штук, все они связаны между собой через очереди. Т.е. в этом случае какой то проект стал бы "центровым" для mbus/pgq. Выносить в отдельную базу нет смысла, т.к. точно так же теряется транзакционность.

Тот самый случай когда стоит добавить технологию.

Что про nsq скажешь? Сетап проще, и без erlang (что и плюс, и минус)

Что про nsq скажешь? Сетап проще, и без erlang (что и плюс, и минус)

Прочитав первые строки из доки я бы сказал что это больше похоже на ZeroMQ.

Я на днях на пет-проекте поднял nsq, как-то полегче вышло, чем с RabbitMQ. Помню когда несколько лет назад rabbitmq поднимал, прямо гайд глубоко читал. А с nsq: докер, докер и в продакшн.

Не скажи, zeromq совсем другое же, там брокера нет, а у nsq брокер есть

disk persistance есть

> messages received are un-ordered

Спасибо, как нибудь без nsq обойдемся :)

Не скажи, zeromq совсем другое же, там брокера нет, а у nsq брокер есть

> horizontally scalable (**no brokers**, seamlessly add more nodes to the cluster)

Так есть брокер или нет?

А подскажите про dockerfile, правильно ли я понимаю, что писать EXPOSE нужно только для того, чтобы потом можно было запускать контейнер с опцией publish-all?

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

Что про nsq скажешь? Сетап проще, и без erlang (что и плюс, и минус)

Роутинга нет на сколько я вижу. Короче не годится для построения сложной шины сообщений.

Нет классического *централизованного* брокера. Но есть durability.

Нет классического *централизованного* брокера. Но есть durability.

Так а чем парируешь un-ordered messages и отсутствие роутинга как класс?

Могу только сделать выводу что rabbitmq и nsq для разных задач должны использоваться и сравнивать их не имеет смысла.

Роутинга нет на сколько я вижу. Короче не годится для построения сложной шины сообщений.

да хрен с ней с сложной. сложное вообще не нужно

да хрен с ней с сложной. сложное вообще не нужно

Даже простую не следаешь. Роутинга то нет!

Да, и правда, разные задачи. А с un-ordered delivery и delivery at least once можно работать. В Amazon SQS то же самое, кстати

Даже простую не следаешь. Роутинга то нет!

да с очередями в том и проблема - нет простой реализации. всё костыли какие-то

nsq для простого. Таймаут на обработку по дефолту 1 минута. Обработчики должны быть идемпотенты: если сообщение пришло дважды, то должно либо заигнориться, либо отработать без багов. Сообщения должны быть независимы: например crawling разных страниц.

А вообще всё это — проблемы distributed mindset. Часто проще забить на всю эту муть и сделать на раббите или другой MQ с упором на 1 мастер, где нет таких заморочек.

Хотел построить топологию нашего RabbitMQ кластера, но у меня визуалайзер повис

Интересно ?

Ну точнее, он тупил-тупил и нарисовал все встолбик что ничего не понятно.

В общем, у нас на данный момент 50 очередей (проектных), 7 проектных exchange'ей, и один глобальный. Если нужна меж-проектная коммуникация то сообщение паблишится в глобальный exchange, дальше летит во все 7 локальных. У каждого проекта свой локальный exchange. Далее сообщение может еще больше раз "расщепиться" и улететь в локальные очереди. Но все так сделано, что каждый проект дефайнит только свой локальный exchange, и свои локальные очереди + биндинги-роутинг - имена событий. Когда во всех проектах запустить конигуратор очередей то получится единая картинка мира так сказать.

ERROR: S client not available

Я пока не знаю что может при таких раскладах заменить RabbitMQ.

Причем, у нас кластер из 3 нод, по 2 проекта на ноду. Поэтому все это дело очень удобно мейнтейнить. Если надо 3ю ноду пгасить - то сначала деплоим реконфигурацию, потом уводим ее в даун.

HA политики настроены на реплецирования все по всем нодам.

Ого, Rabbit HA :) Все в одном ДЦ?

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

Да, но мы не кросс-дц, так что.

Просто ноды Rabbit'а разнесены по разным физическим серверам.

Опять же, говорю, один раз был network partition за 3 года.

Пришлось поебаться, потому что ноду такую в кластер уже не вернуть никак.

Всем добрый вечер! Прошу прощения, что врываюсь с работой сюда В открытый мессенджер Actor (https://github.com/actorapp/actor-platform) ищем опытного DEVOPS поддерживать наш континиус деливери всех трех платформ, любить тимсити, фабрик... ну вы поняли, стандартный набор. Так–то у нас уже все настроено и работает, но поддерживать это некому, так что нужен самостоятельный, знающий и инициативный человек. У нас адекватная команда, интересные задачи, ЗП на уровне. Офис находится в Петербурге, возможна удаленка. Пишите, если интересно. Еще раз прошу прощения за disturbance.

Прошу прощения за дистурбанс.

скажите а в ансибле есть вариант тега "never" ? что бы он был строго ручной ? или я хочу совсем странного ?

Есть наоборот - always :)

это я как раз знаю :)

Ну так запили им never

я думаю на сколько логично добавить тесты в плейбук.

Думаю что будет пара строк копипасты от always :)

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

У нас сделать проще.

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

Стразу видно если кто то какое-то говно закоммитил на след утро.

сделано*

у меня не совсе мтакой кейс

у меня "инсталятор" на базе ансибла

тоесть анчальное конфигурирование системы через него. и штуки типа "state=running" могут просто не пройти

ибо сервис может быть раннинг с точки зрения systemd но нифига не раннинг на самом деле.

Так там же есть штуки типа "ждать сервис пока не появится онлайн"

Можно порт слушать (т.е. ждать)

Типа пока сервис не раздуплится на самом деле.

ну вот я и думаю как всё такие шутки поскладывать в одно место.