Я создаю систему, которая генерирует «рабочие элементы», которые ставятся в очередь для внутренней обработки. Недавно я завершил разработку системы, которая соответствовала тем же требованиям, и разработал архитектуру, которая, на мой взгляд, не является оптимальной, и надеялся получить несколько советов для этой новой системы.
Рабочие элементы помещаются в очередь централизованно и должны обрабатываться в основном порядке FIFO. Если бы это было единственным требованием, то я бы предпочел решение MSMQ или SQL Server Service Broker. Однако в действительности мне нужно выбирать рабочие элементы в измененном порядке FIFO. Рабочий элемент имеет несколько атрибутов, и их необходимо назначать в порядке FIFO, где существуют определенные комбинации значений атрибутов.
Например, рабочий элемент может иметь следующие атрибуты: Офис, Приоритет, Номер группы и Порядковый номер (внутри группы). Когда несколько элементов стоят в очереди для одного и того же номера группы, они гарантированно будут поставлены в очередь в порядке порядкового номера и будут иметь одинаковый приоритет.
Существует несколько внутренних процессов (в настоящее время реализованных как службы Windows), которые обрабатывают время работы в измененном порядке FIFO с учетом определенных параметров конфигурации для данной службы. Служба, работающая в Вашингтоне, округ Колумбия, настроена на обработку только рабочих элементов для DC, в то время как служба в Нью-Йорке может быть настроена на обработку элементов как в Нью-Йорке, так и в округе Колумбия (в основном для увеличения общей пропускной способности). В дополнение к этому типу избирательности, элементы с более высоким приоритетом должны обрабатываться в первую очередь, а элементы, содержащие одинаковый «номер группы», должны обрабатываться в порядке порядкового номера. Поэтому, если служба NY работает с элементом DC в группе 100 с последовательностью 1, я не хочу, чтобы служба DC выполняла элемент DC в группе 100 с последовательностью 2, поскольку последовательность 1 еще не завершена. Элементы в других группах должны оставаться пригодными для обработки.
В последней системе я реализовал очереди с таблицами SQL. Я создал хранимые процедуры для отправки элементов и, что более важно, для «назначения» элементов службам Windows, которые отвечали за их обработку. Хранимые процедуры назначения содержат логику выбора, описанную выше. Каждая служба Windows будет вызывать хранимую процедуру назначения, передавая ей параметры, которые являются уникальными для этого экземпляра службы (например, соответствующие офисы). Эта хранимая процедура назначения помечает рабочий элемент как назначенный (в процессе), и когда работа завершается, вызывается окончательная хранимая процедура для удаления элемента из «очереди» (таблицы).
Это решение имеет некоторые преимущества в том, что я могу быстро изучить состояние этих «очередей» с помощью простого оператора SQL select. Я также могу легко манипулировать очередями (например, я могу увеличивать приоритеты с помощью простого оператора обновления SQL). Однако, с другой стороны, мне иногда приходится иметь дело с тупиковыми ситуациями в этих таблицах очередей, и мне приходится писать эти хранимые процедуры (что через некоторое время становится утомительным).
Почему-то я думаю, что либо MSMQ (с WCS или без него), либо Service Broker должны быть в состоянии предоставить более элегантное решение. Работать с моей собственной системой очередей / обработки рабочих элементов просто нехорошо. Но, насколько я знаю, эти технологии не обеспечивают той гибкости, которая мне нужна в процессе назначения. Я надеюсь, что я не прав. Любой совет приветствуется.