Architektura aplikacji wielowątkowych

1. Architektura aplikacji wielowątkowych Jakub Binkowski

2. Jakub Binkowski 2008-2011 Lead .NET Developer jakub@binkowski.com.pl

3. Cel prezentacji • Alternatywne podejście przy projektowaniu aplikacji wielowątkowych • Częste błędy

4. Przykładowe rozwiązanie – silnik giełdy

5. Jak działa giełda? Produkty Sprzedający Kupujący

6. Jak działa rynek? Oferty zakupu Oferty sprzedaży

7. Jak działa rynek? Oferty zakupu Oferty sprzedaży

8. Jak działa rynek? Oferty zakupu Oferty sprzedaży

9. Jak działa rynek? Oferty zakupu Oferty sprzedaży

10. Jak działa rynek? Oferty zakupu Oferty sprzedaży

11. Jak działa rynek? Oferty zakupu Oferty sprzedaży Transakcja Anna sprzedaje Janowi 30 szt. w cenie 100,00 zł/szt.

12. Jak działa rynek? Oferty zakupu Oferty sprzedaży

13. Jak działa rynek? Oferty zakupu Oferty sprzedaży

14. Jak działa rynek? Oferty zakupu Oferty sprzedaży Transakcja Zenon sprzedaje Janowi 20 szt. w cenie 100,00 zł/szt.

15. Jak działa rynek? Oferty zakupu Oferty sprzedaży

16. Jak działa rynek? Oferty zakupu Oferty sprzedaży Transakcja Zenon sprzedaje Ewie 100 szt. w cenie 95,00 zł/szt.

17. Jak działa rynek? Oferty zakupu Oferty sprzedaży

18. Architektura z lotu ptaka Oferty sprzedaży Silnik rynku Transakcje Oferty zakupu Aktualizacje ofert

19. Przetworzenie oferty • Odebranie wiadomości • Audyt (zapis na dysk) • Deserializacja (byte[] object) • Umieszczenie na rynku Oferty sprzedaży Silnik rynku Oferty zakupu

20. Przetworzenie transakcji • Wygenerowanie przez rynek • Serializacja (object byte[]) • Audyt (zapisanie na dysk) • Wysłanie do strony kupującej i sprzedającej Silnik rynku Transakcje

21. Przetworzenie aktualizacji oferty • Wygenerowanie przez rynek • Serializacja (object byte[]) • Audyt (zapisanie na dysk) • Wysłanie do składającego ofertę Silnik rynku Aktualizacje ofert

22. Wymagania • Niezawodność / bezbłędność • Wysoka testowalność rozwiązania • Pełny audyt • Możliwość odtworzenia dowolnej sytuacji • Wysoka wydajność • Optymalizacja kodu

23. Architektura „standardowa” • Przychodząca wiadomość = 1 wątek • Wątki brane z puli (ThreadPool) Pula wątków w .NET: • Zbiór wątków dostępnych dla aplikacji • Minimalna ilość wątków = ilość procesorów logicznych • Maksymalna – zależy od środowiska

24. Obsługa wiadomości przychodzących Dedykowany wątek Pula wątków Wiadomości przychodzące

25. Składanie oferty

26. Zdarzenia na rynku

27. Podsumowanie

28. Demo:Wielowątkowo vs jednowątkowo

29. W czym jest problem? lock Serializacja Audyt

30. W czym jest problem? Tylko tutaj potrzebny jest lock! lock

31. „lock leak” lock (sync){//...    _eventConsumer.ProcessOfferUpdated(/*...*/); //...} lock (sync){//...var handler = OfferUpdated;if (handler != null)    {        handler(this, EventArgs.Empty);    }//...} Przekazanie kontroli do zewnętrznego kodu

32. „lock leak” - konsekwencje • Utrata wydajności • Możliwe deadlocki • Możliwe zapchanie się puli wątków  OutOfMemoryException

33. „lock leak” - jak uniknąć? boolofferUpdated = false;lock (sync){//...offerUpdated = true;//...}if (offerUpdated)    _eventConsumer.ProcessOfferUpdated(/*..*/); • Uwaga! Wywoływanie powiadomień za sekcją krytyczną może wpłynąć na logikę działania aplikacji.

34. Demo:Unikanie „lock leak”

35. Czy spełniliśmy wymagania? • Niezawodność / bezbłędność • Wysoka testowalność rozwiązania • Czy nasz kod można dobrze przetestować? • Pełny audyt • Możliwość odtworzenia dowolnej sytuacji • Czy wykonanie nie jest losowe? • Wysoka wydajność • Optymalizacja kodu • Czy nie da się szybciej?

36. Co zrobić, aby spełnić te wymagania?

37. Architektura oparta o kolejki Wysokowydajne kolejki wielowątkowe

38. Architektura oparta o kolejki Wątki wykonujące kolejne operacje

39. Architektura oparta o kolejki Wiadomości przychodzące Audyt Deserializacja Przetwarzanie przez rynek Wiadomości wychodzące Serializacja Audyt

40. Jak to zrealizować (w .NET 4)? • ConcurrentQueue<T> • wielowątkowo bezpieczna kolejka • wysoko zoptymalizowana • BlockingCollection<T> • opakowanie na kolekcje • wspiera scenariusz producent-konsument • pozwala na blokowanie odczytu (kolekcja pusta) • pozwala na blokowanie zapisu (kolekcja pełna)

41. BlockingCollection<T> - przykład • Deklaracja:var queue = newBlockingCollection<int>(100); Maksymalna pojemność kolekcji

42. BlockingCollection<T> - przykład • Producent:queue.Add(1);queue.Add(2);queue.Add(3);queue.CompleteAdding(); Wstawianie elementów Zakończenie dodawania

43. BlockingCollection<T> - przykład • Konsument:var consumer = queue.GetConsumingEnumerable();foreach (var number in consumer){Console.WriteLine(number);} Oczekiwanie na elementy (przy pustej kolekcji) Enumeracja jak przy zwykłej kolekcji

44. Demo:Czy kolejki się sprawdzą?

45. Architektura oparta o kolejkiZalety • Eliminacja wielowątkowości • Wiele wątków, ale kolejki zajmują się synchronizacją • Kod łatwy do testowania • Przewidywalność zachowania • Powtórzenie danych wejściowych zawsze da taki sam rezultat • Wyższa wydajność • Mniej wątków = mniejsza konieczność synchronizacji • Możliwość grupowego przetwarzania

46. Architektura oparta o kolejkiZalety • Bardziej przejrzysty design • Jasno określone wątki aplikacji • Dobrze zdefiniowane punkty interakcji pomiędzy wątkami (kolejki) • Pełny wgląd w aktualny stan aplikacji • Ilość elementów w kolejce • Łatwa lokalizacja wąskich gardeł

47. Architektura oparta o kolejkiWady • Trudniejsze debugowanie • Bardziej pracochłonna • Wymaga dokumentacji

48. Gdzie taka architektura się sprawdzi? Aplikacje: • przetwarzające niewiele rodzajów zdarzeń • o relatywnie prostej logice • mocno obciążone (wymagana wysoka wydajność) Na przykład: • systemy giełdowe • systemy agregujące/przetwarzające dane • aplikacje dostarczające dane „na żywo”

49. Podsumowanie • Klasyczne podejście „operacja = wątek” nie zawsze najwydajniejsze • Uwaga na wywołania zewnętrzne wewnątrz lock! • Kolejki mogą rozwiązać problem synchronizacji pomiędzy wątkami

50. Dziękuję za uwagę. Pytania?