Прямо сейчас:
- Приложение # 1 для вставки сообщений в SQS
- Рабочая роль .Net опрашивает очередь, и если найденное сообщение отправляет его в приложение № 2 для обработки, подождите, пока приложение № 2 завершит свою работу, и перезапустите опрос очереди
- Приложение № 2 обрабатывает сообщение, которое является долгой и тяжелой задачей
Поскольку приложению № 2 может потребоваться довольно много времени для обработки сообщений, и я не могу предсказать, сколько сообщений отправляется одновременно из приложения № 1, система очередей гарантирует мне, что в приложении № 2 не заканчиваются ресурсы, и система может масштабировать довольно легко. Но есть проблема, которую я хотел бы решить: я бы предпочел, чтобы у меня не было машины для выполнения рабочей роли (теперь в Azure), просто чтобы опрашивать очередь (все размещено в другом месте, где рабочая роль недоступна). Более того, опрос никогда не будет таким отзывчивым, как пуш, из-за пауз между опросами.
Переход от опроса к push-звуку - правильный путь, но мне нужно сохранить гарантию, что даже если 1к-сообщения отправляются из приложения № 1 за одну секунду, приложение № 2 обрабатывает их одно за другим и не попадает 1 раз в секунду.
Я планировал проект, в котором приложение № 1 публикуется в теме SNS, подписчиками которой являются SQS и приложение № 2. Приложение № 2 проверяет очередь SQS и, если она пуста, закрывается, если не обрабатывает сообщения одно за другим, а затем завершает работу. Но как я могу кодировать приложение № 2 (прямо сейчас .Net / веб-сервис .Net), чтобы, если оно уже обрабатывает сообщение и получает уведомление от SNS, оно ничего не делает и завершает работу (если не будет выполнена множественная обработка).
Есть предложения, как это оформить? Я прочитал это сообщение в блоге , но я не знаю, как избежать обработки приложением для обработки нескольких сообщений одновременно.