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

[PL] Wszyscy tworzymy systemy rozproszone - 4developers 2.04.2017

Ba17945a06aac247b06548d5afe341e8?s=47 mrzasa
April 02, 2017

[PL] Wszyscy tworzymy systemy rozproszone - 4developers 2.04.2017

Slides for my talk at 4developers 2017, Warsaw. Slightly different from previous versions of the same presentation.

Ba17945a06aac247b06548d5afe341e8?s=128

mrzasa

April 02, 2017
Tweet

Transcript

  1. WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY

    WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY WSZYSCY TWORZYMY SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE SYSTEMY ROZPROSZONE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? MACIEJ RZĄSA @mjrzasa
  2. SERIO? SYSTEMY ROZPROSZONE? źródło: goodfreephotos.com

  3. ALL DEVELOPMENT IS WEB DEVELOPMENT Atwood's Law: any application that

    can be written in JavaScript, will eventually be written in JavaScript. Writing Photoshop, Word, or Excel in JavaScript makes zero engineering sense, but it's inevitable. (...) all programming will be web programming Jeff Atwood (2009)
  4. KIM JESTEM? Ruby Developer @ TextMaster główne zainteresowania Ruby writing

    software that matters samoorganizacja systemy rozproszone dzielenie się wiedzą Rzeszów Ruby User Group ( ) Politechnika Rzeszowska rrug.pl
  5. PROSTE JAK APLIKACJA WEBOWA

  6. PROSTE JAK APLIKACJA WEBOWA?

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

    zwartego systemu. Andrew Tanenbaum System rozproszony to taki, w którym maszyna o której nigdy nie słyszałem powoduje, że mój program nie działa. Leslie Lamport PROSTE JAK APLIKACJA WEBOWA?
  8. KOMUNIKACJA: 3 CECHY Consistency - spójność Availability - dostępność Partition

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

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

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

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

    przeczytać gdzie indziej CAP THEOREM
  13. CAP + LATENCY = PACELC If all you have is

    a timeout, everything looks like a partition - @nkeywal
  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 korzystne dla klienta AP: WORK AROUND THE CLOCK
  17. CAP CA - I feel lucky CP - Ordnung muss

    sein AP - Work around the clock The choice of availability over consistency is a business choice, not a technical one. - @coda
  18. CASE STUDY CASE STUDY CASE STUDY CASE STUDY CASE STUDY

    CASE STUDY CASE STUDY CASE STUDY CASE STUDY CASE STUDY źródło: wikipedia.org
  19. CASE STUDY jak na to trafiłem? dziedzina: recycling aplikacja mobilna

    dla agentów + webowy panel admina offline: skupowanie, rejestr płatności
  20. WYZWANIA walidacje spójność (ACID) po stronie klienta edycja offline synchronizacja

    i rozwiązywanie konfliktów rozmiar danych
  21. SYNCHRONIZACJA pobieranie dużej ilości danych po powrocie połączenia dwustronna synchronizacja

    wspólna edycja danych retransmisja
  22. 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
  23. SYNC - ONE WAY (CP) cenniki, publikowane ~1/tydzień, wiele o

    tej samej porze wersja 1.0: wszystkie zmiany na raz większa ilość danych: timeouty, braki pamięci na androidzie
  24. PAGINACJA GET /items? page=1 GET /items? since=1234 to=3456 GET /items?

    since=1234 page_size=3
  25. 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
  26. 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
  27. EDYCJA PARAGONÓW anulowanie paragonów (zakupów) na serwerze zmienione paragony wysyłane

    do klientów FAIL! obie strony edytują paragon: zamiany są nadpisywane
  28. 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
  29. 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?
  30. RETRANSMISJA 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 }
  31. 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 skutek: idempotencja e4043456-b29e-4d80-afaf-4d65246f1d36
  32. RETRANSMISJA

  33. CZEGO SIĘ NAUCZYŁEM? pozwól decydować klientowi o rozmiarze i zakresie

    danych nie wysyłaj z powrotem otrzymanych właśnie danych synchronizuj to, co niezmienne i buduj zmienny stan używaj rozproszonych identyfikatorów, żeby zachować idempotencję Kto już to umiał? git, cassandra, CRDT, ...
  34. PODSUMOWANIE naturalne ograniczenia z systemów rozproszonych w web/mobile są naturalne

    ;-) sieć jest zawodna CAP: spójność - dostępność - odporność na podziały: nie możesz mieć wszystkiego w jednej aplikacji można stosować zarówno podejście CP jak i AP synchronizuj to, co niezmienne i aplikuj do zmiennego (events vs entities)
  35. A couple of months in the laboratory can frequently save

    a couple of hours in the library. Frank Westerheimer
  36. I went through life like this, discovering next something that

    had first beed discovered in 1889, then something from 1921... And finally I discovered something that had the same date as when I discovered it. (...) You are unlikely to discover something new without a lot of practice on old stuff. Richard Feynman, Feynman Lectures on Computation
  37. 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