Очередь с использованием таблицы - PullRequest
Новая
       37

Очередь с использованием таблицы

4 голосов
/ 11 ноября 2008

Мне нужно реализовать очередь, используя таблицу. Бизнес-требование состоит в том, чтобы иметь единственную очередь, к которой будут обращаться 5-10 блоков, чтобы получить следующую работу / рабочие места. Там не будет более 5000 рабочих мест в день. Кроме того, пакет заданий должен быть «снят с производства» за один раз.

Просто интересно, с какими проблемными областями и проблемами я могу столкнуться, поскольку я не делал этого раньше. Если кто-то сталкивался с этим / сделал это раньше, не могли бы вы указать мне на реализацию / пример реализации или проблемы, о которых нужно позаботиться.

Спасибо

Ответы [ 4 ]

3 голосов
/ 11 ноября 2008

Существует множество общих служб очередей или обмена сообщениями. Даже если вы хотите внедрить свою собственную систему, вы можете попробовать взглянуть на несколько других. Первое, что приходит на ум - это JMS ( Java Message Service ) с такими реализациями, как Apache ActiveMQ , OpenJMS или JBoss Messaging . Тогда у вас также будет много предложений не с открытым исходным кодом.

Второе, что приходит на ум, это Amazon Simple Queue Service . Существует пара продуктов, которые реализуют интерфейс такого же типа, например django-queue-service .

Удачи!

2 голосов
/ 11 ноября 2008

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

При получении заданий это так же просто, как поместить операторы SELECT и DELETE в транзакцию. Если вы чувствуете, что это неудобно, что-то вроде этого может сделать это: 

UPDATE tblQueue SET mark = <unique application id> WHERE mark IS NULL ORDER BY timestamp ASC LIMIT 1
SELECT * FROM tblQueue WHERE mark = <unique app id>
DELETE FROM tblQueue WHERE mark = <unique app id>

Используя эту настройку, вы можете избежать транзакций, если они вас пугают.

Ваше определение партии несколько неясно; если вы просто имеете в виду, что я могу обрабатывать 10 элементов одновременно, просто измените предложение LIMIT 1 первого запроса на LIMIT 10.

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

2 голосов
/ 11 ноября 2008

Проблемные зоны:

  • параллелизм
  • Безопасность
  • Скорость
  • Кодирование
  • 1012 * единственность *

И, конечно, этот:

  • Неясная спецификация проблемной области

Удачного кодирования!

0 голосов
/ 11 ноября 2008

Спасибо, Вегард.

Но предложенный вами подход приведет к потере запросов на работу в случае сбоя / сбоя системы, которая получила работу.

Я думал о таблице очередей со следующими столбцами

  • RequestID / MessageID (первичный ключ)
  • LockedBy (кто работает по запросу)
  • LockedTime (когда запрос заблокирован для обработки)
  • RequestedTime (когда запрос добавляется в очередь)
  • CompletionTime (когда запрос завершен)
  • Статус (Ожидание / Обработано)
  • RequestMessage (сериализованный Java-объект в моем случае)
  • Запросчик (который поставил в очередь запрос)

Я могу написать хранимую процедуру [GetNextItemsInQueue], которая возвращает список, скажем, 10 запросов, устанавливает время блокировки и время блокировки. Если заблокированное время увеличивает указанный лимит, запись может быть возвращена в состояние ожидания.

Есть проблемы с этим?

...