У вас может быть столько читателей, сколько вам нужно.Очень распространено масштабирование экземпляров рабочих ролей, поскольку все они могут читать из одной и той же очереди, что значительно увеличивает пропускную способность работы.
Когда вы читаете сообщение очереди, оно помечается как «невидимое» в течение определенного периода времени., чтобы другие не читали и не делали ту же работу.Владелец сообщения должен удалить его до истечения периода времени, в противном случае сообщение снова станет видимым, и будет выдано исключение, когда исходный читатель попытается удалить его.Это означает, что ваши операции должны быть идемпотентными.
Нет прямой обработки ядовитых сообщений, но ее легко реализовать, поскольку каждое сообщение имеет счетчик очереди.Просто проверьте это и удалите вредоносные сообщения после прочтения 3-4 раза.Вы также можете динамически регулировать период ожидания, основываясь на счетчике очереди, поскольку, возможно, обработка завершается неудачно из-за слишком короткого временного окна.
* Документация MSDN для
DequeueCount.
РЕДАКТИРОВАТЬ: что касается обработки 11 000 сообщений за 3 минуты: целевое значение масштабируемости для очередей составляет 500 2000 TPS, или до 360 000 транзакций за 3 минуты (намного больше, чем требуется для 11 000 сообщений),Вы можете еще больше ускорить процесс, объединив сообщения в одно сообщение очереди, а также прочитав несколько сообщений одновременно, что также уменьшит количество транзакций.Вы также можете просмотреть свойство ApproximateMessageCount очереди, чтобы увидеть, выполняет ли резервное копирование очередь (а затем масштабировать до дополнительных экземпляров, чтобы помочь потреблению элементов очереди).