RESTful-сервис: как реализовать выборку новых сообщений?
Создаю приложение на Java (с помощью Jersey), которое представляет собой что-то вроде социалки. Делаю больше для собственного развития, чем с какой-то целью.
Вопрос в следующем. Я хочу добавить возможность выборки новых сообщений с момента последнего визита пользователя. Дата последнего захода сохраняется в профиле, но проблема в следующем: я хочу, чтобы новые сообщения оставались в списке новых, пока пользователь их не прочитает. Т.е. нельзя просто отдавать сообщения, появившиеся после последнего захода.
Понятно, что можно селать отдельные таблицы и хранить там эти сообщения (вернее, ссылки на них), пока пользователь их не прочитает, но хотелось бы хранить это состояние на клиенте.
Вроде, задача довольно стандартная, но как-то ничего не могу придумать, а как спросить у гугла тоже не придумал. М.б. есть готовая идея.
> А на rabbitmq nосмотреть не хотите?
А как он может помочь в данном случае? Если честно, не особо с ним знаком.
> На каждого клиента заводится очередь, из которой он черпает сообщения. Вариантов масса.
Ну да, собственно, такие варианты примерно и приходят на ум.
Но я думал, например, сделать что-то вроде такого: на клиенте хранятся id всех новых сообщений, которые он не читал и при запросе страницы новых сообщений он (клиент) отдает этот список и получает по этим ID сообщения. Ну а, когда он прочитывает какое-то из них, оно удаляется из локальной очереди. Или это плохая идея? Просто при этом не нужно на сервере для каждого клиента заводить очередь.
Алексей Черемисин: нет, тут не о очередях, тут о механизме различия прочитанных и не прочитанных сообщений по аналогии с сообщениями в чатиках. Либо я вас не понял, решить эту задачу на очередях конечно можно но тогда кролик из менеджера очередей превратится в хранилище данных, что как минимум не правильно. Да и заводить по очереди на каждого пользователя как-то сильно напряжно.
Toster100: собственно rabbitmq примерно так и работает, только очередь клинта хранится на сервере, каждое сообщение можно подтверждать, можно делать коллективные очереди, списки подписок, разные таймауты на хранение сообщений, приоритеты, очереди ошибок и все вот это. Клиенту в этом случае ничего хранить не нужно. Просто почитайте введение в rabbitmq. Ну и аналогичную функциональность, в сильно урезанном варианте можно получить на основе redis. Он правда больше заточен как бооольшое хранилище ключ-значение, типа распределенного hashtable, но в нем есть и очереди, сильно урезанные и быстрые. Да, если очередь сообщений должна жить между перезапусками сервера, то ориентируйтесь сразу на раббит.
