Reaktive Programmierung Vorlesung 14 vom 26.06.19 Eventual Consistency

(1)

Reaktive Programmierung Vorlesung 14 vom 26.06.19

Eventual Consistency

Christoph Lüth, Martin Ring

Universität Bremen

Sommersemester 2019

(2)

Fahrplan

I Einführung

I Monaden und Monadentransformer I Nebenläufigkeit: Futures and Promises I Aktoren I: Grundlagen

I Aktoren II: Implementation I Meta-Programmierung

I Bidirektionale Programmierung I Reaktive Ströme I

I Reaktive Ströme II

I Funktional-Reaktive Programmierung I Software Transactional Memory I Eventual Consistency

I Robustheit und Entwurfsmuster

(3)

Heute

I Konsistenzeigenschaften

I Eventual Consistency I CRDTs

I Operational Transformation

I Das Geheimnis von Google Docs und co.

(4)

Was ist eigentlich Konsistenz?

I Konsistenz =Widerspruchsfreiheit I In der Logik:

I Eine Formelmenge Γ ist konsistent wenn:∃A.¬(Γ`A) I In einem verteilten System:

I Redundante (verteilte) Daten I GlobaleWiderspruchsfreiheit?

(5)

Strikte Konsistenz

I Daten sind zu jedem Zeitpunk global konsistent.

I Eine Leseoperation in einem beliebigen Knoten gibt den Wert der letzten globalen Schreiboperation zurück.

I In echten verteilten Systemennicht implementierbar.

(6)

Sequentielle Konsistenz

I Zustand nach verteilter Programmausführung = Zustand nach einer äquivalenten sequentiellen Ausführung in einem Prozess.

I Jeder Prozess sieht die selbe Folge von Operationen.

(7)

Eventual Consistency

Wenn längere Zeitkeine Änderungen stattfinden konvergieren die Daten an jedem Knoten zu einem gemeinsamen Wert.

I Beispiel: DNS

(8)

Strong Eventual Consistency

I Eventual Consistency ist eineinformelleAnforderung.

I Abfragen können beliebige Werte zurückgeben bevor die Knoten konvergieren.

I Keine Sicherheit!

I Strong Eventual Consistencygarantiert:

I wenn zwei Knoten diegleiche (ungeordnete) Mengevon Operationen empfangen haben, befinden sie sich imgleichen Zustand.

I Beispiel: Versionskontrollsystemgit

I Wenn jeder Nutzer seine lokalen Änderungen eingecheckt hat, dann haben alle Nutzer die gleiche Sicht auf denhead.

(9)

Monotonie

I Strong Eventual Consistency kann einfach erreicht werden:

I Nach jedem empfangenen Update alle Daten zurücksetzen.

I Für sinnvolle Anwendungen brauchen wir eine weitere Garantie:

Monotonie

Ein verteiltes System ist monoton, wenn der Effekt jeder Operation erhalten bleibt (keine Rollbacks).

(10)

Beispiel: Texteditor

I Szenario: Webinterface mit Texteditor

I Meherere Nutzer können den Text verändern und sollenimmer die neueste Versionsehen.

I Siehe Google Docs, Etherpad und co.

(11)

Naive Methoden

I Ownership

I Vor Änderungen: Lock-Anfrage an Server

I Nur ein Nutzer kann gleichzeitig das Dokument ändern

I Nachteile: Verzögerungen, Änderungen nur mit Netzverbindung

I Three-Way-Merge

I Server führt nebenläufige Änderungen auf Grundlage einesgemeinsamen Ursprungszusammen.

I Requirement:the chickens must stop moving so we can count them

(12)

Conflict-Free Replicated Data Types

I Konfliktfreie replizierte Datentypen I Garantieren

I Strong Eventual Consistency I Monotonie

I Konfliktfreiheit

I Zwei Klassen:

I Zustandsbasierte CRDTs I Operationsbasierte CRDTs

(13)

Zustandsbasierte CRDTs

I Konvergente replizierte Datentypen (CvRDTs)

I Knoten senden ihren gesamten Zustand an andere Knoten.

I Nur bestimmte Operationen auf dem Datentypen erlaubt (update).

I Einekommutative,assoziative,idempotentemerge-Funktion I Funktioniert gut mit Gossiping-Protokollen

I Nachrichtenverlust unkritisch

(14)

CvRDT: Zähler

I Einfacher CvRDT

I Zustand:P∈N, Datentyp:N query(P) =P

update(P,+,m) =P+m merge(P1,P2) =max(P1,P2)

I Wert kann nur größer werden.

(15)

CvRDT: PN-Zähler

I Gängiges Konzept bei CRDTs: Komposition

I Aus zwei Zählern kann ein komplexerer Typzusammengesetzt werden:

I Zähler P (Positive) und Zähler N (Negative) I Zustand: (P,N)∈N×N, Datentyp:Z

query((P,N)) =query(P)−query(N) update((P,N),+,m) = (update(P,+,m),N) update((P,N),−,m) = (P,update(N,+,m))

merge((P1,N1),(P2,N2)) = (merge(P1,P2),merge(N1,N2))

(16)

CvRDT: Mengen

I Ein weiterer einfacher CRDT:

I Zustand:P∈ P(A), Datentyp:P(A) query(P) =P

update(P,+,a) =P∪ {a}

merge(P₁,P₂) =P₁∪P₂

I Die Menge kann nur wachsen.

(17)

CvRDT: Zwei-Phasen-Mengen

I Durch Komposition kann wieder ein komplexerer Typ entstehen.

I Menge P (Hinzugefügte Elemente) und Menge N (Gelöschte Elemente)

I Zustand: (P,N)∈ P(A)× P(A), Datentyp: P(A) query((P,N)) =query(P)\query(N)

update((P,N),+,m) = (update(P,+,m),N) update((P,N),−,m) = (P,update(N,+,m))

merge((P1,N1),(P2,N2)) = (merge(P1,P2),merge(N1,N2))

(18)

Operationsbasierte CRDTs

I Kommutative replizierte Datentypen (CmRDTs) I Knoten senden nurOperationen an andere Knoten

I update unterscheidete zwischen lokalem und externem Effekt.

I Netzwerkprotokoll wichtig

I Nachrichtenverlust führt zu Inkonsistenzen I Keinmerge nötig

I Kann die übertragenenDatenmengenerheblichreduzieren

(19)

CmRDT: Zähler

I Zustand:P ∈N, Typ: N

I query(P) =P I update(+,n)

I lokal:P:=P+n I extern:P:=P+n

(20)

CmRDT: Last-Writer-Wins-Register

I Zustand: (x,t)∈X ×timestamp

I query((x,t)) =x I update(=,x⁰)

I lokal: (x,t) := (x⁰,now())

I extern:if t<t⁰ then (x,t) := (x⁰,t⁰)

(21)

Vektor-Uhren

I Im LWW Register benötigen wir Timestamps I Kausalität muss erhalten bleiben

I Timestamps müssen eine total Ordnung haben

I Datum und Uhrzeit ungeeignet I Lösung: Vektor-Uhren

I Jeder Knoten hat einen Zähler, der bei Operationen hochgesetzt wird I Zusätzlich merkt sich jeder Knoten den aktuellsten Zählerwert, den er bei

den anderen Knoten beobachtet hat.

(22)

Operational Transformation

I Die CRDTs die wir bis jetzt kennengelernt haben sind recht einfach

I Das Texteditor Beispiel ist damit noch nicht umsetzbar

I Kommutative Operationen auf einer Sequenz von Buchstaben?

I Einfügen möglich (totale Ordnung durch Vektoruhren) I Wie Löschen?

(23)

Operational Transformation

I Idee: Nicht-kommutative Operationen transformieren

•

D f -

D⁰ g0

-

• f⁰ -

g -

I Fürtransform muss gelten:

transform f g =hf⁰,g⁰i=⇒g⁰◦f =f⁰◦g (1) applyOp (g◦f)D =applyOp g (applyOp f D) (2)

(24)

Operationen für Text

Operationen bestehen aus drei Arten von Aktionen:

I Retain— Buchstaben beibehalten I Delete— Buchstaben löschen I Insert c — Buchstabenc einfügen

Eine Operationist eine Sequenz von Aktionen

Ein Beispiel: Eingabe: Ausgabe: Aktionen:

(25)

Operationen für Text

Ein Beispiel:

Eingabe: R 1 P 7 Ausgabe:

Aktionen:

(26)

Ein Beispiel:

Eingabe:

Ausgabe: R P 1 7 Aktionen: Retain, Delete, Retain, Insert 1, Retain.

I Operationen sindpartiell.

(32)

Operationen Komponieren

I Komposition: Fallunterscheidung auf derAktion I Keine einfache Konkatenation!

I Beispiel:

p = [Delete,Insert X,Retain]

q = [Retain,InsertY,Delete]

compose p q = I compose ist partiell.

I Äquivalenzvon Operationen:

compose p q ∼= [Delete,Delete,InsertX,InsertY]

(33)

Operationen Komponieren

I Beispiel:

p = [InsertX,Retain]

q = [Retain,InsertY,Delete]

compose p q = [Delete, I compose ist partiell.

(34)

Operationen Komponieren

I Beispiel:

p = [Retain]

q = [InsertY,Delete]

compose p q = [Delete,Insert X, I compose ist partiell.

(35)

Operationen Komponieren

I Beispiel:

p = [Retain]

q = [Delete]

compose p q = [Delete,Insert X,InsertY, I compose ist partiell.

(36)

Operationen Komponieren

I Beispiel:

p = []

q = []

compose p q = [Delete,Insert X,InsertY,Delete]

I compose ist partiell.

(37)

Operationen Transformieren

I Transformation •

•

a ^-

• b0

-

• a⁰ -

b -

I Beispiel:

a = [Insert X,Retain,Delete]

b = [Delete,Retain,Insert Y]

transform a b = ([

,[ )

(38)

Operationen Transformieren

•

a ^-

• b0

-

• a⁰ -

b -

I Beispiel:

a = [Retain,Delete]

transform a b = ([InsertX, ,[Retain, )

(39)

Operationen Transformieren

•

a ^-

• b0

-

• a⁰ -

b -

I Beispiel:

a = [Delete]

b = [Retain,Insert Y]

transform a b = ([InsertX,Delete, ,[Retain,

)

(40)

Operationen Transformieren

•

a ^-

• b0

-

• a⁰ -

b -

I Beispiel:

a = []

b = [Insert Y]

transform a b = ([InsertX,Delete, ,[Retain,Delete, )

(41)

Operationen Transformieren

•

a ^-

• b0

-

• a⁰ -

b -

I Beispiel:

a = []

b = []

transform a b = ([InsertX,Delete,Retain ,[Retain,Delete,InsertY )

(42)

Operationen Transformieren

•

a ^-

• b0

-

• a⁰ -

b -

I Beispiel:

a = []

b = []

transform a b = ([InsertX,Delete,Retain]

,[Retain,Delete,InsertY]

)

(43)

Operationen Transformieren

•

a ^-

• b0

-

6

c2

- r₂ a⁰ 6

c3

- r₃

Client B •

b

?

(48)

Der Server

I Zweck:

Client A •

c₂⁰ ^- •

c₃⁰ ^- •

Server r₀ c1

- r₁ a

6

c2

- r₂ a⁰ 6

c3

- r₃ a⁰⁰ 6

Client B •

b

?

(49)

Der Server

I Zweck:

Client A •

c₂⁰ ^- •

c₃⁰ ^- •

Server r₀ c1

- r₁ a

6

c2

- r₂ a⁰ 6

c3

- r₃ a⁰⁰ 6

c4=a⁰⁰ - r₄

====

===

Client B •

b

?

(50)

Der Server

I Zweck:

Client A •

c₂⁰ ^- •

c₃⁰ ^- •

Server r₀ c1

- r₁ a

6

c2

- r₂ a⁰ 6

c3

- r₃ a⁰⁰ 6

c4=a⁰⁰ - r₄

====

===

Client B •

b

?

c₃⁰⁰^- • b⁰

?

(51)

Der Server

I Zweck:

Client A •

c₂⁰ ^- •

c₃⁰ ^- •

Server r₀ c1

- r₁ a

6

c2

- r₂ a⁰ 6

c3

- r₃ a⁰⁰ 6

c4=a⁰⁰ - r₄

====

===

Client B •

b

?

c₃⁰⁰^- • b⁰

?

c₄⁰ ^- • b⁰⁰

?

(52)

Der Server

I Zweck:

Client A •

c₂⁰ ^- •

c₃⁰ ^- •

Server r₀ c1

- r₁ a

6

c2

- r₂ a⁰ 6

c3

- r₃ a⁰⁰ 6

c4=a⁰⁰

- r₄ c5=b⁰⁰ -

====

===

r₅

Client B •

b

?

c₃⁰⁰^- • b⁰

?

c₄⁰ ^- • b⁰⁰

?==========

(53)

Der Server

I Zweck:

Client A

Server r₀ c1

- r₁ c2

- r₂ c3

- r₃

Client B

(54)

Der Server

I Zweck:

Client A •

Server r₀ c1

- r₁ a

6

c2

- r₂ c3

- r₃

Client B •

b

?

(55)

Der Server

I Zweck:

Client A •

Server r₀ c1

- r₁ a

6

c2

- r₂ c3

- r₃

Client B •

b

?

c₃⁰⁰^- • b⁰

?

(56)

Der Server

I Zweck:

Client A •

Server r₀ c1

- r₁ a

6

c2

- r₂ c3

- r₃ c4=b⁰ - r₄

Client B •

b

?

c₃⁰⁰^- • b⁰

?==========

(57)

Der Server

I Zweck:

Client A •

c₂⁰ ^- •

Server r₀ c1

- r₁ a

6

c2

- r₂ a⁰ 6

c3

- r₃ c4=b⁰ - r₄

Client B •

b

?

c₃⁰⁰^- • b⁰

?==========

(58)

Der Server

I Zweck:

Client A •

c₂⁰ ^- •

c₃⁰ ^- •

Server r₀ c1

- r₁ a

6

c2

- r₂ a⁰ 6

c3

- r₃ a⁰⁰ 6

c4=b⁰ - r₄

Client B •

b

?

c₃⁰⁰^- • b⁰

?==========

(59)

Der Server

I Zweck:

Client A •

c₂⁰ ^- •

c₃⁰ ^- •

c₄⁰ ^- •

Server r₀ c1

- r₁ a

6

c2

- r₂ a⁰ 6

c3

- r₃ a⁰⁰ 6

c4=b⁰ - r₄

a⁰⁰⁰ 6

Client B •

b

?

c₃⁰⁰^- • b⁰

?==========

(60)

Der Server

I Zweck:

Client A •

c₂⁰ ^- •

c₃⁰ ^- •

c₄⁰ ^- •

Server r₀ c1

- r₁ a

6

c2

- r₂ a⁰ 6

c3

- r₃ a⁰⁰ 6

c4=b⁰ - r₄

a⁰⁰⁰ 6

c5 =a⁰⁰⁰ - r₅

====

===

Client B •

b

?

c₃⁰⁰^- • b⁰

?==========

(61)

Der Client

I Zweck: Operationen Puffern während eine Bestätigung aussteht

• a

- • Revisionr

(62)

Der Client

• a

- • Revision r

• c

? Revision r+ 1

(63)

Der Client

• a

- • Revision r

• c

?

a⁰ ^- • c⁰

? Revision r+ 1

(64)

Der Client

• a

- • Revisionr

(65)

Der Client

• a

- • b

- • Revisionr

(66)

Der Client

• a

- • b

- • Revision r

• c

? Revision r+ 1

(67)

Der Client

• a

- • b

- • Revision r

• c

?

a⁰ ^- • c⁰

? Revision r+ 1

(68)

Der Client

• a

- • b

- • Revision r

• c

?

a⁰ ^- • c⁰

?

b⁰ ^- • c⁰⁰

? Revision r+ 1

(69)

Zusammenfassung

I Strikte Konsistenz in verteilten Systemen nicht erreichbar I Strong Eventual Consistency

I Wennlängere Zeitkeine Änderungen stattgefunden haben befinden sich schließlich alle Knoten imgleichen Zustand.

I Wenn zwei Knoten diegleiche MengeUpdates beobachten befinden sie sich imgleichen Zustand.

I Conflict-Free replicated Data Types:

I Zustandsbasiert: CvRDTs I Operationsbasiert: CmRDTs I Operational Transformation

I Strong Eventual Consistency auch ohne kommutative Operationen