Distributed Systems

Spring 2021

Overview

15-440 jest kursem wprowadzającym do systemów rozproszonych. Nacisk zostanie położony na techniki tworzenia funkcjonalnych, użytecznych i skalowalnych systemów rozproszonych. Aby uczynić zagadnienia bardziej konkretnymi, klasa obejmuje kilka wielotygodniowych projektów wymagających znaczącego projektowania i wdrażania

Cele tego kursu są dwojakie. Po pierwsze, dla studentów, aby uzyskać zrozumienie zasad i technik stojących za projektowaniem systemów rozproszonych, takich jak blokowanie, współbieżność, buforowanie, prefetching, harmonogramowanie i komunikacji w sieci. Po drugie, dla studentów, aby zdobyć praktyczne doświadczenie w projektowaniu, wdrażaniu i debugowaniu rzeczywistych systemów rozproszonych.

Główne tematy, które ten kurs będzie uczyć obejmują:

• Skromność zasobów, harmonogramowanie, i współbieżność
• Łatwość komunikacji i szerokość pasma
• Nazewnictwo
• Abstrakcja i modułowość
• Doskonała komunikacja i inne rodzaje awarii
• Ochrona przed przypadkowymi i złośliwymi szkodami
• Optymizm
• Konsensus
• Użycie narzędzi oprzyrządowania, monitorowania i narzędzi debugowania w rozwiązywaniu problemów.
• Projektowanie, wdrażanie i debugowanie znaczących projektów programistycznych, które obejmują powyższe tematy

Ocena

Wszystkie prace kursowe są wykonywane indywidualnie. Nie ma zespołów ani partnerów projektowych. W osobistych ofertach tego kursu (pre-COVID i, miejmy nadzieję, post-COVID) ocena była oparta na projektach (45%), zestawach problemów (20%), egzaminie śródsemestralnym (15%) i egzaminie końcowym (20%). W ofercie kursu na wiosnę 2021 roku, ze względu na ograniczenia COVID, egzaminy zostały zastąpione przez skumulowane zestawy problemów. Są one jak egzaminy z otwartą książką, ale bez presji czasu. Jak sugeruje ich nazwa, obejmują one cały materiał omówiony na zajęciach do tego momentu. Pozostałe zestawy problemowe nazywamy zestawami tematycznymi, ponieważ koncentrują się one na tematach. Tak więc ocena wiosną 2021 roku będzie następująca (wszystkie wagi są przybliżone, w granicach 5%):

• 45% za 4 projekty, równo ważone
• 20% za 4 tematyczne zestawy problemowe, równo ważone
• 15% za śródsemestralny łączny zestaw problemowy
• 20% za końcowy łączny zestaw problemowy.

Learning Outcomes

Oczekujemy, że studenci zdobędą głębokie zrozumienie, płynność w rozumowaniu i praktyczne umiejętności wdrażania następujących podstawowych koncepcji systemów w systemach rozproszonych:

1. • Komunikacja i zdalne wywoływanie procedur
   • Semantyka sterowania i ograniczenia językowe
   • Exactly-once, at-most-once, at-least-once
   • Serializacja i deserializacja
   • Targ end-to-end i jego zastosowanie w systemach rzeczywistych
   • Integracja z gwintowaniem
   • Współbieżność operacji
2. • Buforowanie danych i semantyka jednokrotnegocopy semantics
   • Protokoły spójności pamięci podręcznej i kompromisy implementacyjne
   • Origins of temporaland spatial locality
   • Metryki jakości pamięci podręcznej
   • Protokoły spójności specyficzne dla aplikacji
   • Prefetching: benefits and risks
   • Extraction of hints
   • Buffer bloat
3. • Awarie w systemach rozproszonych: geneza i badania empiryczne
   • Fail fast and Byzantine failures
   • Fundamentalne ograniczenia odporności na awarie
4. • Tolerancja na awarie: transakcje atomowe; własność ACID
   • Wyzwania implementacyjne
   • Shadowing, listy intencji i logowanie write-ahead
   • Tradeoffs in physical logging and operation logging
   • Transakcje zagnieżdżone
   • Transakcje rozproszone
5. • Konsensus i blockchain: jednomyślność (two-phase commit)
   • Majority (wybory lidera, Paxos)
   • Byzantine (single-shot i Dolev-Strong)
   • Replikacja maszyny stanowej i Streamlet
   • Bitcoin

6. Wspólne paradygmaty programowania, takie jak Map-Reduce, MPI i GraphLab

7. (Tylko jeśli czas na to pozwoli):
   • Uzyskanie wysokiej dostępności: oparte na głosowaniu zachowanie semantyki jednej kopii
   • Taksonomia strategii replikacji: podejścia pesymistyczne i optymistyczne
   • Konflikty odczytu-zapisu i zapisu-zapisu
   • Strategie serwer-klient i peer-to-peer
   • Buforowanie i operacje rozłączne; rozwiązywanie konfliktów
   • Wykorzystanie niskiej przepustowości w celu poprawy dostępności

Logistyka kursów

Profesorowie

.

Nazwa	Godziny urzędowania	Office	Phone	Andrew email
Mahadev Satyanarayanan (Satya)	Tue 1:00 – 3:00 pm	GHC-9123	x8-3743	satya
Padmanabhan Pillai (Babu)	Wed 11:00 am – 1:00 pm	GHC-9232		pspillai
Runting Shi (Elaine)	Mon 4:00 – 6:00 pm	CIC-.2217		Kontakt przez Canvas

Teaching Assistants

.

Nazwa	Godziny urzędowania	Andrew email
Nathan Ang	Thu 2:00-4:00 pm	nathanan
Junwon Chang (Joseph)	Sat 9:00-11:00 am	junwonc
Wenxin Ding (Freda)	Fri 10:00-12:00	wenxind
Timothy Ganger	Sat 4:00-6:00 pm	tganger
Ziying He	Fri 5:00-7:00 pm	ziyingh
Roger Iyengar	Wed 1:00-3:00 pm	raiyenga
Ishaan Jaffer	Thu 4:00-6:00 pm	ijaffer
Ibnul Jahan	Tue 4:00-6:00 pm	iej
Chen Jin (Crystal)	Fri 8:00-10:00	chenj
Yajin Li	Mon 10:00-12:00 pm	yajinl
Diego San Miguel	Fri 2:00-4:00 pm	dsanmigu
Riccardo Santoni	Mon 8:00-10:00 pm	rsantoni
Yiwen Song (Victor)	Thu 9:00-11:00 pm	yiwenson
Haithem Turki	Wed 3:00-5:00 pm	hturki
Clarissa Xu	Tue 6:30-8:30 pm	csxu

Lekcje

• Wtorki i czwartki, 10:40 am – 12:00 noon
• Powiększenie linków i nagrań wideo: Na stronie Canvas dla tego kursu
• No class: Wtorek 23 lutego (Dzień przerwy), Czwartek 15 kwietnia (Karnawał wiosenny)
• Ostatnie zajęcia: Czwartek, 6 maja

Recytacje

• Czas: środy 7:00 – 7:50pm (Sekcja A), 8:00 – 8:50pm (Sekcja B)
• Powiększenie linków i nagrań wideo: Na stronie Canvas dla tego kursu

Course Notes

Będą umieszczane w obszarze AFS kursu na: /afs/andrew/course/15/440/classnotes po każdych zajęciach.Te notatki są tylko do użytku osobistego. Proszę ich nie rozpowszechniać.

Textbooks and Optional Readings

Nie ma wymaganych podręczników. Oto trzy dobre referencje do wykorzystania w lekturach opcjonalnych:

• „Distributed Systems: Principles and Paradigms” Andrew S. Tanenbaum i Maarten Van Steen, Third (2017) Edition, Prentice Hall
• „Guide to Reliable Distributed Systems” Kenneth P. Birman, Springer
• Foundations of Distributed Consensus and Blockchains by Elaine Shi (2020, manuskrypt książki)

Dodatkowo, link „Readings” na górze tej strony internetowej ma pewne specifc opcjonalne lektury, o których będziemy wspominać w różnych punktach wykładów. Pliki pdf tych opcjonalnych lektur są dostępne na stronie internetowej kursu.

Course Policies

Prerequisites

Ponieważ ten kurs ma duży komponent projektowy, musisz być biegły w programowaniu w C i Java na systemach UNIX. Wymagane jest, abyś brał udział w kursie 15-213 i otrzymał „C” lub wyższy, ponieważ wiele z umiejętności programowania, których będziesz potrzebował, jest nauczanych w tym kursie. Jeśli otrzymałeś C w 15-213, musisz spotkać się ze swoim doradcą akademickim, aby omówić swoje doświadczenie przed podjęciem 15-440, być może biorąc dodatkowy kurs, aby wyostrzyć swoje umiejętności systemowe.

Policy on Academic Integrity

The Carnegie Mellon University Policy on Academic Integrity odnosi się do tego kursu. Wszyscy studenci powinni dokładnie zapoznać się z tą polityką i stosować się do niej we wszystkich aspektach tego kursu.

Wskazówki dotyczące współpracy:

• Studenci są zachęcani do rozmawiania ze sobą, z TAs, z instruktorami, lub z kimkolwiek innym na temat każdego z zadań. Wszelka pomoc musi być jednak ograniczona do omówienia problemu i naszkicowania ogólnego podejścia do rozwiązania.
• Każdy student musi napisać swoje własne rozwiązania do zestawów zadań. Wszystkie projekty muszą być wykonane indywidualnie.
• Konsultowanie rozwiązań innego studenta jest zabronione, a nadesłane rozwiązania nie mogą być kopiowane z żadnego źródła. Takie działania stanowią oszukiwanie.
• Jeśli masz jakiekolwiek pytania dotyczące tego, czy jakieś działanie stanowiłoby oszukiwanie, proszę śmiało pytać prowadzących.

Wskazówki dotyczące dzielenia się: Nie wolno dostarczać pracy, którą ukończysz podczas 15-440 innym studentom w przyszłych instancjach tego kursu lub do wykorzystania w przyszłych instancjach tego kursu (tak samo jak nie wolno używać pracy ukończonej przez studentów, którzy wzięli udział w kursie wcześniej).

Nagrania

Na wiosnę 2021, sesje Zoom każdego wykładu i recytacji będą nagrywane przez CMU Computing Services i umieszczane na stronie Canvas dla tego kursu. Wszystkie inne nagrania są zabronione.

Limit na korzystanie z czasu TA

Aby być sprawiedliwym dla wszystkich, zwłaszcza gdy jest długa linia studentów czekających na uwagę TA, będzie limit 10 minut na wszystkie konsultacje. Jeśli student nie skończy pracy po upływie 10 minut, wraca na koniec kolejki, zanim otrzyma więcej czasu na rozmowę z asystentem. Bądź przygotowany przed spotkaniem z TA. Jeśli potrzebujesz pomocy w znalezieniu błędu, zawęź i uprość problem przed spotkaniem z TA.

Piazza Policy

Ten kurs używa strony Piazza do odpowiadania na pytania: tutaj jest strona Piazza dla tego kursu.

Myśl o Piazza jak o podniesieniu ręki w klasie i zadaniu pytania. Żadne pytanie nie jest zbyt głupie, aby je zadać, więc nie bój się. Na każdą osobę, która zadaje pytanie, przypada prawdopodobnie wiele innych, którym to samo pytanie już się nasunęło lub nasunie się wkrótce. Odpowiedź na Twoje pytanie może być korzystna również dla nich. Poza tym mogą być osoby, którym twoje pytanie nie przyszło do głowy. Zadając to pytanie, pomagasz im dostrzec subtelności, których być może wcześniej nie widzieli. Bezpośrednie e-maile do instruktorów nie będą odpowiadane.

Przez cały czas oczekujemy, że użyjesz swojego dobrego osądu w swoich postach na Piazza (pytania jak również odpowiedzi na pytania innych studentów). Częścią procesu uczenia się jest zmaganie się z materiałem, aż dojdziesz do właściwego wglądu, który pozwoli Ci go zrozumieć. Umieszczanie zbyt wielu szczegółów w odpowiedzi na prośbę o pomoc może utrudnić naukę. Z drugiej strony, czasami dobrze jest zostać popchniętym we właściwym kierunku, kiedy nie jesteś w stanie wyrwać się z rutyny. I, oczywiście, niezrozumienie zadania lub dostępnych narzędzi powinno być szybko wyjaśnione. Proszę, używaj swojej najlepszej oceny podczas pisania na stronie Piazza, tak jakbyś współpracował ze swoimi przyjaciółmi osobiście. Kilka wstępnych wytycznych:

Przykłady dobrych rzeczy do wysłania i odpowiedzi:

• Niezrozumienie zadania
• Wyjaśnienia dotyczące wymagań
• Błędy w specyfikacji zadania lub implementacji referencyjnej lub testach
• Małe, szczegółowe pytania dotyczące działania wywołań systemowych, funkcji, itp.
• Rzeczy, które wyglądają na takie, które powinny znaleźć się w FAQ dla zadania

Przykłady złych rzeczy do umieszczenia lub odpowiedzi:

• Więcej niż kilka linii kodu
• Głębokie wyjaśnienia jak działa twój system
• Pytania o najlepsze podejście do architektury systemu na wysokim poziomie
• Pytania o twoją ocenę

Oczekujemy, że dołożysz rozsądnych starań, aby myśleć samodzielnie przed wysłaniem pytania na piazza. Jest to szczególnie prawdziwe w odniesieniu do debugowania Twojego kodu. Czy próbowałeś stron man? Czy przeszukałeś Google w poszukiwaniu odpowiednich zasobów? Czy spojrzałeś na poprzednie pytania, które ludzie już zadawali i na udzielone odpowiedzi? Czy wstawiałeś printf’y i próbowałeś zrozumieć, co się dzieje z twoim kodem?

Nie używaj autolabu jako narzędzia do debugowania. Oczekujemy, że dołożyłeś rozsądnych starań, aby zdebugować swój kod przed wysłaniem go do autolabu. Tworzenie przypadków testowych i testowanie wytrzymałościowe kodu jest częścią tego, o co chodzi w projekcie. Bez włożenia tego wysiłku, tracisz ważną część możliwości nauki w tym kursie. Wysłanie do autolabu powinno być ostatnim krokiem procesu, w którym testowałeś, debugowałeś i poprawiałeś swój kod w najszerszym możliwym zakresie. Wysyłanie zrzutu autolabu w poście na piazzie i mówienie „proszę o pomoc” jest poważnym naruszeniem etykiety piazzy.

Prywatne posty na Piazzie nie są obsługiwane. Jest to decyzja polityczna dla tej klasy. Pamiętaj, że pisanie na Piazza jest podobne do podniesienia ręki i zadania pytania. Inni studenci korzystają z tego, że zadajesz pytanie i widzą odpowiedź prowadzącego. Pozwalamy, aby Twoje posty były anonimowe dla innych studentów, jeśli tak zdecydujesz. Jest to już pewien stopień prywatności wykraczający poza to, co jest możliwe przy zadawaniu pytania na zajęciach. Dla naprawdę rzadkich okazji, kiedy musisz złożyć prywatną prośbę, która nie jest związana z treścią kursu, została stworzona specjalna prywatna lista mailingowa.

Dla próśb, które naprawdę muszą być prywatne Wyślij e-mail do[email protected]i jeden z instruktorów odpowie. E-maile na tę listę dotyczące treści kursu (np. wyjaśnienia do materiału zajęć) będą ignorowane; powinieneś umieszczać takie pytania na Piazza.

Policy on Late Submissions

Dla projektów:

• Każdy student będzie miał pięć spóźnionych dni do wykorzystania w ciągu semestru. Te spóźnienia mają na celu uwzględnienie świąt, podróży, wywiadów, przeziębienia i innych podobnych sytuacji. Możesz je wykorzystać z dowolnego powodu, bez pytania o zgodę prowadzących. Możesz użyć co najwyżej dwóch spóźnień w jednym terminie (tzn. w przypadku projektów z wieloma punktami kontrolnymi możesz użyć maksymalnie dwóch spóźnień dla każdego punktu kontrolnego). Jeden dzień spóźnienia = (0, 24) godziny po terminie; dwa dni spóźnienia = (24, 48) godziny po terminie; itd.

• Jeśli wykorzystasz wszystkie swoje dni spóźnienia, możesz wysłać spóźnienie za karą 15% za dzień, przez maksymalnie dwa dni. Innymi słowy, jeśli wykorzystałeś wszystkie swoje późne dni, możesz nadal składać przez następne dwa dni, ponosząc karę 15% za każdy z tych dni (dni karencji).

• Nie możesz łączyć dni spóźnienia i dni karencji, aby złożyć więcej niż dwa dni spóźnienia.

Dla zestawów zadań: Żadne spóźnione zgłoszenia nie są akceptowane, z lub bez kary. Upewnij się, że złożysz na czas.

Przewodnik po stylu dla projektów

Oprócz testowania funkcjonalności twojego kodu, będziemy również rezerwować część punktów każdego projektu na jego styl i czytelność. Najważniejszą rzeczą jest spójny i czytelny styl. Zwracamy uwagę głównie na to, czy wybrałeś styl, który jest czytelny i rozsądny, oraz czy używasz tego samego stylu konsekwentnie w całym projekcie.Użyj zdrowego rozsądku: nie miej 500-znakowych linii kodu, nie nazywaj swoich zmiennych foo (chyba, że ma to sens w kontekście), i unikaj losowego mieszania konwencji wielkości liter.

Będziemy zwracać uwagę na następujące rzeczy:

Dokumentacja Dobra dokumentacja jest ważna: dla ciebie w przyszłości, dla innych opiekunów kodu, i w tym kontekście, dla oceniających, którzy będą patrzeć na twój kod. Nie czuj potrzeby dokumentowania każdej linii kodu (ponieważ dobry kod powinien być w pewnym sensie samodokumentujący się), ale zazwyczaj dobrze jest podkreślić ogólne użycie i cel każdej funkcji, jak również dużych lub złożonych bloków kodu. Dobrą praktyką jest również umieszczanie nagłówka w każdym pliku, który szczegółowo opisuje jak dany plik pasuje do struktury projektu jako całości. Białe spacje Proszę być konsekwentnym. Proszę nie używać tabulatora 2 spacji w niektórych miejscach, a 4 w innych. Bądź rozsądny i używaj białych spacji, aby Twój kod był czytelny. Długość linii Będziemy rozsądni co do długości linii, tak długo jak będziesz konsekwentny i limity linii będą rozsądne (500 znaków nie jest… 80 lub 120 znaków jest powszechnie używane i akceptowane). Nazwy zmiennych Twoje nazwy zmiennych powinny jasno wskazywać co reprezentują lub jaki jest ich przypadek użycia. Martwy/testowy kod Staraj się nie wysyłać kodu, który jest zaśmiecony instrukcjami debugowania lub dużymi kawałkami kodu z komentarzami. Zmniejsza to czytelność i odwraca uwagę od kodu, który będzie działał na produkcji. Projektowanie Staraj się projektować swój kod i projekty w taki sposób, aby były one w miarę modularne. Funkcje składające się z 5000 linii są zazwyczaj oznaką słabego projektu i przysporzą ci później bólu głowy.

Tutaj jest przewodnik stylu Google, który może być pomocny.

Dobre samopoczucie

Tutaj jest kilka wskazówek dotyczących dobrego samopoczucia.