Przetwarzanie asynchroniczne w zastosowaniach webowych

Transcript

1. PRZETWARZANIE ASYNCHRONICZNE W ZASTOSOWANIACH WEBOWYCH Leszek Krupiński WebClusters 2011
2. Ja  Kontakt z Linuksami od 1995 r.  Administrowanie Linuksami od 1999 r.  Programowanie dla Webu od 2000 r.  Aktualny etat: Instytut Techniczny Wojsk Lotniczych  Oprócz tego: optymalizacja serwisów, konsulting, budowanie architektury
3. Web PING-PONG PING-PONG PING-PONG
4. Wyobrażenie  Klient wysyła zdjęcie  Serwer generuje miniatury obrazków  Serwer rozsyła komunikaty do znajomych  Serwer regeneruje RSS  Klient dostaje odpowiedź o powodzeniu
5. Realia  Klient przesyła zdjęcie  Serwer generuje miniatury  Klient po dziesięciu sekundach się nudzi i odświeża stronę  Serwer znowu generuje miniatury  Klient po kolejnych dziesięciu sekundach się wkurza i wyłącza przeglądarkę
6. Przetwarzanie asynchroniczne Klient dostaje komunikat, przetwarzanie idzie w tle
7. Use Case Generowanie miniaturek
8. Rozwiązanie tradycyjne I  Zapisanie zdjęcia do katalogu  Regularne przeglądanie katalogu w poszukiwaniu nowych plików  Przetwarzanie plików  Zalety: brak opóźnienia dla klienta on-line  Wady: ograniczony zakres zastosowań, mała wydajność, opóźniona reakcja – technika pull
9. Rozwiązanie tradycyjne II  Dopisanie zadania do bazy SQL  Regularne przetwarzanie nowych zadań – Cron Job  Zalety:  dowolność technologii  Wspólny element: obsługa bazy danych  Wady:  opóźnione przetwarzanie  technika pull  tight coupling  sztywne spinanie przetwarzania – czy w kodzie, czy w konfiguracji
10. Odkrycie XXI wieku
11. Kolejka  zwana też ogonem lub ogonkiem. Forma nietrwałej zbiorowości powstająca przy transakcji (kolejki mieszkaniowe w PRL były trwałe, gdyż okres oczekiwania wynosił czasem powyżej 20 lat, także oczekiwanie na samochód w NRD trwało kilkanaście lat). Wiąże się ona ze zbyt małą liczbą osób oferujących dany towar/usługę w stosunku do zapotrzebowania i czasu obsługi. W wyniku tej sytuacji powstaje zgromadzenie ludzi, którzy organizują kolejność obsługi.  Prawidłowy przebieg transakcji: klienci są obsługiwani według kolejności ich przybycia do kas (np. w sklepie) lub rejestracji (u lekarza). W niektórych przypadkach jest to zbiorowość rozproszona, np. wówczas, gdy osoby zamawiają kolejkę czyli ustalają kolejność transakcji, jednak nie przebywają w tej samej przestrzeni, w pobliżu dokonywania transakcji pozostają tylko osoby, które zostaną obsłużone w najbliższym czasie.
13. PO CO KOLEJKA W WEBIE?  Długotrwałe zadania  Przetwarzanie w tle  Rozsyłanie informacji  Jeden nadawca, wielu odbiorców  Pewność transmisji  Zapewnienie przetworzenia każdego komunikatu
14. A w praktyce?
19. Jak to zrobić w praktyce?
20. Gotowe rozwiązania
21. Nihli Novi Java to ma od dawna
22. Advanced Message Queuing Protocol Otwarty standard
23. AMQP - Kolejka++  Otwarty protokół  Metoda publish-subscribe  Routing  Gotowe implementacje – np. RabbitMQ  Bramki do innych protokołów
24. Długotrwałe działania Miły dodatek do pozostałych cech
26. Loose coupling Przeciwieństwo technologii ściśle połączonych – gniazda TCP, UDP, CORBA, RMI
27. Dynamika połączeń Wpinanie listenerów w razie potrzeby  Dodawanie nowych usług  Duplikacja danych
28. Tryby działania  Fanout  Direct  Topic http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.1/html/Messaging_Tutorial/chap- Messaging_Tutorial-Initial_Concepts.html#sect-Messaging_Tutorial-Initial_Concepts-Fanout_Exchange
29. Fanout http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.1/html/Messaging_Tutorial/chap- Messaging_Tutorial-Initial_Concepts.html#sect-Messaging_Tutorial-Initial_Concepts-Fanout_Exchange
30. Direct http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.1/html/Messaging_Tutorial/sect- Messaging_Tutorial-Initial_Concepts-Direct_Exchange.html
31. Topic http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.1/html/Messaging_Tutorial/sect- Messaging_Tutorial-Initial_Concepts-Topic_Exchange.html
32. Przenośność Wiele platform, wiele technologii, wiele języków, wiele aplikacji
34. Load Balancing
35. Opcjonalnie – persistence
36. Opcjonalnie – tryb UDP-like
37. Show me the code
40. Dziękuję za uwagę. leafnode@gmail.com http://leafnode.pl/