Возможно, у меня неправильное мышление при подходе к системе очередей с Redis, поэтому мне нужна помощь ваших ребят.
Итак, у меня есть эта довольно простая очередь, отвечающая за укладку электронных писем в одну коллекцию, а затем за получение доступных электронных писем из стека и их отправку.
Система построена на NodeJS, поэтому я использую для этого библиотеку node-redis.
Очередь (стек) должна быть постоянно доступна: одна точка добавляет (отправляет) новые электронные письма поверх нее, а другой конец извлекает первый отправленный элемент.
При таком подходе я, возможно, думаю, что слишком похоже на Javascript, и то, что я нашел в документации Redis, может не подойти, поэтому здесь я обращаюсь к вам, ребята, чтобы помочь мне приобрести правильное мышление при разговоре на языке Redis.
Используя простой пример, в JSON, вот мой стек очереди:
queue = [
{
_id: 5a05eec08a7e66eb10ad6361,
email: "some html content in here",
domain: "domain.com"
},
{
_id: 5a05eb785710017b7d7a0243,
email: "some more html content here",
domain: "domain.com"
},
...
]
Изучив документацию Redis, я обнаружил, что могу поместить каждое электронное письмо в стек, выполнив что-то вроде этого:
HMSET queue:5a05eec08a7e66eb10ad6361 email "some html content in here" domain "domain.com"
HMSET queue:5a05eb785710017b7d7a0243 email "some more html content here" domain "domain.com"
И я мог бы явно получить одну «коллекцию» следующим образом:
HMGET queue:5a05eec08a7e66eb10ad6361 email
HMGET queue:5a05eec08a7e66eb10ad6361 domain
HMGET queue:5a05eb785710017b7d7a0243 email
HMGET queue:5a05eb785710017b7d7a0243 domain
До этого момента все довольно ванильно. Но проблема в том, что когда дело доходит до одной системы очередей, нужно действительно использовать функции PUSH и POP, которые предоставляет вам язык/база данных.
Я действительно смог найти механизмы PUSH и POP, которые выдает Redis, но я мог использовать их только при работе с одномерными KEY.
Итак, в моем случае вместо того, чтобы выводить один элемент, например:
RPOP email
Мне действительно нужно что-то вроде этого:
RPOP queue //see the abstraction here? calling the stack and not a single item?
В свою очередь вернул бы мне - и в то же время удалил - последний элемент в этой коллекции очереди.
So,
RPOP queue //or whatever other command I couldn't find
Должен дать мне
{
_id: 5a05eec08a7e66eb10ad6361,
email: "some html content in here",
domain: "domain.com"
}
... а потом с другим
RPOP queue
Вернись ко мне
{
_id: 5a05eb785710017b7d7a0243,
email: "some more html content here",
domain: "domain.com"
}
И так один, пока не опустошит эту "очередь".
Надеюсь, я ясно изложил свое мышление, а также саму проблему.
Я не могу повторять код с помощью механизма HMGET, потому что, как и в любой очереди, в то время как один конец может выталкивать элементы снизу, другой конец может укладывать новые элементы поверх него. Таким образом, сохранение с помощью кодирования некоторого механизма «переиндексации» было бы слишком большим хаком.
К этому моменту я начинаю верить, что Redis не предлагает мне необходимых инструментов для поддержки этого «многомерного» подхода к стеку. Имхо, это нормально, Redis может не быть ответом на то, что мне нужно.
Но я знаю, что в настоящее время у меня может быть неправильное мышление, и, вероятно, Redis предлагает элегантный способ справиться с этим, но с совершенно другим подходом. Я не мог просто заставить его работать с RPUSH и LPOP, поскольку, как я уже упоминал, он предлагает мне только способ работы с простыми одномерными KEY VALUE.
На случай, если Redis не поддерживает это, я уже реализовал один обходной путь в конечной точке NodeJS. Но вы знаете, больше кода означает больше потенциальных ошибок.
Мир