1 / 50

Architektura aplikacji wielowątkowych

Architektura aplikacji wielowątkowych. Jakub Binkowski. Jakub Binkowski. 2008-2011. Lead .NET Developer. jakub@binkowski.com.pl. Cel prezentacji. Alternatywne podejście przy projektowaniu aplikacji wielowątkowych Częste błędy. Przykładowe rozwiązanie – silnik giełdy. Jak działa giełda?.

Download Presentation

Architektura aplikacji wielowątkowych

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related