Czy powinienem używać MSMQ lub SQL Service Broker dla transakcji?

Question

Zostałem poproszony przez kierownika zespołu o zbadanie MSMQ jako opcji dla nowej wersji naszego produktu. Używamy SQL Service Broker w naszej aktualnej wersji. Zrobiłem sporo eksperymentów i Googling, aby znaleźć produkt, który jest lepszy dla moich potrzeb, ale pomyślałem, że poprosiłbym o najlepszą stronę, którą znam do programowania odpowiedzi.

Niektóre szczegóły:

• Nasz klient jest .NET 1.1 i 2.0 kodu; to jest miejsce, z którego zostanie wysłana wiadomość.
• Cel w wystąpieniu programu SQL Server 2005. Wszystkie wiadomości kończą się aktualizacjami bazy danych lub wstawkami.
• Wyślemy kilka aktualizacji, które należy traktować jako transakcję.
• Musimy mieć doskonałą możliwość odzyskania wiadomości; żadne wiadomości nie mogą zostać utracone.
• Musimy być asynchroniczni i być w stanie akceptować wiadomości nawet wtedy, gdy docelowy serwer SQL nie działa.
• Opracowanie własnego rozwiązania kolejkowania nie jest opcją; jesteśmy małym zespołem.

Czego odkryliśmy do tej pory:

• Zarówno MSMQ i SQL Service Broker może wykonać pracę.
• Wygląda na to, że broker usług jest szybszy w przypadku wiadomości transakcyjnych.
• Service Broker wymaga serwera SQL działającego gdzieś, podczas gdy MSMQ potrzebuje jakiejkolwiek skonfigurowanej maszyny Windows uruchomionej gdzieś.
• MSMQ wydaje się być lepszy/szybszy/łatwiejszy do skonfigurowania/uruchomienia w klastrach.

Czy czegoś brakuje? Czy jest tu wyraźny zwycięzca? Wszelkie myśli, doświadczenia i linki będą cenione. Dziękuję Ci!

EDYCJA: Skończyło się trzymanie brokera usług, ponieważ mamy niestandardową strukturę DB używaną w niektórych z naszych kodów klienta (lepiej radzimy sobie z transakcjami). Ten kod przechwycił SQL dla transakcji, ale nie. Kod klienta był również w wersji 1.1 systemu .NET, więc musielibyśmy zaktualizować cały kod klienta. Dzięki za pomoc!

Answer 1

Po migracji mojej aplikacji z Service Broker do MSMQ, musiałbym głosować na używanie MSMQ. Jest kilka czynników, które należy wziąć pod uwagę, ale większość z nich ma związek z tym, w jaki sposób korzystasz z danych i gdzie przetwarzane są dane.

• Jeśli przetwarzanie odbywa się w bazie danych? Service Broker
• Jeśli to tylko przenoszenie danych?Service Broker
• Czy przetwarzanie odbywa się w kodzie .NET/COM? MSMQ
• Czy trzeba zdalnego transakcji rozproszonych (na przykład przetwarzanie na polu innym niż SQL)? MSMQ
• Czy musisz mieć możliwość wysyłania wiadomości, gdy miejsce docelowe nie działa? MSMQ
• Chcesz skorzystać nServiceBus, MassTransit Rhino-ESB, itp? MSMQ

warte rozważenia bez względu na to, co wybrać

• Skąd wiesz zdrowia kolejce? Obie opcje obsługują przełączanie awaryjne inaczej. Na przykład Service Broker wyłącza twoją kolejkę w niektórych scenariuszach, które mogą spowodować likwidację aplikacji.
• Jak przeprowadzasz raportowanie? Jeśli używasz już tabel SQL w swoich raportach, Service Broker może łatwo się zmieścić, ponieważ jest to tylko kolejny dynamiczny stół. Jeśli korzystasz już z Monitora wydajności, MSMQ może być ładniejszy. Service Broker ma wiele liczników wydajności, więc niech to nie będzie jedyny czynnik.
• Jak mierzysz czas pracy? Czy tylko upewniasz się, że nie tracisz transakcji, czy też musisz reagować synchronicznie? Uważam, że rozproszona natura MSMQ pozwala na dłuższy czas pracy bez przestojów, ponieważ główna kolejka może przejść w tryb offline i niczego nie stracić. Podczas gdy z Service Broker twoja baza danych musi być online lub w przeciwnym razie stracisz.
• Czy masz już doświadczenie z jedną z tych technologii? Oba mają wiele szczegółów dotyczących implementacji, które mogą wrócić i cię ugryźć.
• Nie ma znaczenia, jakiego wyboru dokonujesz, jak łatwo jest wyłączyć podstawową technologię kolejkowania? Polecam posiadanie ogólnego interfejsu IQueue, przed którym piszesz konkretną implementację. W ten sposób dokonany wybór można łatwo zmienić później, jeśli okaże się, że zrobiłeś źle. W końcu kolejka jest po prostu kolejką i nie powinna blokować cię w konkretnej implementacji.

Answer 2

Używałem wcześniej MSMQ i jedynym elementem, który bym dodał do twojej listy, jest sprawdzenie wymagań wstępnych dla wersji. Wystąpił problem, w którym jedna witryna miała serwer Windows 2000, a zatem MSMQ v.2, a nie Windows 2003 Server i MSMQ v3. Cały mój kod .NET jest skierowany do v.3 i nie są kompatybilne ... a przynajmniej nie tak łatwo.

Tylko rozważenie, jeśli przejdziesz na trasę MSMQ.

Answer 3

Ograniczenie rozmiaru wiadomości w MSMQ zatrzymało moje kopanie w tym kierunku. Uczę się Service Broker dla projektu.

Answer 4

Czy musisz mieć możliwość wysyłania wiadomości, gdy miejsce docelowe nie działa? MSMQ

Nie rozumiem dlaczego? SSB może bez problemu wysyłać wiadomości do odłączonego miejsca docelowego. Wszystkie te wiadomości będą przesyłane do kolejki transmisji i będą dostarczane po osiągnięciu miejsca docelowego.