Web Analytics

system-design-primer

⭐ 318813 stars Polish by donnemartin

English ∙ 日本語 ∙ 简体中文 ∙ 繁體中文 | العَرَبِيَّة‎ ∙ বাংলা ∙ Português do Brasil ∙ Deutsch ∙ ελληνικά ∙ עברית ∙ Italiano ∙ 한국어 ∙ فارسی ∙ Polski ∙ русский язык ∙ Español ∙ ภาษาไทย ∙ Türkçe ∙ tiếng Việt ∙ Français | Add Translation

Pomóż przetłumaczyć ten przewodnik!

The System Design Primer


Motywacja

Naucz się projektować systemy na dużą skalę.
>
Przygotuj się do rozmowy rekrutacyjnej z zakresu projektowania systemów.

Naucz się projektować systemy na dużą skalę

Nauka projektowania skalowalnych systemów pomoże Ci stać się lepszym inżynierem.

Projektowanie systemów to szeroki temat. Istnieje ogromna ilość zasobów rozproszonych po całym internecie na temat zasad projektowania systemów.

To repozytorium to zorganizowana kolekcja zasobów, które pomogą Ci nauczyć się budować systemy na dużą skalę.

Ucz się od społeczności open source

To jest stale aktualizowany projekt open source.

Wkłady są mile widziane!

Przygotuj się do rozmowy rekrutacyjnej z zakresu projektowania systemów

Oprócz rozmów technicznych z zakresu kodowania, projektowanie systemów jest wymaganym elementem procesu rekrutacyjnego w wielu firmach technologicznych.

Ćwicz popularne pytania rekrutacyjne z projektowania systemów i porównuj swoje odpowiedzi z przykładowymi rozwiązaniami: dyskusje, kod oraz diagramy.

Dodatkowe tematy do przygotowania do rozmowy rekrutacyjnej:

Fiszki Anki


Dostarczone talii fiszek Anki używają powtarzania rozłożonego w czasie, aby pomóc Ci zapamiętać kluczowe pojęcia z projektowania systemów.

Świetne do nauki w podróży.

Zasób programistyczny: Interaktywne wyzwania programistyczne

Szukasz zasobów, które pomogą Ci przygotować się do rozmowy rekrutacyjnej z kodowania?


Zobacz repozytorium siostrzane Interaktywne wyzwania programistyczne, które zawiera dodatkową talię Anki:

Współtworzenie

Ucz się od społeczności.

Zachęcamy do zgłaszania pull requestów, aby pomóc:

Treści wymagające dopracowania są umieszczone w trakcie rozwoju.

Przejrzyj Wytyczne dotyczące współtworzenia.

Indeks tematów dotyczących projektowania systemów

Podsumowania różnych tematów związanych z projektowaniem systemów, w tym zalety i wady. Wszystko jest kompromisem.
>
Każda sekcja zawiera linki do bardziej szczegółowych materiałów.


Przewodnik do nauki

Zalecane tematy do przeglądu w zależności od terminu rozmowy kwalifikacyjnej (krótki, średni, długi).

Imgur

P: Czy na rozmowę kwalifikacyjną muszę znać wszystko z tej listy?

O: Nie, nie musisz znać wszystkiego, aby przygotować się do rozmowy kwalifikacyjnej.

O co zostaniesz zapytany na rozmowie zależy od takich czynników jak:

Od bardziej doświadczonych kandydatów zazwyczaj oczekuje się większej wiedzy o projektowaniu systemów. Architekci lub liderzy zespołów mogą być zobowiązani do szerszej wiedzy niż pojedynczy członkowie zespołu. Najlepsze firmy technologiczne prawdopodobnie przeprowadzą jedną lub więcej rund rozmów o projektowaniu systemów.

Zacznij szeroko i pogłęb się w kilku obszarach. Pomaga znać podstawy różnych kluczowych zagadnień z zakresu projektowania systemów. Dostosuj poniższy przewodnik do swojego harmonogramu, doświadczenia, stanowisk na które aplikujesz oraz firm, z którymi masz rozmowy.

| | Krótki | Średni | Długi | |---|---|---|---| | Przeczytaj Tematy projektowania systemów, aby uzyskać szerokie zrozumienie działania systemów | :+1: | :+1: | :+1: | | Przeczytaj kilka artykułów z Blogów inżynierskich firm, do których aplikujesz | :+1: | :+1: | :+1: | | Przejrzyj kilka Architektur rzeczywistych systemów | :+1: | :+1: | :+1: | | Przejrzyj Jak podejść do pytania z projektowania systemu | :+1: | :+1: | :+1: | | Przećwicz Pytania z rozmów z projektowania systemów wraz z rozwiązaniami | Kilka | Wiele | Większość | | Przećwicz Pytania z rozmów z projektowania obiektowego wraz z rozwiązaniami | Kilka | Wiele | Większość | | Przejrzyj Dodatkowe pytania z rozmów o projektowaniu systemów | Kilka | Wiele | Większość |

Jak podejść do pytania z projektowania systemu

Jak zmierzyć się z pytaniem na rozmowie o projektowaniu systemu.

Rozmowa z projektowania systemu to otwarta dyskusja. Oczekuje się, że to Ty ją poprowadzisz.

Możesz skorzystać z poniższych kroków, aby poprowadzić rozmowę. Aby utrwalić ten proces, przejdź sekcję Pytania z rozmów z projektowania systemów wraz z rozwiązaniami korzystając z tych kroków.

Krok 1: Określ przypadki użycia, ograniczenia i założenia

Zbierz wymagania i określ zakres problemu. Zadawaj pytania, aby wyjaśnić przypadki użycia i ograniczenia. Omów założenia.

Krok 2: Stwórz projekt na wysokim poziomie

Przedstaw projekt na wysokim poziomie ze wszystkimi istotnymi komponentami.

Krok 3: Zaprojektuj główne komponenty

Przejdź do szczegółów każdego kluczowego komponentu. Na przykład, jeśli poproszono Cię o zaprojektowanie usługi skracania URL, omów:

Krok 4: Skalowanie projektu

Zidentyfikuj i rozwiąż wąskie gardła, biorąc pod uwagę ograniczenia. Na przykład, czy potrzebujesz poniższych rozwiązań, aby rozwiązać problemy ze skalowalnością?

Omów potencjalne rozwiązania i kompromisy. Wszystko jest kompromisem. Rozwiązuj wąskie gardła, wykorzystując zasady projektowania skalowalnych systemów.

Szacowania „na szybko”

Możesz zostać poproszony o wykonanie szacowań ręcznych. Zajrzyj do Aneksu, gdzie znajdziesz następujące materiały:

Źródła i dalsza lektura

Zapoznaj się z poniższymi linkami, aby lepiej zrozumieć, czego się spodziewać:

Pytania z rozmów kwalifikacyjnych z projektowania systemów wraz z rozwiązaniami

Typowe pytania z rozmów kwalifikacyjnych z projektowania systemów wraz z przykładami dyskusji, kodem i diagramami.
>
Rozwiązania powiązane z zawartością w folderze solutions/.

| Pytanie | | |---|---| | Zaprojektuj Pastebin.com (lub Bit.ly) | Rozwiązanie | | Zaprojektuj linię czasu i wyszukiwanie na Twitterze (lub Facebook feed i wyszukiwanie) | Rozwiązanie | | Zaprojektuj crawler internetowy | Rozwiązanie | | Zaprojektuj Mint.com | Rozwiązanie | | Zaprojektuj struktury danych dla sieci społecznościowej | Rozwiązanie | | Zaprojektuj magazyn klucz-wartość dla wyszukiwarki | Rozwiązanie | | Zaprojektuj funkcję rankingów sprzedaży według kategorii Amazon | Rozwiązanie | | Zaprojektuj system skalujący się do milionów użytkowników na AWS | Rozwiązanie | | Dodaj pytanie z projektowania systemu | Współtwórz |

Zaprojektuj Pastebin.com (lub Bit.ly)

Zobacz ćwiczenie i rozwiązanie

Imgur

Zaprojektuj linię czasu i wyszukiwanie na Twitterze (lub Facebook feed i wyszukiwanie)

Zobacz ćwiczenie i rozwiązanie

Imgur

Zaprojektuj crawler internetowy

Zobacz ćwiczenie i rozwiązanie

Imgur

Design Mint.com

View exercise and solution

Imgur

Design the data structures for a social network

View exercise and solution

Imgur

Design a key-value store for a search engine

View exercise and solution

Imgur

Design Amazon's sales ranking by category feature

View exercise and solution

Imgur

Design a system that scales to millions of users on AWS

View exercise and solution

Imgur

Object-oriented design interview questions with solutions

Common object-oriented design interview questions with sample discussions, code, and diagrams.
>
Solutions linked to content in the solutions/ folder.

>Note: This section is under development

| Question | | |---|---| | Zaprojektuj tablicę mieszającą (hash map) | Rozwiązanie | | Zaprojektuj pamięć podręczną najmniej używanych danych (LRU cache) | Rozwiązanie | | Zaprojektuj centrum obsługi połączeń | Rozwiązanie | | Zaprojektuj talię kart | Rozwiązanie | | Zaprojektuj parking | Rozwiązanie | | Zaprojektuj serwer czatu | Rozwiązanie | | Zaprojektuj tablicę cykliczną | Wnieś swój wkład | | Dodaj pytanie z zakresu projektowania obiektowego | Wnieś swój wkład |

Tematy projektowania systemów: zacznij tutaj

Nowy w projektowaniu systemów?

Najpierw musisz mieć podstawową wiedzę na temat powszechnych zasad, dowiedzieć się czym są, jak się ich używa oraz poznać ich zalety i wady.

Krok 1: Zapoznaj się z wykładem wideo o skalowalności

Wykład o skalowalności na Harvardzie

Krok 2: Zapoznaj się z artykułem o skalowalności

Skalowalność

Kolejne kroki

Następnie przyjrzymy się kompromisom na wysokim poziomie:

Pamiętaj, że wszystko jest kompromisem.

Potem przejdziemy do bardziej szczegółowych tematów, takich jak DNS, CDN i load balancery.

Wydajność vs skalowalność

Usługa jest skalowalna, jeśli powoduje wzrost wydajności proporcjonalny do dodanych zasobów. Zazwyczaj zwiększenie wydajności oznacza obsługę większej liczby jednostek pracy, ale może też oznaczać obsługę większych jednostek pracy, np. gdy rosną zbiory danych.1

Inny sposób spojrzenia na wydajność vs skalowalność:

Źródła i dalsza lektura

Opóźnienie vs przepustowość

Opóźnienie to czas potrzebny na wykonanie jakiejś akcji lub uzyskanie wyniku.

Przepustowość to liczba takich akcji lub wyników w jednostce czasu.

Zasadniczo należy dążyć do maksymalnej przepustowości przy akceptowalnym opóźnieniu.

Źródła i dalsza lektura

Dostępność vs spójność

Twierdzenie CAP


Źródło: CAP theorem revisited

W rozproszonym systemie komputerowym można zapewnić tylko dwie z poniższych gwarancji:

Sieci nie są niezawodne, więc trzeba zapewnić odporność na podziały. Konieczny będzie kompromis programistyczny pomiędzy spójnością a dostępnością.

#### CP – spójność i odporność na podziały

Oczekiwanie na odpowiedź od podzielonego węzła może skutkować błędem przekroczenia czasu oczekiwania. CP jest dobrym wyborem, jeśli wymagania biznesowe wymagają atomowych odczytów i zapisów.

#### AP – dostępność i odporność na podziały

Odpowiedzi zwracają najłatwiej dostępną wersję danych na dowolnym węźle, która może nie być najnowsza. Zapisy mogą wymagać czasu na propagację po rozwiązaniu podziału.

AP jest dobrym wyborem, jeśli wymagania biznesowe dopuszczają ostateczną spójność lub gdy system musi działać mimo błędów zewnętrznych.

Źródła i dalsza lektura

Wzorce spójności

Przy wielu kopiach tych samych danych musimy zdecydować, jak je synchronizować, aby klienci mieli spójny widok danych. Przypomnijmy definicję spójności z twierdzenia CAP – Każdy odczyt otrzymuje najnowszy zapis lub błąd.

Słaba spójność (Weak consistency)

Po zapisie odczyty mogą go widzieć lub nie. Stosuje się podejście „najlepszych starań”.

To podejście występuje w systemach takich jak memcached. Słaba spójność sprawdza się w zastosowaniach czasu rzeczywistego, takich jak VoIP, czat wideo i gry wieloosobowe w czasie rzeczywistym. Na przykład, jeśli podczas rozmowy telefonicznej utracisz zasięg na kilka sekund, po odzyskaniu połączenia nie usłyszysz tego, co zostało powiedziane podczas utraty połączenia.

Spójność ostateczna

Po zapisie, odczyty ostatecznie go zobaczą (zazwyczaj w ciągu milisekund). Dane są replikowane asynchronicznie.

To podejście jest stosowane w systemach takich jak DNS i poczta elektroniczna. Spójność ostateczna dobrze sprawdza się w systemach o wysokiej dostępności.

Spójność silna

Po zapisie, odczyty go zobaczą. Dane są replikowane synchronicznie.

To podejście jest stosowane w systemach plików i relacyjnych bazach danych (RDBMS). Spójność silna dobrze sprawdza się w systemach wymagających transakcji.

Źródło(ła) i dalsza lektura

Wzorce dostępności

Istnieją dwa komplementarne wzorce wspierające wysoką dostępność: przełączanie awaryjne i replikacja.

Przełączanie awaryjne

#### Aktywny-pasywny

W przełączaniu awaryjnym aktywny-pasywny, między serwerem aktywnym a pasywnym (w trybie gotowości) są wysyłane sygnały kontrolne (heartbeat). Jeśli sygnał zostanie przerwany, serwer pasywny przejmuje adres IP aktywnego i wznawia usługę.

Długość przestoju zależy od tego, czy serwer pasywny działa już w trybie „gorącej” gotowości, czy musi uruchomić się z „zimnej” gotowości. Tylko serwer aktywny obsługuje ruch.

Przełączanie awaryjne aktywny-pasywny może być również nazywane przełączaniem awaryjnym master-slave.

#### Aktywny-aktywny

W przełączaniu aktywny-aktywny oba serwery obsługują ruch, rozkładając obciążenie między sobą.

Jeśli serwery są dostępne publicznie, DNS musi znać publiczne adresy IP obu serwerów. Jeśli serwery są dostępne wewnętrznie, logika aplikacji musi znać oba serwery.

Przełączanie awaryjne aktywny-aktywny może być również nazywane przełączaniem awaryjnym master-master.

Wada(y): przełączanie awaryjne

Replikacja

#### Master-slave i master-master

Ten temat jest szczegółowo omówiony w sekcji Baza danych:

Dostępność w liczbach

Dostępność jest często wyrażana jako procent czasu działania (lub przestoju), w którym usługa jest dostępna. Dostępność zwykle mierzy się liczbą dziewiątek--usługa o dostępności 99,99% jest określana jako mająca cztery dziewiątki.

#### 99,9% dostępności - trzy dziewiątki

| Okres | Akceptowalny czas przestoju| |----------------------|----------------------------| | Przestój rocznie | 8h 45min 57s | | Przestój miesięcznie | 43m 49,7s | | Przestój tygodniowo | 10m 4,8s | | Przestój dziennie | 1m 26,4s |

#### 99,99% dostępności - cztery dziewiątki

| Okres | Akceptowalny czas przestoju| |----------------------|----------------------------| | Przestój rocznie | 52min 35,7s | | Przestój miesięcznie | 4m 23s | | Przestój tygodniowo | 1m 5s | | Przestój dziennie | 8,6s |

#### Dostępność równoległa vs sekwencyjna

Jeśli usługa składa się z kilku komponentów podatnych na awarie, całkowita dostępność zależy od tego, czy komponenty są połączone sekwencyjnie czy równolegle.

###### Sekwencyjnie Ogólna dostępność maleje, gdy dwa komponenty o dostępności < 100% są połączone szeregowo:

Availability (Total) = Availability (Foo) * Availability (Bar)

Jeśli zarówno Foo, jak i Bar miałyby dostępność na poziomie 99,9%, ich łączna dostępność w sekwencji wynosiłaby 99,8%.

###### Równolegle

Całkowita dostępność wzrasta, gdy dwa komponenty o dostępności < 100% są połączone równolegle:

Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))
Jeśli zarówno Foo, jak i Bar miałyby dostępność na poziomie 99,9%, ich łączna dostępność w trybie równoległym wynosiłaby 99,9999%.

System nazw domenowych


Źródło: Prezentacja o bezpieczeństwie DNS

System nazw domenowych (DNS) tłumaczy nazwę domeny, taką jak www.example.com, na adres IP.

DNS jest hierarchiczny, z kilkoma autorytatywnymi serwerami na najwyższym poziomie. Twój router lub dostawca internetu (ISP) dostarcza informacje o tym, z jakim(i) serwerem(i) DNS się łączyć podczas wyszukiwania. Niższe poziomy serwerów DNS przechowują w pamięci podręcznej mapowania, które mogą się zdezaktualizować z powodu opóźnień propagacji DNS. Wyniki DNS mogą być również buforowane przez Twoją przeglądarkę lub system operacyjny przez określony czas, ustalany przez parametr time to live (TTL).

Usługi takie jak CloudFlare i Route 53 oferują zarządzane usługi DNS. Niektóre usługi DNS mogą kierować ruchem na różne sposoby:

Wada(-y): DNS

Źródła i dalsza lektura

Sieć dostarczania treści


Źródło: Dlaczego warto używać CDN

Sieć dostarczania treści (CDN) to globalnie rozproszona sieć serwerów proxy, która udostępnia treści z lokalizacji bliższych użytkownikowi. Zazwyczaj z CDN serwowane są pliki statyczne, takie jak HTML/CSS/JS, zdjęcia i filmy, chociaż niektóre CDN-y, jak Amazon CloudFront, obsługują także treści dynamiczne. Rozwiązanie DNS strony wskaże klientom, z którym serwerem się połączyć.

Serwowanie treści z CDN znacząco poprawia wydajność na dwa sposoby:

Push CDN

Push CDN otrzymuje nowe treści za każdym razem, gdy nastąpią zmiany na Twoim serwerze. Bierzesz pełną odpowiedzialność za dostarczanie treści, przesyłając je bezpośrednio do CDN i przepisując adresy URL tak, aby wskazywały na CDN. Możesz skonfigurować, kiedy treść wygasa i kiedy jest aktualizowana. Treść jest przesyłana tylko gdy jest nowa lub zmieniona, minimalizując ruch, ale maksymalizując zużycie miejsca.

Strony z niewielkim ruchem lub takie, których treść rzadko się zmienia, dobrze współpracują z Push CDN. Treść jest umieszczana na CDN tylko raz, zamiast być ponownie pobieraną w regularnych odstępach czasu.

Pull CDN

Pull CDN pobiera nowe treści z Twojego serwera, gdy pierwszy użytkownik zażąda tej treści. Pozostawiasz treść na swoim serwerze i przepisujesz adresy URL, aby wskazywały na CDN. Powoduje to wolniejsze żądanie, dopóki treść nie zostanie zapisana w pamięci podręcznej CDN.

Parametr time-to-live (TTL) określa, jak długo treść jest przechowywana w pamięci podręcznej. Pull CDN minimalizuje wykorzystanie przestrzeni na CDN, ale może generować zbędny ruch, jeśli pliki wygasną i zostaną pobrane, zanim rzeczywiście się zmienią.

Strony z dużym ruchem dobrze współpracują z Pull CDN, ponieważ ruch jest równomierniej rozłożony, a na CDN pozostaje tylko niedawno żądana treść.

Wady: CDN

Źródła i dalsza lektura

Load balancer


Źródło: Wzorce projektowe skalowalnych systemów

Load balancery rozdzielają przychodzące żądania klientów na zasoby obliczeniowe, takie jak serwery aplikacyjne i bazy danych. W każdym przypadku load balancer zwraca odpowiedź z zasobu obliczeniowego do odpowiedniego klienta. Load balancery są skuteczne w:

Load balancery mogą być implementowane sprzętowo (drogo) lub programowo, np. za pomocą HAProxy.

Dodatkowe korzyści obejmują:

Aby zabezpieczyć się przed awariami, powszechne jest stosowanie wielu load balancerów, w trybie active-passive lub active-active.

Load balancery mogą kierować ruch na podstawie różnych metryk, w tym:

Load balancing warstwy 4

Load balancery warstwy 4 analizują informacje na warstwie transportowej, aby zdecydować, jak rozdzielić żądania. Zazwyczaj obejmuje to źródłowe i docelowe adresy IP oraz porty w nagłówku, ale nie zawartość pakietu. Load balancery warstwy 4 przekazują pakiety sieciowe do i z serwera nadrzędnego, wykonując Translację Adresów Sieciowych (NAT).

Load balancing warstwy 7

Load balancery warstwy 7 analizują warstwę aplikacji, aby zdecydować, jak rozdzielić żądania. Może to obejmować zawartość nagłówka, wiadomości i ciasteczek. Load balancery warstwy 7 kończą ruch sieciowy, odczytują wiadomość, podejmują decyzję o rozkładzie obciążenia, a następnie otwierają połączenie z wybranym serwerem. Na przykład, load balancer warstwy 7 może kierować ruch wideo do serwerów hostujących filmy, podczas gdy bardziej wrażliwy ruch związany z rozliczeniami użytkowników przekierowywać na serwery wzmocnione pod względem bezpieczeństwa.

Kosztem elastyczności, load balancing warstwy 4 wymaga mniej czasu i zasobów obliczeniowych niż warstwy 7, chociaż wpływ na wydajność może być minimalny na współczesnym sprzęcie klasy konsumenckiej.

Skalowanie horyzontalne

Load balancery mogą również pomagać w skalowaniu horyzontalnym, poprawiając wydajność i dostępność. Skalowanie za pomocą maszyn klasy konsumenckiej jest bardziej opłacalne i skutkuje wyższą dostępnością niż rozbudowa pojedynczego serwera na droższym sprzęcie, nazywana skalowaniem wertykalnym. Łatwiej jest również zatrudnić specjalistów pracujących na sprzęcie konsumenckim niż do systemów korporacyjnych wymagających specjalizacji.

#### Wada(y): skalowanie horyzontalne

Wada(y): load balancer

Źródła i dalsza lektura

Reverse proxy (serwer WWW)


Źródło: Wikipedia

Reverse proxy to serwer WWW, który centralizuje usługi wewnętrzne i zapewnia jednolite interfejsy dla użytkowników zewnętrznych. Żądania od klientów są przekazywane do serwera, który może je obsłużyć, zanim reverse proxy zwróci odpowiedź serwera do klienta.

Dodatkowe korzyści obejmują:

Load balancer vs reverse proxy

Wady: reverse proxy

Źródła i dalsza lektura

Warstwa aplikacji


Źródło: Wprowadzenie do architektury systemów dla skalowalności

Oddzielenie warstwy webowej od warstwy aplikacyjnej (znanej również jako warstwa platformowa) umożliwia skalowanie i konfigurowanie obu warstw niezależnie. Dodanie nowego API powoduje dodanie serwerów aplikacyjnych bez konieczności dodawania dodatkowych serwerów webowych. Zasada pojedynczej odpowiedzialności opowiada się za małymi i autonomicznymi usługami współpracującymi ze sobą. Małe zespoły z małymi usługami mogą agresywniej planować szybki wzrost.

Pracownicy w warstwie aplikacyjnej pomagają również umożliwić asynchroniczność.

Mikrousługi

Powiązane z tą dyskusją są mikrousługi, które można opisać jako zestaw niezależnie wdrażalnych, małych, modułowych usług. Każda usługa działa jako unikalny proces i komunikuje się przez dobrze zdefiniowany, lekki mechanizm, aby realizować cel biznesowy. 1

Pinterest, na przykład, może posiadać następujące mikrousługi: profil użytkownika, obserwujący, kanał, wyszukiwarka, przesyłanie zdjęć itd.

Odkrywanie usług

Systemy takie jak Consul, Etcd, oraz Zookeeper mogą pomagać usługom odnajdywać się nawzajem poprzez śledzenie zarejestrowanych nazw, adresów i portów. Kontrole zdrowia pomagają weryfikować integralność usług i często są wykonywane przy użyciu punktu końcowego HTTP. Zarówno Consul jak i Etcd posiadają wbudowany magazyn klucz-wartość, który może być użyteczny do przechowywania wartości konfiguracyjnych i innych współdzielonych danych.

Wady: warstwa aplikacyjna

Źródła i dalsza lektura

Baza danych


Źródło: Skalowanie do pierwszych 10 milionów użytkowników

Relacyjny system zarządzania bazą danych (RDBMS)

Relacyjna baza danych, taka jak SQL, to zbiór danych zorganizowanych w tabelach.

ACID to zbiór właściwości transakcji relacyjnych baz danych.

Istnieje wiele technik skalowania relacyjnych baz danych: replikacja master-slave, replikacja master-master, federacja, sharding, denormalizacja oraz optymalizacja SQL.

#### Replikacja master-slave

Master obsługuje operacje odczytu i zapisu, replikując zapisy do jednego lub więcej slave’ów, które obsługują tylko odczyty. Slave’y mogą replikować się do kolejnych slave’ów w strukturze drzewiastej. Jeśli master przestanie działać, system może nadal działać w trybie tylko do odczytu, aż slave zostanie awansowany na mastera lub zostanie utworzony nowy master.


Źródło: Skalowalność, dostępność, stabilność, wzorce

##### Wada(y): replikacja master-slave

#### Replikacja master-master

Oba master’y obsługują odczyty i zapisy oraz koordynują się nawzajem przy zapisach. Jeśli którykolwiek z master’ów przestanie działać, system może nadal obsługiwać zarówno odczyty, jak i zapisy.


Źródło: Skalowalność, dostępność, stabilność, wzorce

##### Wada(y): replikacja master-master

##### Wady: replikacja

##### Źródła i dalsza lektura: replikacja

#### Federacja


Źródło: Skalowanie do pierwszych 10 milionów użytkowników

Federacja (lub partycjonowanie funkcjonalne) dzieli bazy danych według funkcji. Na przykład zamiast pojedynczej, monolitycznej bazy danych, możesz mieć trzy bazy: fora, użytkownicy i produkty, co skutkuje mniejszym ruchem odczytu i zapisu dla każdej bazy, a tym samym mniejszym opóźnieniem replikacji. Mniejsze bazy danych pozwalają na przechowywanie większej ilości danych w pamięci, co z kolei prowadzi do większej liczby trafień w cache dzięki poprawionej lokalności. Brak centralnego mastera serializującego zapisy umożliwia wykonywanie zapisów równolegle, zwiększając przepustowość.

##### Wady: federacja

##### Źródła i dalsza lektura: federacja

#### Sharding


Źródło: Skalowalność, dostępność, stabilność, wzorce

Sharding (dzielenie na fragmenty) rozprowadza dane pomiędzy różne bazy danych, tak że każda baza może zarządzać tylko podzbiorem danych. Na przykładzie bazy użytkowników, gdy liczba użytkowników rośnie, do klastra dodawane są kolejne shard'y.

Podobnie jak zalety federacji, sharding powoduje mniejszy ruch odczytu i zapisu, mniej replikacji i więcej trafień do cache. Zmniejsza się również rozmiar indeksu, co generalnie poprawia wydajność przez szybsze zapytania. Jeśli jeden shard przestanie działać, pozostałe nadal funkcjonują, choć warto wdrożyć jakąś formę replikacji, by uniknąć utraty danych. Podobnie jak w federacji, nie ma jednego centralnego mastera serializującego zapisy, co pozwala na równoległe zapisy i większą przepustowość.

Typowe metody dzielenia tabeli użytkowników to np. według pierwszej litery nazwiska lub lokalizacji geograficznej użytkownika.

##### Wady: sharding

##### Źródła i dalsza lektura: sharding

#### Denormalizacja

Denormalizacja stara się poprawić wydajność odczytu kosztem wydajności zapisu. Redundantne kopie danych zapisywane są w wielu tabelach, by uniknąć kosztownych połączeń (joinów). Niektóre systemy RDBMS, jak PostgreSQL czy Oracle wspierają widoki materializowane, które zajmują się przechowywaniem redundantnych informacji i utrzymywaniem ich spójności.

Gdy dane zostaną rozproszone za pomocą takich technik jak federacja i sharding, zarządzanie joinami pomiędzy centrami danych staje się jeszcze bardziej złożone. Denormalizacja może obejść potrzebę takich skomplikowanych joinów.

W większości systemów odczyty znacznie przewyższają zapisy, nawet w stosunku 100:1 czy 1000:1. Odczyt wymagający złożonego połączenia bazodanowego może być bardzo kosztowny, zajmując znaczną część czasu na operacje dyskowe.

##### Wady: denormalizacja

###### Źródła i dalsza lektura: denormalizacja

#### Optymalizacja SQL

Optymalizacja SQL to szeroki temat, do którego powstało wiele książek jako źródło referencyjne.

Ważne jest, aby przeprowadzać benchmarking i profilowanie, aby symulować oraz wykrywać wąskie gardła.

Benchmarking i profilowanie mogą wskazać następujące optymalizacje.

##### Uściślij schemat

##### Używaj dobrych indeksów

##### Unikaj kosztownych złączeń

##### Partycjonuj tabele

##### Dostrój pamięć podręczną zapytań

##### Źródła i dalsza lektura: optymalizacja SQL

NoSQL

NoSQL to zbiór elementów danych reprezentowanych jako magazyn klucz-wartość, magazyn dokumentów, magazyn szerokich kolumn lub baza danych grafowa. Dane są zdenormalizowane, a łączenia zwykle wykonywane są w kodzie aplikacji. Większość baz NoSQL nie oferuje prawdziwych transakcji ACID i preferuje spójność ostateczną.

BASE jest często używany do opisu właściwości baz danych NoSQL. W porównaniu z Teorią CAP, BASE wybiera dostępność ponad spójność.

Oprócz wyboru między SQL a NoSQL, warto zrozumieć, który typ bazy NoSQL najlepiej pasuje do Twojego przypadku użycia. W kolejnej sekcji omówimy magazyny klucz-wartość, magazyny dokumentów, magazyny szerokich kolumn oraz bazy danych grafowe.

#### Magazyn klucz-wartość

Abstrakcja: tablica mieszająca

Magazyn klucz-wartość zazwyczaj umożliwia odczyty i zapisy w czasie O(1) i często jest oparty na pamięci RAM lub SSD. Magazyny danych mogą utrzymywać klucze w porządku leksykograficznym, co pozwala na efektywne pobieranie zakresów kluczy. Magazyny klucz-wartość mogą pozwalać na przechowywanie metadanych wraz z wartością.

Magazyny klucz-wartość zapewniają wysoką wydajność i są często używane dla prostych modeli danych lub szybko zmieniających się danych, takich jak warstwa pamięci podręcznej w pamięci operacyjnej. Ponieważ oferują tylko ograniczony zestaw operacji, złożoność jest przenoszona do warstwy aplikacji, jeśli wymagane są dodatkowe operacje.

Magazyn klucz-wartość jest podstawą dla bardziej złożonych systemów, takich jak magazyn dokumentów, a w niektórych przypadkach baza danych grafowa.

##### Źródła i dalsza lektura: magazyn klucz-wartość

#### Magazyn dokumentów

Abstrakcja: magazyn klucz-wartość z dokumentami przechowywanymi jako wartości

Magazyn dokumentów koncentruje się wokół dokumentów (XML, JSON, binarne itd.), gdzie dokument przechowuje wszystkie informacje dotyczące danego obiektu. Magazyny dokumentów udostępniają API lub język zapytań do wyszukiwania na podstawie wewnętrznej struktury samego dokumentu. Uwaga, wiele magazynów klucz-wartość zawiera funkcje do pracy z metadanymi wartości, co zaciera granice między tymi dwoma typami magazynowania.

W zależności od implementacji dokumenty są organizowane według kolekcji, tagów, metadanych lub katalogów. Chociaż dokumenty mogą być organizowane lub grupowane razem, pola w dokumentach mogą się całkowicie różnić od siebie.

Niektóre magazyny dokumentów, takie jak MongoDB oraz CouchDB, udostępniają język zbliżony do SQL umożliwiający wykonywanie złożonych zapytań. DynamoDB obsługuje zarówno klucz-wartość, jak i dokumenty.

Magazyny dokumentów oferują wysoką elastyczność i są często używane do pracy z danymi zmieniającymi się okazjonalnie.

##### Źródła i dalsza lektura: magazyn dokumentów

#### Magazyn szerokokolumnowy


Źródło: SQL & NoSQL, krótka historia

Abstrakcja: zagnieżdżona mapa ColumnFamily>

Podstawową jednostką danych magazynu szerokokolumnowego jest kolumna (para nazwa/wartość). Kolumny mogą być grupowane w rodziny kolumn (analogicznie do tabeli SQL). Super-rodziny kolumn dodatkowo grupują rodziny kolumn. Dostęp do każdej kolumny można uzyskać niezależnie za pomocą klucza wiersza, a kolumny o tym samym kluczu wiersza tworzą wiersz. Każda wartość zawiera znacznik czasu do wersjonowania i rozwiązywania konfliktów.

Google wprowadziło Bigtable jako pierwszy magazyn szerokokolumnowy, który wpłynął na otwartoźródłowe HBase często używane w ekosystemie Hadoop oraz Cassandra od Facebooka. Magazyny takie jak BigTable, HBase i Cassandra utrzymują klucze w porządku leksykograficznym, co pozwala na efektywne pobieranie wybranych zakresów kluczy.

Magazyny szerokokolumnowe oferują wysoką dostępność i skalowalność. Często używane są do bardzo dużych zbiorów danych.

##### Źródła i dalsza lektura: magazyn szerokokolumnowy

#### Baza danych grafowa


Źródło: Baza danych grafowa

Abstrakcja: graf

W bazie danych grafowej każdy węzeł to rekord, a każda krawędź to relacja między dwoma węzłami. Bazy danych grafowe są zoptymalizowane do reprezentowania złożonych zależności z wieloma kluczami obcymi lub relacjami wiele-do-wielu.

Bazy grafowe oferują wysoką wydajność dla modeli danych z rozbudowanymi relacjami, jak w sieciach społecznościowych. Są stosunkowo nowe i nie są jeszcze szeroko stosowane; może być trudniej znaleźć narzędzia programistyczne i zasoby. Wiele grafów można uzyskać tylko przez REST API.

##### Źródła i dalsza lektura: graf

#### Źródła i dalsza lektura: NoSQL

SQL czy NoSQL


Źródło: Przechodzenie z RDBMS na NoSQL

Powody wyboru SQL:

Powody wyboru NoSQL:

Przykładowe dane dobrze pasujące do NoSQL:

##### Źródła i dalsza lektura: SQL czy NoSQL

Cache


Źródło: Wzorce projektowe skalowalnych systemów

Buforowanie poprawia czas ładowania strony i może zmniejszyć obciążenie serwerów oraz baz danych. W tym modelu dispatcher najpierw sprawdza, czy żądanie zostało już wcześniej wykonane i próbuje znaleźć poprzedni wynik do zwrotu, aby zaoszczędzić faktyczne wykonanie.

Bazy danych często korzystają z równomiernego rozkładu odczytów i zapisów między partycjami. Popularne elementy mogą zaburzać ten rozkład, powodując wąskie gardła. Umieszczenie bufora przed bazą danych może pomóc w absorbowaniu nierównomiernych obciążeń i skoków ruchu.

Buforowanie po stronie klienta

Bufory mogą być zlokalizowane po stronie klienta (system operacyjny lub przeglądarka), po stronie serwera lub w oddzielnej warstwie bufora.

Buforowanie CDN

CDN-y są uznawane za rodzaj bufora.

Buforowanie serwera WWW

Reverse proxy oraz bufory takie jak Varnish mogą obsługiwać bezpośrednio treści statyczne i dynamiczne. Serwery WWW mogą także buforować żądania, zwracając odpowiedzi bez kontaktu z serwerami aplikacji.

Buforowanie bazy danych

Twoja baza danych zazwyczaj zawiera pewien poziom buforowania w domyślnej konfiguracji, zoptymalizowanej dla ogólnego przypadku użycia. Dostosowanie tych ustawień do konkretnych wzorców użytkowania może dodatkowo zwiększyć wydajność.

Buforowanie aplikacji

Bufory w pamięci RAM, takie jak Memcached i Redis, to magazyny klucz-wartość pomiędzy aplikacją a magazynem danych. Ponieważ dane przechowywane są w RAM, dostęp do nich jest znacznie szybszy niż w typowych bazach, gdzie dane znajdują się na dysku. RAM jest bardziej ograniczony niż dysk, dlatego algorytmy inwalidacji bufora takie jak najrzadziej używane (LRU)) pomagają usuwać „zimne” wpisy i trzymać „gorące” dane w RAM.

Redis oferuje następujące dodatkowe funkcje:

Istnieje kilka poziomów buforowania, które dzielą się na dwie ogólne kategorie: zapytania do bazy danych i obiekty:

Zazwyczaj należy unikać buforowania na plikach, ponieważ utrudnia to klonowanie i automatyczne skalowanie.

Buforowanie na poziomie zapytań do bazy danych

Za każdym razem, gdy wykonujesz zapytanie do bazy danych, zhashuj zapytanie jako klucz i zapisz wynik w pamięci podręcznej. To podejście ma problemy z wygasaniem:

Buforowanie na poziomie obiektów

Traktuj swoje dane jako obiekt, podobnie jak robisz to w kodzie aplikacji. Niech aplikacja złoży zestaw danych z bazy do instancji klasy lub struktury danych:

Propozycje, co buforować:

Kiedy aktualizować bufor

Ponieważ można przechowywać ograniczoną ilość danych w pamięci podręcznej, trzeba określić, która strategia aktualizacji bufora najlepiej pasuje do Twojego przypadku użycia.

#### Cache-aside (bufor pośredni)


Źródło: From cache to in-memory data grid

Aplikacja odpowiada za odczyt i zapis z/do magazynu. Bufor nie komunikuje się bezpośrednio z magazynem. Aplikacja wykonuje następujące kroki:

def get_user(self, user_id):
    user = cache.get("user.{0}", user_id)
    if user is None:
        user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
        if user is not None:
            key = "user.{0}".format(user_id)
            cache.set(key, json.dumps(user))
    return user

Memcached jest zazwyczaj używany w ten sposób.

Kolejne odczyty danych dodanych do pamięci podręcznej są szybkie. Cache-aside nazywane jest również leniwym ładowaniem. Do pamięci podręcznej trafiają tylko żądane dane, co zapobiega zapełnieniu jej niepotrzebnymi informacjami.

##### Wada(-y): cache-aside

#### Write-through


Źródło: Skalowalność, dostępność, stabilność, wzorce

Aplikacja wykorzystuje pamięć podręczną jako główny magazyn danych, odczytując i zapisując w niej dane, podczas gdy pamięć podręczna odpowiada za odczyt i zapis do bazy danych:

Kod aplikacji:

set_user(12345, {"foo":"bar"})

Kod pamięci podręcznej:

def set_user(user_id, values):
    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
    cache.set(user_id, user)
Write-through to ogólnie wolna operacja ze względu na operację zapisu, ale kolejne odczyty właśnie zapisanych danych są szybkie. Użytkownicy zazwyczaj są bardziej tolerancyjni na opóźnienia podczas aktualizacji danych niż podczas ich odczytu. Dane w pamięci podręcznej nie są nieaktualne.

##### Wada(y): write-through

#### Write-behind (write-back)


Źródło: Scalability, availability, stability, patterns

W write-behind aplikacja wykonuje następujące czynności:

##### Wada(y): write-behind

#### Refresh-ahead


Źródło: From cache to in-memory data grid

Możesz skonfigurować pamięć podręczną, aby automatycznie odświeżała każdy ostatnio używany wpis przed jego wygaśnięciem.

Refresh-ahead może skutkować niższą latencją w porównaniu do read-through, jeśli pamięć podręczna potrafi dokładnie przewidzieć, które elementy będą potrzebne w przyszłości.

##### Wada(y): refresh-ahead

Wada(y): cache

Źródło(a) i dalsza lektura

Asynchroniczność


Źródło: Wprowadzenie do architektury systemów na skalę

Asynchroniczne przepływy pracy pomagają skrócić czas odpowiedzi na kosztowne operacje, które w przeciwnym razie byłyby wykonywane synchronicznie. Mogą również pomóc wykonując czasochłonne zadania z wyprzedzeniem, takie jak okresowa agregacja danych.

Kolejki wiadomości

Kolejki wiadomości odbierają, przechowują i dostarczają wiadomości. Jeśli operacja jest zbyt wolna, by wykonać ją synchronicznie, można użyć kolejki wiadomości zgodnie z poniższym schematem:

Użytkownik nie jest blokowany, a zadanie jest przetwarzane w tle. W tym czasie klient może opcjonalnie wykonać drobne przetwarzanie, by sprawiać wrażenie, że zadanie zostało zakończone. Przykładowo, przy publikowaniu tweeta, tweet może zostać natychmiast dodany do Twojej osi czasu, ale może minąć trochę czasu, zanim dotrze do wszystkich Twoich obserwujących.

Redis jest przydatny jako prosty broker wiadomości, ale wiadomości mogą zostać utracone.

RabbitMQ jest popularny, ale wymaga dostosowania się do protokołu 'AMQP' i samodzielnego zarządzania węzłami. Amazon SQS jest usługą hostowaną, ale może charakteryzować się dużym opóźnieniem oraz możliwością dwukrotnego dostarczenia wiadomości.

Kolejki zadań

Kolejki zadań odbierają zadania wraz z powiązanymi danymi, wykonują je, a następnie dostarczają wyniki. Mogą wspierać harmonogramowanie i są używane do uruchamiania zasobożernych obliczeń w tle.

Celery posiada wsparcie dla harmonogramowania i przede wszystkim obsługuje język Python.

Presja zwrotna

Jeśli kolejki zaczną znacząco rosnąć, ich rozmiar może przekroczyć pojemność pamięci, skutkując nietrafieniami do pamięci podręcznej, odczytami z dysku oraz jeszcze wolniejszym działaniem. Presja zwrotna pomaga poprzez ograniczenie rozmiaru kolejki, utrzymując wysoką przepustowość i dobre czasy odpowiedzi dla już oczekujących zadań. Po zapełnieniu kolejki klient otrzymuje informację o zajętości serwera lub kod HTTP 503, by spróbować ponownie później. Klient może powtórzyć żądanie później, na przykład stosując eksponencjalne opóźnienie.

Wada(-y): asynchroniczność

Źródła i dalsza lektura

Komunikacja


Źródło: Model OSI 7 warstw

Protokół przesyłania hipertekstu (HTTP)

HTTP to metoda kodowania i przesyłania danych między klientem a serwerem. Jest to protokół żądanie/odpowiedź: klient wysyła żądania, a serwer odpowiada odpowiednimi danymi oraz informacją o statusie realizacji żądania. HTTP jest niezależny, pozwala na przekazywanie żądań i odpowiedzi przez wiele pośrednich routerów i serwerów realizujących równoważenie obciążenia, buforowanie, szyfrowanie i kompresję.

Podstawowe żądanie HTTP składa się z czasownika (metody) i zasobu (endpointu). Poniżej przedstawiono typowe czasowniki HTTP:

| Czasownik | Opis | Idempotentny* | Bezpieczny | Buforowalny |

| GET | Odczytuje zasób | Tak | Tak | Tak | | POST | Tworzy zasób lub uruchamia proces obsługujący dane | Nie | Nie | Tak, jeśli odpowiedź zawiera informację o świeżości | | PUT | Tworzy lub zastępuje zasób | Tak | Nie | Nie | | PATCH | Częściowo aktualizuje zasób | Nie | Nie | Tak, jeśli odpowiedź zawiera informację o świeżości | | DELETE | Usuwa zasób | Tak | Nie | Nie |

*Można wywołać wiele razy bez różnych rezultatów.

HTTP to protokół warstwy aplikacji opierający się na niższych protokołach takich jak TCP i UDP.

#### Źródło(-a) i dalsza lektura: HTTP

Protokół kontroli transmisji (TCP)


Źródło: How to make a multiplayer game

TCP to protokół połączeniowy działający na sieci IP. Połączenie jest ustanawiane i kończone za pomocą handshake. Wszystkie wysłane pakiety mają gwarancję dotarcia do celu w oryginalnej kolejności i bez uszkodzeń dzięki:

Jeśli nadawca nie otrzyma poprawnej odpowiedzi, ponownie wysyła pakiety. Jeśli wystąpi wiele przekroczeń czasu, połączenie jest zrywane. TCP implementuje także kontrolę przepływu) oraz kontrolę przeciążenia. Te gwarancje powodują opóźnienia i generalnie skutkują mniej wydajną transmisją niż UDP.

Aby zapewnić wysoką przepustowość, serwery WWW mogą utrzymywać dużą liczbę otwartych połączeń TCP, co skutkuje dużym zużyciem pamięci. Utrzymywanie wielu otwartych połączeń między wątkami serwera WWW a np. serwerem memcached może być kosztowne. Pule połączeń mogą pomóc, podobnie jak przejście na UDP tam, gdzie to możliwe.

TCP jest przydatny dla aplikacji wymagających wysokiej niezawodności, ale mniej krytycznych czasowo. Przykłady to serwery WWW, informacje z baz danych, SMTP, FTP i SSH.

Użyj TCP zamiast UDP, gdy:

Protokół datagramów użytkownika (UDP)


Źródło: Jak stworzyć grę wieloosobową

UDP jest bezpołączeniowy. Datagramy (analogiczne do pakietów) są gwarantowane tylko na poziomie pojedynczego datagramu. Datagramy mogą dotrzeć do celu w niewłaściwej kolejności lub wcale. UDP nie obsługuje kontroli przeciążenia. Bez gwarancji oferowanych przez TCP, UDP jest na ogół bardziej wydajny.

UDP umożliwia rozgłaszanie, wysyłając datagramy do wszystkich urządzeń w podsieci. Jest to użyteczne przy DHCP, ponieważ klient nie otrzymał jeszcze adresu IP, co uniemożliwia TCP przesyłanie strumieniowe bez adresu IP.

UDP jest mniej niezawodny, ale sprawdza się w zastosowaniach czasu rzeczywistego, takich jak VoIP, czat wideo, streaming i gry wieloosobowe w czasie rzeczywistym.

Użyj UDP zamiast TCP gdy:

#### Źródło(-a) i dalsza lektura: TCP i UDP

Zdalne wywołanie procedury (RPC)


Źródło: Crack the system design interview

W RPC klient powoduje wykonanie procedury w innym obszarze adresowym, zwykle na zdalnym serwerze. Procedura jest kodowana tak, jakby była lokalnym wywołaniem procedury, ukrywając szczegóły komunikacji z serwerem przed programem klienckim. Zdalne wywołania są zwykle wolniejsze i mniej niezawodne niż lokalne wywołania, dlatego warto odróżniać wywołania RPC od lokalnych. Popularne frameworki RPC to Protobuf, Thrift oraz Avro.

RPC jest protokołem żądanie-odpowiedź:

Przykładowe wywołania RPC:

GET /someoperation?data=anId
POST /anotheroperation
{
  "data":"anId";
  "anotherdata": "another value"
}

RPC koncentruje się na udostępnianiu zachowań. RPC są często używane ze względów wydajnościowych w komunikacji wewnętrznej, ponieważ można ręcznie dostosować natywne wywołania do własnych przypadków użycia.

Wybierz natywną bibliotekę (czyli SDK), gdy:

HTTP API zgodne z REST są częściej używane jako publiczne API.

#### Wada(y): RPC

Representational state transfer (REST)

REST to styl architektoniczny wymuszający model klient/serwer, w którym klient operuje na zestawie zasobów zarządzanych przez serwer. Serwer dostarcza reprezentację zasobów i akcje, które mogą manipulować lub pobierać nową reprezentację zasobów. Cała komunikacja musi być bezstanowa i możliwa do buforowania.

RESTful interfejs ma cztery cechy:

Przykładowe wywołania REST:

GET /someresources/anId
PUT /someresources/anId
{"anotherdata": "another value"}
REST koncentruje się na udostępnianiu danych. Minimalizuje sprzężenie między klientem a serwerem i jest często używany do publicznych HTTP API. REST stosuje bardziej ogólną i jednolitą metodę udostępniania zasobów poprzez URI, reprezentację przez nagłówki oraz akcje poprzez czasowniki takie jak GET, POST, PUT, DELETE i PATCH. Jako bezstanowy, REST świetnie nadaje się do skalowania horyzontalnego i partycjonowania.

#### Wada(y): REST

Porównanie wywołań RPC i REST

| Operacja | RPC | REST | |---|---|---| | Rejestracja | POST /signup | POST /persons | | Rezygnacja | POST /resign
{
"personid": "1234"
} | DELETE /persons/1234 | | Odczyt osoby | GET /readPerson?personid=1234 | GET /persons/1234 | | Odczyt listy przedmiotów osoby | GET /readUsersItemsList?personid=1234 | GET /persons/1234/items | | Dodanie przedmiotu do listy osoby | POST /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | POST /persons/1234/items
{
"itemid": "456"
} | | Aktualizacja przedmiotu | POST /modifyItem
{
"itemid": "456";
"key": "value"
} | PUT /items/456
{
"key": "value"
} | | Usunięcie przedmiotu | POST /removeItem
{
"itemid": "456"
} | DELETE /items/456 |

Źródło: Czy naprawdę wiesz, dlaczego preferujesz REST nad RPC

#### Źródło(a) i dalsza lektura: REST i RPC

Bezpieczeństwo

Ta sekcja wymaga aktualizacji. Rozważ wniesienie wkładu!

Bezpieczeństwo to szeroki temat. Jeśli nie masz dużego doświadczenia, wykształcenia w zakresie bezpieczeństwa lub nie aplikujesz na stanowisko wymagające wiedzy z zakresu bezpieczeństwa, prawdopodobnie wystarczy Ci znajomość podstaw:

Źródła i dalsza lektura

Dodatek

Czasem zostaniesz poproszony o wykonanie szacunków „na szybko”. Na przykład możesz potrzebować określić, ile czasu zajmie wygenerowanie 100 miniatur obrazów z dysku lub ile pamięci zajmie struktura danych. Tabela potęg dwójki oraz Liczby opóźnień, które każdy programista powinien znać to przydatne odniesienia.

Tabela potęg dwójki

Power           Exact Value         Approx Value        Bytes
---------------------------------------------------------------
7                             128
8                             256
10                           1024   1 thousand           1 KB
16                         65,536                       64 KB
20                      1,048,576   1 million            1 MB
30                  1,073,741,824   1 billion            1 GB
32                  4,294,967,296                        4 GB
40              1,099,511,627,776   1 trillion           1 TB

#### Źródła i dalsza lektura

Liczby opóźnień, które powinien znać każdy programista

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy            10,000   ns       10 us
Send 1 KB bytes over 1 Gbps network     10,000   ns       10 us
Read 4 KB randomly from SSD*           150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
HDD seek                            10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from 1 Gbps  10,000,000   ns   10,000 us   10 ms  40x memory, 10X SSD
Read 1 MB sequentially from HDD     30,000,000   ns   30,000 us   30 ms 120x memory, 30X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms
Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns
Przydatne metryki na podstawie powyższych liczb:

#### Liczby dotyczące opóźnień zobrazowane

#### Źródło(-a) i dalsza lektura

Dodatkowe pytania na rozmowę o projektowaniu systemów

Typowe pytania na rozmowach o projektowaniu systemów, wraz z odnośnikami do zasobów, jak je rozwiązać.

| Pytanie | Odnośnik(i) | |---|---| | Zaprojektuj usługę synchronizacji plików jak Dropbox | youtube.com | | Zaprojektuj wyszukiwarkę jak Google | queue.acm.org
stackexchange.com
ardendertat.com
stanford.edu | | Zaprojektuj skalowalnego web crawlera jak Google | quora.com | | Zaprojektuj Google docs | code.google.com
neil.fraser.name | | Zaprojektuj sklep klucz-wartość jak Redis | slideshare.net | | Zaprojektuj system cache jak Memcached | slideshare.net | | Zaprojektuj system rekomendacji jak Amazon | hulu.com
ijcai13.org | | Zaprojektuj system tinyurl jak Bitly | n00tc0d3r.blogspot.com | | Zaprojektuj aplikację czatu jak WhatsApp | highscalability.com | Zaprojektuj system udostępniania zdjęć jak Instagram | highscalability.com
highscalability.com | | Zaprojektuj funkcję news feed Facebooka | quora.com
quora.com
slideshare.net | | Zaprojektuj funkcję timeline Facebooka | facebook.com
highscalability.com | | Zaprojektuj funkcję czatu Facebooka | erlang-factory.com
facebook.com |

| Zaprojektuj funkcję wyszukiwania grafu jak na Facebooku | facebook.com
facebook.com
facebook.com | | Zaprojektuj sieć dostarczania treści jak CloudFlare | figshare.com | | Zaprojektuj system trendujących tematów jak na Twitterze | michael-noll.com
snikolov .wordpress.com | | Zaprojektuj system generowania losowych identyfikatorów | blog.twitter.com
github.com | | Zwróć k najczęściej żądanych zapytań w określonym przedziale czasu | cs.ucsb.edu
wpi.edu | | Zaprojektuj system obsługujący dane z wielu centrów danych | highscalability.com | | Zaprojektuj internetową grę karcianą multiplayer | indieflashblog.com
buildnewgames.com | | Zaprojektuj system garbage collection | stuffwithstuff.com
washington.edu | | Zaprojektuj ogranicznik zapytań API | https://stripe.com/blog/ | | Zaprojektuj giełdę (np. NASDAQ lub Binance) | Jane Street
Golang Implementation
Go Implementation | | Dodaj pytanie dotyczące projektowania systemu | Contribute |

Architektury rzeczywiste

Artykuły o tym, jak projektowane są rzeczywiste systemy.


Źródło: Twitter timelines at scale

Nie skupiaj się na drobnych szczegółach w poniższych artykułach, zamiast tego:

|Typ | System | Źródło(y) | |---|---|---| | Przetwarzanie danych | MapReduce - Rozproszone przetwarzanie danych od Google | research.google.com | | Przetwarzanie danych | Spark - Rozproszone przetwarzanie danych od Databricks | slideshare.net | | Przetwarzanie danych | Storm - Rozproszone przetwarzanie danych od Twittera | slideshare.net | | | | | | Magazyn danych | Bigtable - Rozproszona baza danych kolumnowa od Google | harvard.edu | | Magazyn danych | HBase - Otwarta implementacja Bigtable | slideshare.net | | Magazyn danych | Cassandra - Rozproszona baza danych kolumnowa od Facebooka | slideshare.net | Magazyn danych | DynamoDB - Baza danych dokumentowa od Amazon | harvard.edu | | Magazyn danych | MongoDB - Baza danych dokumentowa | slideshare.net | | Magazyn danych | Spanner - Globalnie rozproszona baza danych od Google | research.google.com | | Magazyn danych | Memcached - rozproszony system buforowania pamięci | slideshare.net | | Magazyn danych | Redis - rozproszony system buforowania pamięci z trwałością i typami wartości | slideshare.net | | | | | | System plików | Google File System (GFS) - rozproszony system plików | research.google.com | | System plików | Hadoop File System (HDFS) - otwarta implementacja GFS | apache.org | | | | | | Różne | Chubby - serwis blokad dla luźno powiązanych systemów rozproszonych od Google | research.google.com | | Różne | Dapper - infrastruktura śledzenia systemów rozproszonych | research.google.com | Różne | Kafka - kolejka wiadomości pub/sub od LinkedIn | slideshare.net | | Różne | Zookeeper - scentralizowana infrastruktura i usługi umożliwiające synchronizację | slideshare.net | | | Dodaj architekturę | Contribute |

Architektury firm

| Firma | Referencje | |---|---| | Amazon | Amazon architecture | | Cinchcast | Produkcja 1 500 godzin audio każdego dnia | | DataSift | Analiza danych w czasie rzeczywistym przy 120 000 tweetów na sekundę | | Dropbox | Jak skalowaliśmy Dropbox | | ESPN | Przetwarzanie 100 000 duh nuh nuhs na sekundę | | Google | Architektura Google | | Instagram | 14 milionów użytkowników, terabajty zdjęć
Co napędza Instagram | | Justin.tv | Architektura transmisji wideo na żywo Justin.TV | | Facebook | Skalowanie Memcached w Facebooku
TAO: rozproszony magazyn danych Facebooka dla grafu społecznościowego
Przechowywanie zdjęć w Facebooku
Jak Facebook transmituje na żywo do 800 000 jednoczesnych widzów | | Flickr | Architektura Flickr | | Mailbox | Od 0 do miliona użytkowników w 6 tygodni | | Netflix | 360-stopniowy widok całego stosu Netflix
Netflix: Co się dzieje po naciśnięciu „Play”? | | Pinterest | Od 0 do dziesiątek miliardów odsłon miesięcznie
18 milionów odwiedzających, 10x wzrost, 12 pracowników | | Playfish | 50 milionów użytkowników miesięcznie i rośnie | | PlentyOfFish | Architektura PlentyOfFish | | Salesforce | Jak obsługują 1,3 miliarda transakcji dziennie | | Stack Overflow | Architektura Stack Overflow | | TripAdvisor | 40 mln odwiedzających, 200 mln dynamicznych odsłon, 30 TB danych | | Tumblr | 15 miliardów odsłon miesięcznie | | Twitter | Przyspieszenie Twittera o 10 000 procent
Przechowywanie 250 milionów tweetów dziennie za pomocą MySQL
150 mln aktywnych użytkowników, 300 tys. QPS, 22 MB/s firehose
Oś czasu w skali
Duże i małe dane w Twitterze
Operacje w Twitterze: skalowanie ponad 100 milionów użytkowników
Jak Twitter obsługuje 3 000 obrazów na sekundę | | Uber | Jak Uber skaluje swój platformę rynku czasu rzeczywistego
Wnioski z skalowania Ubera do 2000 inżynierów, 1000 usług i 8000 repozytoriów Git | | WhatsApp | Architektura WhatsApp, którą Facebook kupił za 19 miliardów dolarów | | YouTube | Skalowalność YouTube
Architektura YouTube |

Firmowe blogi inżynierskie

Architektury firm, z którymi prowadzisz rozmowy kwalifikacyjne.
>
Pytania, z którymi się spotkasz, mogą pochodzić z tej samej dziedziny.

#### Źródło(-a) i dalsza lektura

Chcesz dodać bloga? Aby uniknąć powielania pracy, rozważ dodanie bloga swojej firmy do następującego repozytorium:

W trakcie rozwoju

Chcesz dodać sekcję lub pomóc ukończyć jedną z rozpoczętych? Wnieś swój wkład!

Podziękowania

Podziękowania i źródła są podane w całym repozytorium.

Szczególne podziękowania dla:

Informacje kontaktowe

Zapraszam do kontaktu w celu omówienia wszelkich problemów, pytań lub uwag.

Moje dane kontaktowe znajdziesz na mojej stronie GitHub.

Licencja

Kod i zasoby w tym repozytorium udostępniam na licencji open source. Ponieważ jest to moje osobiste repozytorium, licencja na mój kod i zasoby jest udzielana przeze mnie, a nie przez mojego pracodawcę (Facebook).

Copyright 2017 Donne Martin

Creative Commons Attribution 4.0 International License (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/

--- Tranlated By Open Ai Tx | Last indexed: 2025-08-09 ---

Original README: View on GitHub

Translated by OpenAiTx | Last updated: 2025-09-16