[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Дубли в очереди
Страницы: 1, 2
T1grOK
Цитата (Arh @ 16.04.2017 - 08:09)
просто RabbitMQ не ассоциативный

Это не его забота. При формировании задачи на продюсере можно вложить в задачу все, что угодно, а на консюмере сопоставить эти данные с чем то другим, вот и ассоциация.
Цитата (Arh @ 16.04.2017 - 08:09)
есть ли аналоги, у которых это предусмотрено из коробки

Разве что Kafka из экосистемы Hadoop, в нем на уровне драйвера очереди многие вещи реализованы, от которых RabbitMQ далек.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api
Arh
T1grOK
Цитата
Это не его забота.

Можно так сказать, а можно сказать что он это не умеет, суть не меняется.
Цитата
Разве что Kafka из экосистемы Hadoop, в нем на уровне драйвера очереди многие вещи реализованы, от которых RabbitMQ далек.

Во

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
Ron
Смотри, ты хочешь создать блокировку очереди по какому-то признаку, в данном случае по ключу, через Redis. От этого эффекта будет мало, когда консьюмер берет задачу в обработку, он должен сначала удалить запись из Redis, а потом приступить к выполнению задания. Если он это будет делать после, то заблокированная во время выполнения очередь может стать причиной потери данных. Кэш начнет рушиться, клиенты воспримут как жуткие глюки, и что их данные пропали. =( Таким образом, твой подход эффективен только в случае разрастания очереди, чем она больше, тем эффективнее. То есть максимальная эффективнось в режиме (pre)failure.

Следить за кэшом (очередью) нужно на продюсере, или на проксе между кроликом и продюссерами, что далеко не простая задача, учитывая спицифику данных. Эффективный механизм инвалидации. Вот чего тебе не хватает.

Тут правильно говорят, не нужно городить черт знает чего. Кэширование страниц - не лучшая затея, тебе уж раз об этом намекнули. =) И сантехник говорит очень умные вещи!
Arh
Santehnick
Цитата
Дубли задач возникают, потому что в базе хранится состояние и кажется, что rabbitmq чего-то не умеет. Но если архитектуру сайта построить на event sourcing, то в базе будут храниться события, а не состояние. И окажется, что дублей нет. Так что это не проблема сервера очередей.

При чём тут база вообще?
Неважно от кого поступает задача, не важно что конкретно делает обработчик, просто через консоль добавили, в другой консоле увидели сообщение, проблема в другом.
У RabbitMQ есть список задач, если добавить туда такую же, то в очереди будет дубль.
Есть ли у RabbitMQ функционал, который не позволяет дублировать уже существующие задачи? Нет. Что это значит? Что он не умеет.
А надо что бы умел, так может есть VasyaMQ который умеет?

Цитата
Все решения, которые ты хочешь сделать - это костыли. Костыли всегда отваливаются. И они отвалятся, например при рефакторинге сайта на event sourcing.

По такой логике любой код костыль и любой код всегда отваливается.

Цитата
Динамический блок входа на nginx, это не тот слой, где это нужно делать. Кластер на котором крутится сайт, может быть неоднородный, где-то будет nginx, где-то другой веб-сервер. Разработчик может использовать встроенный php веб-сервер и у него ничего не будет работать. Функциональные тесты не будут работать без nginx. Новый разработчик вместо того, чтобы писать код, будет тратить время на выяснение почему ничего не работает в его окружении. Ужасное решение.

А ещё может быть что сервер работает на php, а разработчик разрабатывает на python, а ещё ему сказали делать интернет магазин, а он начал играть в марио на денди. Ужасный разработчик.

Цитата
Никто такое ломкое решение делать не будет. Все сделают по другому. Закешируют данные. А если php стал узким местом, значит пришло время поставить 2 бекенд-сервер. Такой объем трафика еще заслужить надо.

Всё уже работает несколько лет, хватит фантазировать.
Я бы сделал по другому, но всё уже сделано. Бэкенд писал не я, а уважаемые, известные зарубежные люди, вот только их говнокод и пары тысяч онлайна не выдержит, а мне нужно быть готовым к скачкам до 100 тысяч.
Можно конечно сделать всё динамикой, размазать по миллиону серверов, костылями другого уровня кстати заметь. Но у меня только пара серверов и один не подключенный балансировщик. Да и тема не про это, холиварщики)

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

Чем она будет заблокирована? Обработчики как обрабатывали, так и буду обрабатывать задачи. Постановщик задач будет добавлять только те задачи, которых ещё нет в очереди.

Цитата
Следить за кэшом (очередью) нужно на продюсере, или на проксе между кроликом и продюссерами, что далеко не простая задача.

Ну так я это и предлагаю в отличие от остальных. Задача проще некуда.

Цитата
Эффективный механизм инвалидации. Вот чего тебе не хватает.

Что ты подразумеваешь под "эффективный"? Можно подробнее? А то так можно про всё сказать) "проект, который не падает - вот что тебе нужно"
Ну а вообще инвалидация есть, но это подходит только для старых статей, что бы не хранить в кеше пол терабайта страниц, на которые никто давно уже не заходит. А вот для страниц на которых под 50,000 онлайна может зайти это критично, потому что они все разом проваляться на бэк.

Цитата
Тут правильно говорят, не нужно городить черт знает чего. Кэширование страниц - не лучшая затея, тебе уж раз об этом намекнули. =) И сантехник говорит очень умные вещи!

Ну хз, разве что слова по отдельности умные, но в целом ощущение что они учат тому, в чём даже не пачкались.

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

Можно и так, но по идее он должен попробовать выполнить задание, а потом сказать справился или нет, хотя существует ненулевая вероятность, что за то время, пока он обновлял кеш, страницу обновили ещё раз. Согласен, лучше перед обновлением удалить.

Подытожу.

Arh: Есть аналог RabbitMQ?
T1grOK: Разве что Kafka
Santehnick: Нету
Arh: ок, всем спасибо

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.