Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[PL] We all make distributed systems - RG Dev

Ba17945a06aac247b06548d5afe341e8?s=47 mrzasa
January 26, 2017

[PL] We all make distributed systems - RG Dev

Growing complexity of web and mobile apps makes then distributed systems. That's why it's reasonable to apply some results of distributed system research to web and mobile apps.

Slides for a talk given on Rzeszów Developer Meetup: https://www.meetup.com/rg-dev/events/236341099/.
I show how CAP theorem can be used to understand and handle limitations in modern web and mobile applications.

Ba17945a06aac247b06548d5afe341e8?s=128

mrzasa

January 26, 2017
Tweet

Transcript

  1. WE ALL MAKE WE ALL MAKE WE ALL MAKE WE

    ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE WE ALL MAKE DISTRIBUTED SYSTEMS DISTRIBUTED SYSTEMS DISTRIBUTED SYSTEMS DISTRIBUTED SYSTEMS DISTRIBUTED SYSTEMS DISTRIBUTED SYSTEMS MACIEJ RZĄSA @mjrzasa
  2. SERIO? SYSTEMY ROZPROSZONE? źródło: goodfreephotos.com

  3. KIM JESTEM? Software Engineer główne zainteresowania Ruby writing software that

    matters samoorganizacja systemy rozproszone (okazjonalnie) dzielenie się wiedzą Rzeszów Ruby User Group ( ) Politechnika Rzeszowska rrug.pl
  4. O CZYM POWIEM? Why? - dlaczego warto się zająć systemami

    rozproszonymi What? - ograniczenia systemów rozproszonych How? - case study
  5. Zestaw niezależnych komputerów, sprawiający na jego użytkownikach wrażenie jednego, logicznie

    zwartego systemu. źródło: Wikipedia SYSTEM ROZPROSZONY
  6. PROSTE JAK APLIKACJA WEBOWA?

  7. Zestaw niezależnych komputerów, sprawiający na jego użytkownikach wrażenie jednego, logicznie

    zwartego systemu. źródło: Wikipedia SYSTEM ROZPROSZONY
  8. NO I CO Z TEGO? źródło: pinterest.com

  9. 3 CECHY Consistency - spójność Availability - dostępność Partition tolerance

    - odporność na podziały
  10. single-copy consistency nie to samo co w ACID zapisuję na

    androidzie, czytam na komputerze CONSISTENCY
  11. każdy działający węzeł odpowiada poprawnie np: mogę skorzystać z każdego

    klienta (web/android/iOS/WP) AVAILABILITY
  12. system działa pomimo przerwania komunikacji błąd sieci: utrata pewnej ilości

    pakietów offline-mode timeout PARTITION TOLERACE
  13. nie można mieć wszystkich 3 dowód: spróbuj zapisać offline i

    przeczytać gdzie indziej CAP THEOREM
  14. spójność i dostępność rezygnujemy z obsługi podziałów jeden host sieć

    jest zawodna CA: I FEEL LUCKY
  15. spójność i odporność na podziały zapewniona spójność nie ma offline,

    działa tylko jak jest sieć ew. ograniczone funkcje (read-only) proste pobranie danych po powrocie połączenia CP: ORDNUNG MUSS SEIN
  16. dostępność i odporność na podziały aplikacja dostępna offline konieczna dwustronna

    synchronizacja AP: WORK AROUND THE CLOCK
  17. CASE STUDY jak na to trafiłem? dziedzina: recycling aplikacja mobilna

    dla agentów + webowy panel admina offline: skupowanie, rejestr płatności
  18. ARCHITEKTURA offline: AP, reszta: CP wymagana synchronizacja i rozwiązywanie konfliktów

    wyzwania rozmiar danych walidacje spójność (ACID) po stronie klienta identyfikacja edycja offline
  19. SYNCHRONIZACJA pobieranie dużej ilości danych po powrocie połączenia dwustronna synchronizacja

    wspólna edycja danych retransmisja
  20. SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC SYNC

    ALL THE DATA! ALL THE DATA! ALL THE DATA! ALL THE DATA! ALL THE DATA! ALL THE DATA! źródło: memegenerator.com
  21. SYNC - ONE WAY (CP) cenniki, publikowane ~1/tydzień, wiele o

    tej samej porze pierwsza wersja: wszystkie zmiany na raz większa ilość danych: timeouty, braki pamięci na androidzie rozwiązanie: paginacja!
  22. PAGINACJA GET /items? page=1 GET /items? since=1234 to=3456 GET /items?

    since=1234 page_size=3
  23. ONE WAY SYNC pobieranie danych do odczytu offline klient przechowuje

    timestamp klient może decydować o ilości przesyłanych danych
  24. SYNC - TWO WAY (AP) zapis paragonów (paragon, kupione przedmioty)

    skupowanie offline (!) każdy klient (android) tworzy swoje paragony i dodaje przedmioty paragony dostępne na serwerze i rozsyłane do innych klientów
  25. CLIENT SERVER SYNC - TWO WAY (AP) def sync() timestamp

    = get_timestamp() client_changes = choose_updated(timestamp) server_changes = send(client_changes, timestamp) # wait... store(server_changes) set_timestamp(Time.now()) end def sync(client_changes, timestamp) server_changes = choose_updated(timestamp) store(client_changes) send(server_changes) end
  26. EDYCJA PARAGONÓW anulowanie paragonów (zakupów) na serwerze zmienione paragony wysyłane

    do klientów FAIL! obie strony edytują paragon: serwer wygrywa rozwiązanie: synronizacja zmian statusu, a nie całych paragonów
  27. ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES

    NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY ONE DOES NOT SIMPLY SYNC MUTABLE STATE SYNC MUTABLE STATE SYNC MUTABLE STATE SYNC MUTABLE STATE SYNC MUTABLE STATE SYNC MUTABLE STATE źródło: youtube.com
  28. RETRANSMISJA Klient płatności wysyła płatności Serwer zapisuje i uaktualnia stany

    kont Co jeśli po zapisie klient utraci połączenie?
  29. RETRANSMISJA I IDENTYFIKACJA def sync(data) create_transaction(data) account.redeem(data.amount) end PUT /transactions

    { amount: 1000 } def sync(data) transaction = find_transaction(data.uuid) if transaction return end create_transaction(data) account.redeem(data.amount) end PUT /transactions { uuid: "2db1ec4c-...", amount: 1000 }
  30. WSPÓŁDZIELONE IDENTYFIKATORY AUTOINCREMENT z bazy danych nie wystarczy ;-) UUID

    (v4) bardzo niskie ryzyko kolizji może być generowany po stronie klienta pomocniczy identyfikator albo klucz główny e4043456-b29e-4d80-afaf-4d65246f1d36
  31. SKUTEK: IDEMPOTENTNOŚĆ If all you have is a timeout, everything

    looks like a partition synchronizacja może być powtarzana dowolną ilość razy pomocne przy błędach (sieci, serwera, klienta) zastosowanie: tworzenie danych po stronie klienta offline: notatki zakupy commity ;-)
  32. CZEGO SIĘ NAUCZYŁEM?

  33. CZEGO SIĘ NAUCZYŁEM? paginacji przy pomocy timestampów i rozmiaru strony

    poprawnej synchronizacji dwustronnej dbania o bezpieczeństwo danych podczas błędów (idempotencja) GET /items? since=1234 page_size3
  34. PODSUMOWANIE naturalne ograniczenia z systemów rozproszonych w web/mobile są naturalne

    ;-) CAP: spójność - dostępność - odporność na podziały: nie możesz mieć wszystkiego synchronizuj to, co niezmienne i aplikuj od zmiennego (events vs entities) idempotency matters :) w jednej aplikacji można stosować zarówno podejście CP jak i AP sieć jest zawodna ikony w diagramach pochodzą ze strony: http:/ /www.flaticon.com
  35. MATERIAŁY ikony w diagramach pochodzą ze strony: : testy bezpieczeństwa

    (safety) systemów rozproszonych : o zawodności sieci http:/ /www.flaticon.com CAP 12 years later Jepsen Netwok is reliable