У нас есть много коммуникационных серверов, отправляющих пакеты данных. Мы хотели бы хранить эти пакеты данных, поступающие от этих серверных программ, в MSMQ до тех пор, пока программа обновления не обработает их. Потеря данных была проблемой, и мы хотели бы не потерять ни одного пакета данных, поступающего от этих серверных программ, и нам нужно эффективное и производительное решение.
Какой будет лучший подход к дизайну?
Ну, есть две основные вещи, которые вам нужно сделать, чтобы начать. Во-первых, вы захотите изменить установку по умолчанию, чтобы переместить место хранения на зеркальный диск и/или не тот, с которого загружается операционная система на этом сервере. Кроме того, вы должны убедиться, что там достаточно места для хранения сообщений по мере их поступления в очередь, в зависимости от объема, который вы рассматриваете. Это статья охватывает это.
Во-вторых, вы захотите использовать транзакции и ведение журнала для обеспечения надежности. Это проблема как программирования, так и инфраструктуры, поэтому вы можете начать с просмотра этого, а затем следовать общему руководству о том, как правильно программировать MSMQ. Это, например, хорошая отправная точка, если вы никогда не использовал MSMQ, хотя это довольно просто. Если вы собираетесь использовать MSMQ в качестве привязки/транспорта для WCF, тогда у вас есть сантехническая часть, которая в значительной степени покрыта; это просто вопрос настройки ваших сервисов для обработки объема и трафика, которые, как вы думаете, вы собираетесь увидеть.
У нас есть много коммуникационных серверов, отправляющих пакеты данных.
При хранении «пакетов данных» я бы рекомендовал записывать [Serializable] объекты .NET в WCF, главным образом потому, что WCF может прозрачно читать и записывать их в MSMQ. С этим будет проще работать, но если ваши пакеты данных, скажем, TCP/IP или двоичные пакеты, вам нужно будет включить «Порядок», чтобы гарантировать, что они попадут в очередь в точном порядке, в котором они были размещены.
MSMQ также имеет сеансы, поэтому, если вы хотите сгруппировать элементы, это возможно. WCF не дает такой гарантии. Для этого вам нужно будет написать собственный код, но это только случай присвоения уникального идентификатора каждому сообщению в конкретном сеансе.
Потеря данных была проблемой, и мы хотели бы не потерять ни одного пакета данных, поступающего от этих серверных программ.
MSMQ может сохранять данные на диск, поэтому, если сервер выходит из строя, его очередь сохраняется. MSMQ может хранить очередь в памяти, что более эффективно, но при сбоях или перезапусках информация об очереди не сохраняется.
и хотите эффективную (хорошую производительность)
MSMQ достаточно эффективен. Сохранение на диск имеет небольшие накладные расходы, но только из-за записи на диск. Если производительность включает многопоточность, MSMQ не предлагает эту функцию, поскольку очередь является последовательной, поэтому ее необходимо обрабатывать по порядку. Но это типично для технологий очередей.
MSMQ также имеет максимальный размер сообщения 4 МБ, поэтому имейте в виду, что вы хотите отправить по сети.
Другое дело, что MSMQ нельзя масштабировать. Его основная цель — гарантированная доставка. Если вы отправляете миллионы пакетов, они дойдут до места назначения, но у MSMQ есть ограниченная возможность отправлять сообщения на другие машины. Он работает с системой, подобной ThreadPool, поэтому он не будет масштабироваться, если это также является требованием.
Я также добавил информацию в вики #msmq-wcf с базовым примером записи данных.
