Hacki do projektowania systemu:

1. ) Napisz ciężki system — Odniesienie-1 , Odniesienie-2
2. ) Odczyt ciężkiego systemu — Odniesienie-1 , Odniesienie-2
3. ) Twierdzenie CAP -

5.) AP (dostępność z tolerancją partycji) — Cassandra, Dynamo, CouchDB, Riak, Elastic Search, MongoDB (replikacja).

6.) CA (spójność z dostępnością) - MySQL, Postgres.

Krótkie notatki referencyjne:

MongoDB — MongoDB jest domyślnie bardzo spójny — jeśli wykonasz zapis, a następnie odczyt, zakładając, że zapis się powiódł, zawsze będziesz mógł odczytać wynik właśnie przeczytanego zapisu. Dzieje się tak, ponieważ MongoDB jest systemem z jednym wzorcem i wszystkie odczyty domyślnie przechodzą do podstawowego. Jeśli opcjonalnie włączysz odczyt z elementów pomocniczych, MongoDB ostatecznie stanie się spójny tam, gdzie możliwe jest odczytanie nieaktualnych wyników. MongoDB uzyskuje również wysoką dostępność dzięki automatycznemu przełączaniu awaryjnemu w zestawach replik:http://www.mongodb.org/display/DOCS/Replica+Sets

Gwarancje spójności klastra Redis —

Klaster Redis nie gwarantuje silnej spójności. W praktyce oznacza to, że w pewnych warunkach klaster Redis może utracić zapisy, które zostały potwierdzone przez system do klienta.

Pierwszym powodem, dla którego klaster Redis może utracić zapisy, jest użycie replikacji asynchronicznej. Oznacza to, że podczas zapisywania dzieje się:

Twój klient pisze do mistrza B.

Master B odpowiada klientowi OK.

Master B propaguje zapis do swoich replik B1, B2 i B3.

Jak widać, B nie czeka na potwierdzenie od B1, B2, B3 przed udzieleniem odpowiedzi klientowi, ponieważ byłaby to zaporowa kara za opóźnienie dla Redis, więc jeśli twój klient coś napisze, B potwierdza zapis, ale ulega awarii przed będąc w stanie wysłać zapis do swoich replik, jedna z replik (która nie otrzymała zapisu) może zostać awansowana do roli głównej, tracąc zapis na zawsze.

W Redis wysoka dostępność to coś więcej niż tolerancja partycji. Redis ma architekturę Master Slave, a jeśli Master zawiedzie, Redis Sentinels promuje Slave jako nowego Master, dzięki czemu całe rozwiązanie jest wysoce dostępne. A master może zawieść (lub stać się niedostępny) z wielu powodów (np. brak pamięci), niekoniecznie z powodu partycji sieciowej.

Następnie pojawia się przypadek partycji sieciowej (P), a jeśli nastąpi (P), Redis staje się niedostępny w partycji mniejszościowej. Dlatego z perspektywy CAP Redis jest CP, ponieważ staje się niedostępny w zaborach mniejszościowych. Pamiętaj, że nadal będzie dostępny w podziale większościowym.

Więcej informacji na temat wysokiej dostępności Redis można znaleźć tutaj . Szczegółowe informacje na temat partycjonowania można znaleźć w akapicie zatytułowanym „Spójność w ramach partycji”.

Redis jest również nazywany ostatecznie spójnym, ponieważ gdy nastąpi (P), podział mniejszościowy jest nadal dostępny przez kilka sekund, a wszelkie zapisy wykonane w tym okresie na układzie mniejszościowym zostaną ostatecznie odrzucone.

Kasandra — kliknij tutaj