Обзор системы очереди задач

Question

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

Элементы следует обрабатывать более или менее по порядку - в идеале элемент A будет добавлен в систему, а рецензенты 1,2 и 3 рассмотрят его и будут возвращены пользователю. Затем элемент B добавляется в систему, рецензенты 2,5,1 просматривают его и т. Д. Конечно, поскольку рецензенты могут работать одновременно, и есть более трех рецензентов, система должна поддерживать несколько элементов, рассмотренных одновременно (разными рецензентами, конечно).

Я не уверен, как реализовать репозиторий элементов данных. Требования:

• Элементы добавлены несколькими авторами.
• Каждый предмет читается 3 различными читателями.
• Когда читатель берет предмет, он должен взять первый элемент, который читатель не видел первым.

Я могу реализовать все это с использованием базы данных SQL, но он не будет масштабироваться очень хорошо.

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

Answer 1

Учитывая, что базы данных SQL лежат в основе многих систем масштаба предприятия, я не вижу оснований для утверждения «он не будет очень хорошо масштабироваться». Это правда, что крупномасштабные корпоративные системы выигрывают от выделенных систем очередей, но эти системы имеют дело, например, со всеми транзакциями, которые будут обрабатываться в день розничными банками. Я скептически отношусь к тому, что у вас может быть так много предметов, которые нужно пересмотреть, и так много параллельных обозревателей, что это требование будет подчеркивать стандартную базу данных SQL - 6000 рецензентов, обрабатывающих 60 предметов в час, дадут всего несколько сотен tps. Конечно, я догадываюсь о масштабах ваших требований, поэтому было бы интересно услышать, что они собой представляют.

Однако я вижу концептуальные достоинства реализации этого как набора очередей, а главное требование - «дать мне следующий элемент из этой очереди, который я еще не просмотрел».

Селектора JMS позволяют выбирать записи на основе содержимого поля заголовка, поэтому добавление полей заголовка Reviewer1 и Reviewer2 в ваше сообщение должно обеспечивать эффективный выбор следующего доступного элемента. Поэтому я бы предположил, что любой системы массового обслуживания, совместимой с JMS, будет достаточно.