Есть что то типа RabbitMQ, только с уникальными ключами?

Суть проблемы RabbitMQ:
Представим сайт с новостями, допустим хабрахабр.
Допустим он весь полностью кешируется.
Кешируется не по запросу пользователя, а программно.
Примерно так:
Пользователь добавил статью, страница добавилась в очередь на создание кеша.
Но по мимо страницы статьи также добавилась главная страница, страница с последними статьями, страница с разделом статьи, да и вообще все страницы, на которых она как то упоминается. В итоге допустим 5 уникальных страниц в очереди на добавление в кеш.

Теперь второй и третий и десятый пользователи тоже добавили статью в тот же раздел.
В очередь добавились ещё 10 страниц разных статей, 10 раз главная страница, 10 раз раздел, 10 раз страница с последними статьями и т.д.
В итоге в очереди вместо допустим 13 уникальных заданий, будет 50 дублей. (такая псевдо-математика)

С ходу видно два решения:
1) Делать всё на редисе. Туда нельзя записать больше одного элемента с одинаковым ключом, это как ассоциативный массив.
Но на него не повесить больше одного обработчика. Конечно если 50 дублей обрабатывают 5 обработчиков, то с 13 уникальными и один справится, но в случае чего это не расширить.
Есть вариант вешать каждый обработчик на свою маску ключа, типа один обрабатывает задачи по обновлению главной, другой страницы типа /page/*, третий третье. Но вдруг придут 50 пользователей и добавят 50 /page/* =)

2) Скрестить RabbitMQ и Redis.
При добавлении нового задания проверяется нет ли уже такого в Redis, если нет, в Redis добавляется ключ, а в RabbitMQ задача.
Когда RabbitMQ выполнит эту задачу, он удалит её из Redis.


В общем обожаю изобретать) Но скорее всего есть что то готовое? <- красным выделена суть вопроса

Что бы всю тему не читать:

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

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

Arh, Проблемы нет. Просто нужно обрабатывать все дубликаты в логике, а не на стороне транспорта сообщений.

Гость_chee
Есть проблема - дубли.

Arh, ты не правильно понял мои слова. Я имел ввиду что не на уровне radis не на уровне rabbitmq не надо решать проблему дублирования сообщений, это нужно делать непосредственно в консьюмере. Консьюмер должен проверять сообщение, было ли подобное сообщение обработано другим или этим же консьюмером.

Если сообщение уже было обработано другим консьюмером, говорить очереди что сообщение обработано, но по факту ничего не делать.

Гость_chee

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

Гость_chee

Можно хранить в Redis счетчики, а на консюмере сравнивать значение счетчика из задачи и из Redis, тем самым будет обеспечено выполнение наиболее новой задачи. А на случай, если пользователи начнут долго и непрерывно, что-то добавлять, можно установить некоторый таймаут(время последнего выполнения, которое храним рядом с каждым счетчиком), при котором задание будет выполнено несмотря на значения счетчиков.

P.S. В целом, по теме, сложилось впечатление преждевременной оптимизации.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

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

T1grOK