Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом разделе приводятся общие и основные понятия, связанные с обменом данными в очереди. В последующих разделах приведены подробные сведения о том, как описанные здесь понятия очереди манифестируются в Windows Communication Foundation (WCF).
Основные понятия очереди
При разработке распределенного приложения важно выбрать правильный транспорт для обмена данными между службами и клиентами. Некоторые факторы влияют на тип транспорта для использования. Один из важных факторов — изоляция между службой, клиентом и транспортом — определяет использование транспорта с очередью или прямого транспорта, например, TCP или HTTP. Вследствие особенностей прямых транспортных протоколов, таких как TCP и HTTP, обмен данными полностью останавливается, если служба или клиент перестает функционировать или если сеть выходит из строя. Служба, клиент и сеть должны работать одновременно, чтобы приложение работало. Транспортные средства очередей обеспечивают изоляцию, что означает, что если служба или клиент выйдут из строя, или если связь между ними будет нарушена, клиент и служба могут продолжать работать.
Очереди обеспечивают надежную связь, даже если происходят сбои в работе участвующих сторон или самой сети. Очереди фиксируют и доставляют сообщения, которыми обмениваются стороны коммуникации. Очереди обычно поддерживаются каким-то хранилищем, которое может быть неустойчивым или устойчивым. Очереди хранят сообщения от клиента для службы и затем перенаправляют их в службу. Очереди косвенного обращения обеспечивают изоляцию отказа от любой стороны, что делает его предпочтительным механизмом связи для систем высокой доступности и отключенных служб. Косвенное использование связано с затратами на высокую задержку. Задержка — это задержка времени между временем отправки клиентом сообщения и временем его получения службой. Это означает, что после отправки сообщения вы не знаете, когда это сообщение может быть обработано. Большинство приложений в очереди справляются с высокой задержкой. На следующем рисунке показана концептуальная модель обмена данными в очереди.
Концептуальная модель связи с очередью
В действительности очередь представляет собой распределенную концепцию. Таким образом, они могут быть локальными для одной из сторон или удаленными для обеих сторон. Как правило, очередь является локальной для службы. В этой конфигурации клиент не может зависеть от подключения к удаленной очереди, чтобы быть постоянно доступным. Аналогичным образом очередь должна быть доступна независимо от доступности службы чтения из очереди. Диспетчер очередей управляет коллекцией очередей. Он отвечает за прием сообщений, отправленных в очереди от других диспетчеров очередей. Он также отвечает за управление подключением к удаленным очередям и передаче сообщений в эти удаленные очереди. Чтобы обеспечить доступность очередей, несмотря на сбои клиентского или служебного приложения, диспетчер очередей обычно работает в качестве внешней службы.
Когда клиент отправляет сообщение в очередь, он обращается к целевой очереди, которая является очередью, управляемой диспетчером очередей службы. Управляющий очередью на клиенте отправляет сообщение в очередь передачи (или исходящую). Очередь передачи — это очередь в диспетчере очередей клиента, в которой хранятся сообщения для передачи в целевую очередь. Затем диспетчер очередей находит путь к диспетчеру очередей, который управляет целевой очередью, и передает сообщение к нему. Чтобы обеспечить надежную связь, диспетчеры очередей реализуют надежный протокол передачи, чтобы предотвратить потерю данных. Диспетчер очередей назначения принимает сообщения, адресованные целевым очередям, принадлежащим ему, и сохраняет сообщения. Служба отправляет запросы на чтение из целевой очереди, в то время как диспетчер очередей отправляет сообщение в целевое приложение. На следующем рисунке показан обмен данными между четырьмя сторонами.
Обмен данными в очереди в типичном сценарии развертывания
Таким образом, диспетчер очередей обеспечивает необходимую изоляцию, чтобы отправитель и получатель могли независимо завершить работу, не влияя на фактическое взаимодействие. Преимущество дополнительного косвенного использования очередей также позволяет нескольким экземплярам приложений считывать из одной очереди, чтобы сельскохозяйственная работа между узлами достигла более высокой пропускной способности. Таким образом, для достижения более высоких требований к масштабу и пропускной способности часто используются очереди.
Очереди и транзакции
Транзакции позволяют группировать набор операций вместе, чтобы при сбое одной операции все операции завершились сбоем. Пример использования транзакций: когда пользователь использует банкомат для перевода $1000 из своего сберегательного счета на свой расчетный счет. Это влечет за собой следующие операции:
Вывод $1000 из сберегательного счета.
Внесение $1000 на расчетный счет.
Если первая операция завершается успешно, и $1000 удаляется из сберегательного счета, но вторая операция завершается сбоем, то 1000 долларов теряется, так как она уже была снята из сберегательного счета. Чтобы сохранить учетные записи в допустимом состоянии, если одна операция завершается ошибкой, обе операции должны завершиться с ошибкой.
При транзакционном обмене сообщениями, сообщения можно отправлять в очередь и получать из очереди под транзакцией. Таким образом, если сообщение отправляется в транзакции и транзакция откатывается, результат будет таким, как если бы сообщение никогда не было отправлено в очередь. Аналогично, если сообщение получено в транзакции и транзакция откатывается, результат будет таким же, как если бы сообщение никогда не было получено. Сообщение остается в очереди для чтения.
Из-за высокой задержки при отправке сообщения у вас нет способа знать, сколько времени требуется для достижения целевой очереди, и вы не знаете, сколько времени занимает служба для обработки сообщения. Из-за этого вы не хотите использовать одну транзакцию для отправки сообщения, получения сообщения и последующей обработки сообщения. При этом создается транзакция, которая не фиксируется в течение неопределенного периода времени. Когда клиент и служба взаимодействуют через очередь с помощью транзакции, участвуют две транзакции: одна на клиенте и одна на службе. На следующем рисунке показаны границы транзакций в типичном обмене данными в очереди.
Очередь обмена данными с отдельными транзакциями для сбора и доставки
Клиентская транзакция обрабатывает и отправляет сообщение. При фиксации транзакции сообщение находится в очереди передачи. В службе транзакция считывает сообщение из целевой очереди, обрабатывает сообщение, а затем фиксирует транзакцию. Если во время обработки возникает ошибка, сообщение откатывается и помещается в целевую очередь.
Асинхронное взаимодействие с помощью очередей
Очереди предоставляют асинхронные средства связи. Приложения, отправляющие сообщения с помощью очередей, не могут ожидать получения и обработки сообщения получателем из-за высокой задержки, введенной диспетчером очередей. Сообщения могут оставаться в очереди в течение гораздо более длительного времени, чем изначально предполагалось приложением. Чтобы избежать этого, приложение может указать значение time-To-Live в сообщении. Это значение указывает, сколько времени сообщение должно оставаться в очереди передачи. Если это время превышено, и сообщение по-прежнему не отправлено в целевую очередь, сообщение может быть передано в очередь недоставленных писем.
Когда отправитель отправляет сообщение, завершение операции отправки подразумевает только факт достижения сообщения до очереди передачи на стороне отправителя. Таким образом, если при получении сообщения в целевую очередь возникает сбой, отправляющее приложение не может сразу узнать об этом. Чтобы заметить такие сбои, сообщение об ошибке передается в очередь недоставленных писем.
Любая ошибка, такая как сообщение, не достигающее целевой очереди, или истечение срока действия событияTo-Live, должна обрабатываться отдельно. Для приложений, работающих с очередями, нередко писать два набора логики.
Обычная логика клиента и службы отправки и получения сообщений.
Логика компенсации для обработки сообщений из сбоя передачи или доставки.
В следующих разделах рассматриваются эти понятия.
Dead-Letter Программирование очередей
Очереди недоставленных писем содержат сообщения, которые не смогли достичь целевой очереди по различным причинам. Причины могут варьироваться от просроченных сообщений до проблем с подключением, предотвращающих передачу сообщения в целевую очередь.
Как правило, приложение может читать сообщения из системной очереди недоставленных писем, определять, что пошло не так, и принимать соответствующие меры, такие как исправление ошибок и повторная отправка сообщения или отметить это.
Программирование очереди подозрительных сообщений
После того как сообщение попадает в целевую очередь, службе может многократно не удаваться обработать сообщение. Например, приложение, считывающее сообщение из очереди в рамках транзакции, может обновлять базу данных и обнаружить, что база данных временно отключена. В этом случае транзакция откатывается, создается новая транзакция, и сообщение считывается заново из очереди. Вторая попытка может завершиться успешной или неудачной. В некоторых случаях в зависимости от причины ошибки сообщение может неоднократно не доставляться в приложение. В этом случае сообщение считается "ядным". Такие сообщения перемещаются в очередь отравляющих веществ, которую можно прочитать приложением для обработки подозрительных веществ.