Это классическая проблема. Лучшее, что вы можете сделать, это использовать блокировку Dequeue() с таймаутом, чтобы можно было обрабатывать больше, чем просто сообщения RabbitMQ. Например:
- на Unix/Linux также системы обработки сигналов, таких как SIGHUP или SIGINT
- на терминальных команд также принимают пользовательский ввод, чтобы вырваться из цикла с сообщением «Нажмите ESC, чтобы выйти ...» или что-то подобное
- , если есть и другие входные потоки обрабатывают те, тоже в том же потоке
Тайм-аут должен быть установлен на основе того, что вы ожидаете. Для некоторых системных сигналов очень строгие таймауты даются до того, как процесс выйдет из воды. Для консольных приложений человеческие пользователи не будут замечать тайм-аут 150 мс, он по-прежнему будет смотреть на них практически в реальном времени.
Если вы не блокируете и не используете таймаут, процессор будет потреблять ненужные ресурсы, чтобы как можно быстрее прокручивать их, без каких-либо преимуществ. Что-то вроде этого целесообразно только тогда, когда время очень важно. Но тогда вы бы не использовали RabbitMQ.
EDIT: больше о тайм-аута
А 1 второй тайм-аута делает не означает, что сообщение подобран в 1 секунду. Сообщения по-прежнему обрабатываются мгновенно, по мере их поступления. Тайм-аут означает, что ПРОЧИЕ задачи выполняются с максимальной задержкой в 1 секунду (средняя задержка составляет половину таймаута, поэтому 0,5 секунды).
Ожидание вращения должно использоваться только в том случае, если ожидаемое время ожидания «очень короткое». Вы эффективно держите CPU занятым ни с чем. В случае, когда это дешевле, чем переключение контекста на другой поток, это может быть хорошей идеей. Если вы долго ждали, это не так. Не зная больше о вашем случае, трудно дать хороший совет. У вас есть асинхронные версии этих методов? –
К сожалению, у него нет асинхронизации. Это было бы очень приятно. – Pintac
@ Pintac очень легко написать асинхронную оболочку. Очевидно, что поток I/O должен быть принесен в жертву. Но это нормально/приемлемо и распространено в EDA (Event Driven Architecture, например node.js). Таким образом, идея асинхронной обертки - это больше о стиле программирования и простоте использования, чем производительности или ресурсе. – pid