💭П
Десяток :-)
Size: a a a
2019 November 09
A
Десяток :-)
4386 если кокретно
SS
Новый положняк: celery не нужен, делаем pubsub через Postgres https://layerci.com/blog/postgres-is-the-answer/
NK
Новый положняк: celery не нужен, делаем pubsub через Postgres https://layerci.com/blog/postgres-is-the-answer/
Бартунов вчера про это ничего не говорил
SS
Вообще, надо в постгрес встроить js движок и все приложения делать прямо в нём
SS
Будет как тарантул только не распределеный
AM
Вообще, надо в постгрес встроить js движок и все приложения делать прямо в нём
Не, надо смержить nginx и postgresql давно уже.
KK
Новый положняк: celery не нужен, делаем pubsub через Postgres https://layerci.com/blog/postgres-is-the-answer/
Уже есть в интернетах старая статья почему RBD совсем не подходят на роль производительных очередей вроде RabbitMQ.
Они просто начнут дико тормозить с ростом числа воркеров, которые начнут запускать свои транзакции для обработки задачек, и эти транзакции будут лочить друг-друга.
И вот это повеселило в статье:
Они просто начнут дико тормозить с ростом числа воркеров, которые начнут запускать свои транзакции для обработки задачек, и эти транзакции будут лочить друг-друга.
И вот это повеселило в статье:
As a database, Postgres has very good persistence guarantees - It's easy to query "dead" jobs with, e.g., SELECT * FROM ci_jobs WHERE status='initializing' AND NOW() - status_change_time > '1 hour'::interval to handle workers crashing or hanging.Только одного этого достаточно, что бы не делать из RDB замену нормальным реализациям очередей, которые могут отследить "дисконект" клиента и вернуть "задачку" в очередь.
KK
Как и раньше, когда Celery умел базы данных в роли брокера, такое решение может подойти для простейших случаев с не очень большой нагрузкой, и конечно же без горизонтального масштабирования и нормального HA.
RH
А можешь найти эту статью? Со скольки воркеров могут начаться проблемы? У меня похожая схема, только без pg_notify. На 50 воркерах точно все нормально
KK
Ну та статья конечно не учитывала что есть такая штука как pg_notify. Но в целом то что транзакции могут лочить друг друга - это по прежнему остаётся.
KK
И вот этот "поиск умерших задачек" вообще будет не просто реализовать нормально. В статье он проверяет только статус initializing, а есть ещё ведь running. Воркер мог начать выполнять задачку и потом умереть, и она будет висть в статусе running
RH
Про running такими же запросами решается, причем у разных задач будут разные тайм-ауты, и например рассчитываться для конкретных операций, например от объема передаваемых данных. Вряд-ли цель статьи показать полное решение
KK
Все эти таймауты очень сложно считать и поддерживать. "Плавали, знаем".
У нас с распределёнными локами регулярно подобные косяки вылазят, когда процесс помер, лок остался висеть и другой процесс не может его взять. А задачка исходная долго выполняющаяся. Более менее работающий вариант - ставить лок на мелкий таймаут и хера-битить его в треде.
Гораздо проще и надёжнее, когда тот же RabbitMQ видит что клиент отвалился, и возвращает сообщение в очередь.
У нас с распределёнными локами регулярно подобные косяки вылазят, когда процесс помер, лок остался висеть и другой процесс не может его взять. А задачка исходная долго выполняющаяся. Более менее работающий вариант - ставить лок на мелкий таймаут и хера-битить его в треде.
Гораздо проще и надёжнее, когда тот же RabbitMQ видит что клиент отвалился, и возвращает сообщение в очередь.
RH
Когда есть внешние сервисы, все равно приходится эти проблемы решать. Т.е. пришла задача, начали ее выполняиь, сделали что-то подготовительнле, отправили запрос во внешний сервис, там началась операция. Такую задачу нельзя будет просто переложить обратно в очередь, если во внешнем сервисе что-то пойдет не так
KK
Ну это уже другое дело - тут надо сохранять в отдельной базе ID задачки в другом сервисе, что бы при повторном запуске проверить что он не пустой и запросить результат из внешнего сервиса.
RH
Отсюда и получаются задачи в бд со статусами и тайм-аутами
KK
Ну это уже другое - не всегда же есть внешняя система с со своей очередью задач. Хотя и тут можно выкрутится - отправил запрос во внешнюю систему, отправил в очередь задачку с ID от внешнего сервиса, что бы она результат получила (или заретраила себя, если его нет).
KK
Нам отдельная база обычно бывает нужна, когда надо обеспечить последовательность выполнения задач в условиях, когда одновременно можно выполнять только одну.
2019 November 10
A
Я себе недавно уши искал беспроводные, причём чтобы работало на линуксе тоже. Дома я юзаю наушники от PlayStation, они с отдельным свистком идут и на убунте нормально работают. На работу купил steelseries arctis, тоже игровые. С линуксом работают, и на радиоканале - достаёт до туалета и переговорок, очень удобно, выглядят классно.
Jbl на блютусе. Работают с убунтой из коробки и без приседаний. До туалета тоже добивают.