Udostępnij przez

Najlepsze rozwiązania dotyczące komunikacji z obsługą kolejek

  • Artykuł

Ten temat zawiera zalecane rozwiązania dotyczące komunikacji w kolejce w programie Windows Communication Foundation (WCF). W poniższych sekcjach omówiono zalecane rozwiązania z perspektywy scenariusza.

Szybkie, najlepsze wysiłki kolejkowane komunikaty

W przypadku scenariuszy wymagających oddzielenia komunikatów w kolejce zapewnia i szybkie komunikaty o wysokiej wydajności z najlepszymi zabezpieczeniami, należy użyć kolejki nie transakcyjnej i ustawić ExactlyOnce właściwość na false.

Ponadto można zrezygnować z ponoszenia kosztów zapisów dysków, ustawiając Durable właściwość na falsewartość .

Bezpieczeństwo ma wpływ na wydajność. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące wydajności.

Niezawodna kompleksowa obsługa komunikatów w kolejce

W poniższych sekcjach opisano zalecane rozwiązania dotyczące scenariuszy wymagających kompleksowej niezawodnej obsługi komunikatów.

Podstawowy niezawodny transfer

Aby zapewnić kompleksową ExactlyOnce niezawodność, ustaw właściwość na wartość , aby true zapewnić transfer. Właściwość Durable można ustawić na true lub false w zależności od wymagań (wartość domyślna to true). Ogólnie rzecz biorąc, Durable właściwość jest ustawiona na true jako część kompleksowej niezawodności. Kompromis jest kosztem wydajności, ale sprawia, że komunikat jest trwały, aby komunikat nie został utracony, jeśli menedżer kolejek ulegnie awarii.

Korzystanie z transakcji

Aby zapewnić kompleksową niezawodność, należy użyć transakcji. ExactlyOnce Zapewnia tylko, że komunikaty są dostarczane do kolejki docelowej. Aby upewnić się, że komunikat zostanie odebrany, użyj transakcji. Bez transakcji, jeśli usługa ulegnie awarii, utracisz komunikat dostarczany, ale jest rzeczywiście dostarczany do aplikacji.

Korzystanie z kolejek utraconych komunikatów

Kolejki utraconych komunikatów zapewniają, że otrzymasz powiadomienie, jeśli komunikat nie zostanie dostarczony do kolejki docelowej. Możesz użyć kolejki utraconych komunikatów dostarczanych przez system lub niestandardowej kolejki utraconych komunikatów. Ogólnie rzecz biorąc, użycie niestandardowej kolejki utraconych komunikatów jest najlepsze, ponieważ umożliwia wysyłanie komunikatów utraconych z jednej aplikacji do pojedynczej kolejki utraconych komunikatów. W przeciwnym razie wszystkie komunikaty utraconych komunikatów, które występują dla wszystkich aplikacji uruchomionych w systemie, są dostarczane do jednej kolejki. Każda aplikacja musi następnie przeszukiwać kolejkę utraconych komunikatów, aby znaleźć komunikaty utraconych wiadomości, które są istotne dla tej aplikacji. Czasami użycie niestandardowej kolejki utraconych komunikatów nie jest możliwe, na przykład w przypadku korzystania z biblioteki MSMQ 3.0.

Wyłączenie kolejek utraconych komunikatów na potrzeby kompleksowej niezawodnej komunikacji nie jest zalecane.

Aby uzyskać więcej informacji, zobacz Using Dead-Letter Queues to Handle Message Transfer Failures (Używanie kolejek utraconych komunikatów do obsługi błędów transferu komunikatów).

Korzystanie z obsługi komunikatów zatrutych

Obsługa komunikatów zatrutych umożliwia odzyskanie sprawności po niepowodzeniu przetwarzania komunikatów.

W przypadku korzystania z funkcji obsługi komunikatów trucizny upewnij się, że ReceiveErrorHandling właściwość jest ustawiona na odpowiednią wartość. Ustawienie wartości Drop oznacza, że dane zostaną utracone. Z drugiej strony ustawienie go na Fault błędy hosta usługi podczas wykrywania komunikatu trucizny. Użycie msMQ 3.0 jest najlepszą opcją, Fault aby uniknąć utraty danych i przenieść zatruty komunikat z drogi. Użycie programu MSMQ 4.0 Move jest zalecanym podejściem. Move przenosi zatruty komunikat z kolejki, aby usługa mogła nadal przetwarzać nowe komunikaty. Usługa otrucia wiadomości może następnie przetworzyć komunikat trucizny oddzielnie.

Aby uzyskać więcej informacji, zobacz Obsługa komunikatów zatrutych.

Osiąganie wysokiej przepływności

Aby uzyskać wysoką przepływność w jednym punkcie końcowym, użyj następującego polecenia:

  • Przetwarzanie wsadowe z transakcjami. Przetwarzanie wsadowe w ramach transakcji gwarantuje, że wiele komunikatów można odczytać w jednej transakcji. Pozwala to zoptymalizować zatwierdzenia transakcji, zwiększając ogólną wydajność. Koszt przetwarzania wsadowego polega na tym, że jeśli awaria wystąpi w jednym komunikacie w partii, cała partia zostanie wycofana, a komunikaty muszą być przetwarzane pojedynczo, dopóki nie zostanie ponownie bezpiecznie wsadowe. W większości przypadków komunikaty o truciznach są rzadkie, więc dzielenie na partie jest preferowanym sposobem zwiększenia wydajności systemu, szczególnie w przypadku innych menedżerów zasobów, którzy uczestniczą w transakcji. Aby uzyskać więcej informacji, zobacz Batching Messages in a Transaction (Przetwarzanie wsadowe komunikatów w transakcji).

  • Współbieżność. Współbieżność zwiększa przepływność, ale współbieżność również wpływa na rywalizację o udostępnione zasoby. Aby uzyskać więcej informacji, zobacz Współbieżność.

  • Ograniczenie przepustowości. Aby uzyskać optymalną wydajność, ogranicz liczbę komunikatów w potoku dyspozytora. Aby zapoznać się z przykładem tego, jak to zrobić, zobacz Ograniczanie przepustowości.

Podczas korzystania z przetwarzania wsadowego należy pamiętać, że współbieżność i ograniczanie przepustowości przekładają się na współbieżne partie.

Aby uzyskać większą przepływność i dostępność, użyj farmy usług WCF odczytywanych z kolejki. Wymaga to, aby wszystkie te usługi uwidoczniły ten sam kontrakt w tym samym punkcie końcowym. Podejście farmy działa najlepiej w przypadku aplikacji, które mają wysokie stawki produkcyjne komunikatów, ponieważ umożliwia wielu usługom odczytywanie z tej samej kolejki.

W przypadku korzystania z farm należy pamiętać, że program MSMQ 3.0 nie obsługuje zdalnych operacji odczytu. Program MSMQ 4.0 obsługuje zdalne operacje odczytu.

Aby uzyskać więcej informacji, zobacz Batching Messages in a Transaction (Przetwarzanie wsadowe komunikatów w transakcji).

Kolejkowanie za pomocą semantyki jednostki pracy

W niektórych scenariuszach grupa komunikatów w kolejce może być powiązana i dlatego kolejność tych komunikatów jest znacząca. W takich scenariuszach przetwórz grupę powiązanych komunikatów razem jako pojedynczą jednostkę: wszystkie komunikaty są przetwarzane pomyślnie lub żadna z nich. Aby zaimplementować takie zachowanie, użyj sesji z kolejkami.

Aby uzyskać więcej informacji, zobacz Grupowanie komunikatów w kolejce w sesji.

Korelowanie komunikatów żądania i odpowiedzi

Chociaż kolejki są zwykle jednokierunkowe, w niektórych scenariuszach możesz skorelować odpowiedź odebraną wcześniej do żądania. Jeśli potrzebujesz takiej korelacji, zaleca się zastosowanie własnego nagłówka komunikatu PROTOKOŁU SOAP zawierającego informacje korelacji z komunikatem. Zazwyczaj nadawca dołącza ten nagłówek z komunikatem i odbiorcą po przetworzeniu wiadomości i odpowiedzi z powrotem przy użyciu nowej wiadomości w kolejce odpowiedzi dołącza nagłówek wiadomości nadawcy zawierający informacje korelacji, aby nadawca mógł zidentyfikować komunikat odpowiedzi z komunikatem żądania.

Integrowanie z aplikacjami innych niż WCF

Użyj MsmqIntegrationBinding polecenia podczas integrowania usług lub klientów programu WCF z usługami lub klientami spoza programu WCF. Aplikacja spoza programu WCF może być aplikacją MSMQ napisaną przy użyciu biblioteki System.Messaging, COM+, Visual Basic lub C++.

W przypadku korzystania z programu MsmqIntegrationBindingnależy pamiętać o następujących kwestiach:

  • Treść komunikatu programu WCF nie jest taka sama jak treść komunikatu MSMQ. Podczas wysyłania komunikatu programu WCF przy użyciu powiązania w kolejce treść komunikatu programu WCF jest umieszczana wewnątrz komunikatu MSMQ. Infrastruktura MSMQ nie jest nieświadoma tych dodatkowych informacji; widzi tylko komunikat MSMQ.

  • MsmqIntegrationBinding obsługuje popularne typy serializacji. Na podstawie typu serializacji typ treści komunikatu MsmqMessage<T>ogólnego , przyjmuje różne parametry typu. Na przykład ByteArray wymaga i MsmqMessage\<byte[]>Stream wymaga .MsmqMessage<Stream>

  • W przypadku serializacji XML można określić znany typ przy użyciu atrybutu KnownTypes w <elemecie zachowania> , który jest następnie używany do określenia, jak deserializować komunikat XML.

Zobacz też