T1grOK
16.04.2017 - 12:39
Цитата (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
T1grOK
Цитата |
Это не его забота. |
Можно так сказать, а можно сказать что он это не умеет, суть не меняется.
Цитата |
Разве что Kafka из экосистемы Hadoop, в нем на уровне драйвера очереди многие вещи реализованы, от которых RabbitMQ далек. |
Во
_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
Смотри, ты хочешь создать блокировку очереди по какому-то признаку, в данном случае по ключу, через Redis. От этого эффекта будет мало, когда консьюмер берет задачу в обработку, он должен сначала удалить запись из Redis, а потом приступить к выполнению задания. Если он это будет делать после, то заблокированная во время выполнения очередь может стать причиной потери данных. Кэш начнет рушиться, клиенты воспримут как жуткие глюки, и что их данные пропали. =( Таким образом, твой подход эффективен только в случае разрастания очереди, чем она больше, тем эффективнее. То есть максимальная эффективнось в режиме (pre)failure.
Следить за кэшом (очередью) нужно на продюсере, или на проксе между кроликом и продюссерами, что далеко не простая задача, учитывая спицифику данных. Эффективный механизм инвалидации. Вот чего тебе не хватает.
Тут правильно говорят, не нужно городить черт знает чего. Кэширование страниц - не лучшая затея, тебе уж раз об этом намекнули. =) И сантехник говорит очень умные вещи!
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