Distribuerede systemer på CBS, 14. september 2017 - transaktioner, del 1

Slide 1

Slide 1 text

Velkommen til min undervisning. Distribuerede systemer på CBS, september 2017, DS-bogens kapitel 16 og 17 plus en vigtig artikel

Slide 2

Slide 2 text

[email protected]. Skriv til mig, hvis I har brug for hjælp.

Slide 3

Slide 3 text

Hvordan fungerer git og GitHub? Det blev jeg spurgt om sidst - og det er et godt spørgsmål.

Slide 4

Slide 4 text

git bruges til versionsstyring og GitHub er en visuel udgave af git.

Slide 5

Slide 5 text

Man pull’er i git for at hente de seneste ændringer.

Slide 6

Slide 6 text

… og man push’er for at lægge sine ændringer op.

Slide 7

Slide 7 text

… og man push’er for at lægge sine ændringer op.

Slide 8

Slide 8 text

Her har jeg skrevet en commit-besked, som kommer med i commit-loggen.

Slide 9

Slide 9 text

Her har jeg committed mine ændringer. De ligger nu lokalt og er ikke skubbet til serveren.

Slide 10

Slide 10 text

… og her har jeg push’et mine ændringer til serveren. Yes!

Slide 11

Slide 11 text

Nogle værktøjer har git-integration indbygget - fx Atom.

Slide 12

Slide 12 text

GitHub har også lavet et program til git, som kan installeres.

Slide 13

Slide 13 text

Vi skal tale om transaktioner. De bliver nemlig brugt hele tiden.

Slide 14

Slide 14 text

Deﬁnitionen fra ordbogen.

Slide 15

Slide 15 text

En transaktion er en behandling af informationer, der enten lykkes eller ikke lykkes. Den generelle deﬁnition inden for IT.

Slide 16

Slide 16 text

Det kunne fx skabe kaos, hvis der ikke blev anvendt transaktioner i banken… Transaktioner er en måde at skabe et forløb på, så behandlinger af data ikke foregår kaotisk.

Slide 17

Slide 17 text

Her læser vi en kontos anløbende og lægger 10% til. Tidspunkt Handling Resultat 12:00 beløb = kontoA.læsBeløb() 1.000 kr. 12:01 kontoA.sætInd(beløb * 1.1) 1.100 kr.

Slide 18

Slide 18 text

Her gør vi det samme igen på samme tid fra en anden maskine. Tidspunkt Handling Resultat 12:00 beløb = kontoA.læsBeløb() 1.000 kr. 12:01 kontoA.sætInd(beløb * 1.1) 1.100 kr. 12:00 beløb = kontoA.læsBeløb() 1.000 kr. 12:01 kontoA.sætInd(beløb * 1.1) 1.100 kr.

Slide 19

Slide 19 text

For at citere DS-bogen for en gangs skyld. Det er det, der hedder the lost update problem.

Slide 20

Slide 20 text

Når to transaktioners operationer giver samme resultat. Sig hej til seriel ækvivalens.

Slide 21

Slide 21 text

Rækkefølgen på to transaktioner må altså ikke være afgørende. We say two operations performed by diﬀerent processes on the same resource conﬂict if the resulting state depends on the order in which they are executed.

Slide 22

Slide 22 text

En-efter-en versus samtidig afvikling. We say that an interleaving of two blocks is serially equivalent, if the result is equivalent to an execution in which one block was executed entirely before the other.

Slide 23

Slide 23 text

Jeg nævnte det jo sidste gang. Lad os bringe det på banen igen. Vi skal tale om atomicitet igen.

Slide 24

Slide 24 text

Et lille tip: flyv direkte. Det kan man jo nu. Du vil gerne til San Francisco. Du beder et rejsebureau om at arrangere din tur. De fortæller at du skal over Chicago. De booker først en billet til Chicago, og finder så ud af at der ikke er flere pladser i flyet derfra til San Francisco - og du ærgrer dig.

Slide 25

Slide 25 text

Drako var en græsk politiker med nogle meget stramme love. Det kunne undgås med en transaktion, der på drakonisk vis enten ville lykkes eller slet ikke.

Slide 26

Slide 26 text

Konflikter kan opstå når der er afhængigheder i rækkefølgen. Operationer i to transaktioner Konflikt Årsag læs læs Nej Effekten af to læse-operationer er ikke afhængig af deres rækkefølge læs skriv Ja Effekten af en læs- og skriv- operationer er afhængig af deres rækkefølge skriv skriv Ja Effekten af en skriv- og skriv- operation er afhængig af deres rækkefølge

Slide 27

Slide 27 text

Microsoft Access er et eksempel på en database som har streng afvikling af instruktioner.

Slide 28

Slide 28 text

Tænk MySQL, PostgreSQL, Oracle og så videre. ACID er et begreb inden for databaser, som står for Atomicity, Consistency, Isolation og Durability.

Slide 29

Slide 29 text

ACID er et stærkt koncept fra den gamle skole inden for databaser. Atomicity Enten virker hele molevitten eller også bliver det droppet. Consistency Sørger for at data er korrekte, fx at en ny række har en primærnøgle. Isolation Sætter lighedstegn mellem samtidig og seriel kørsel af transaktioner. Durability Hvis nu serveren eksploderer, så skal transaktioner kunne overleve - typisk ved at være gemt på disken.

Slide 30

Slide 30 text

At bruge locks og locking er meget udbredt i databaser. Man kan sikre seriel ækvivalens ved fx at låse værdier eller ved at lave wait-for-grafer.

Slide 31

Slide 31 text

Om hvordan det forholder sig med læse- og skrive-låse. Læse-operation Skrive-operation Hvis der ikke er nogen lås OK OK Hvis læse-lås på værdien OK Vent Hvis skrive-lås på værdien Vent Vent

Slide 32

Slide 32 text

Og det kan jo opstå når man bruger låse-mekanismer. Deadlocking er ikke godt.

Slide 33

Slide 33 text

Her er der skabt en deadlock-situation. Transaktion 1 Transaktion 2 Operationer Låse Operationer Låse kontoA.sætInd(200) skrive-lås på konto A kontoB.sætInd(200) skrive-lås på konto B kontoB.læsBeløb() (venter på skrive-låsen på konto B) kontoA.læsBeløb() (venter på skrive-låsen på konto A)

Slide 34

Slide 34 text

Det er essensen af two-phase locking. Hvis en værdi ikke allerede er låst, så lås den. Hvis værdien har en lås i forvejen, der er i konﬂikt med operationen, så vent til låsen fjernes. Hvis værdien har en lås i forvejen, der ikke er i konﬂikt, så fortsæt som planlagt. Hvis værdien allerede er låst i samme transaktion, så forfrem den eventuelt og fortsæt som planlagt.

Slide 35

Slide 35 text

En måde at styre samtidig afvikling på, så det ikke går rabundus. Locking er en form for concurrency control.

Slide 36

Slide 36 text

I kender locking fra dagligdagen.

Slide 37

Slide 37 text

Det kan skabe bedre performance at være optimistisk. Optimistic concurrency control er en antagelse om at ﬂere forskellige transaktioner kan gennemføres uden at påvirke hinanden. Når en transaktion bliver kørt, så foregår det uden brug af locking. Når resultatet af en transaktion bliver gemt, så undersøges hvorvidt de data, den har brug, er blevet ændret i mellemtiden. Hvis ja, så forsøges transaktionen gentaget på ny.

Slide 38

Slide 38 text

Altså: adgang til værdier styres af tidsstempler. Timestamp ordering har som regel at en transaktion ikke må gemme en værdi, der er blevet læst på et senere tidspunkt af en anden transaktion. En transaktion må ikke gemme en værdi, der er blevet gemt på et senere tidspunkt af en anden transaktion. En transaktion må ikke læse en værdi, der er blevet gemt på et senere tidspunkt af en anden transaktion.

Slide 39

Slide 39 text

Det har at gøre med Leslie Lamport. Ham vender vi tilbage til. Et tidsstempel kan være et tidspunkt eller blot en værdi som stiger.

Slide 40

Slide 40 text

Endnu et citat fra bogen. Transactions all limit to some extent the potential for concurrent operation.

Slide 41

Slide 41 text

Fx når en transaktion læser værdier fra et cluster af database-servere. Transaktioner er distribuerede når de anvender værdier fra ﬂere forskellige steder.

Slide 42

Slide 42 text

Nu kommer vi til noget af det, som er virkelig interessant. Med distribuerede transaktioner har vi ﬂere forskellige aktører, og hvem styrer så hvad?

Slide 43

Slide 43 text

Two Generals’ Problem hvor sendebude bliver sendt ud og hjem - og nogen bliver slået ihjel undervejs.

Slide 44

Slide 44 text

Det handler om at lede og fordele ansvar. Der skal være en, der styrer slagets gang. Det skal ikke være den samme altid - turen skal gå på skift. Det kaldes blandt andet for en coordinator role, en log leader eller generelt set log election. Husk at transaktioner skal gemmes og kunne genskabes - det gøres via en log over hvad der er sket.

Slide 45

Slide 45 text

Det er jo nødvendigt at koordinere hændelser i et distribueret system. For at koordinere har vi skabt det, der hedder en two-phase commit protocol.

Slide 46

Slide 46 text

Sådan ser en atomic commit protocol ud. – Er I klar? – Ja, mand! – På hvad? – Næ!

Slide 47

Slide 47 text

Atomic commit protocol, forklaret. Hvis alle melder tilbage med grønt lys, så bliver transaktionen gennemført (commit). Hvis ikke alle melder positivt tilbage, så bliver transaktionen afbrudt (abort/rollback). Hvis en deltager har meldt positivt tilbage og ikke hører mere fra lederen, så er deltageren i en uncertain state.

Slide 48

Slide 48 text

Konsensus vender vi tilbage til senere. Den form for koordinering er et eksempel på konsensus i et distribueret system.

Slide 49

Slide 49 text

Stjålet direkte fra Wikipedia. A fundamental problem in distributed computing is to achieve overall system reliability in the presence of a number of faulty processes. This often requires processes to agree on some data value that is needed during computation. Examples of applications of consensus include whether to commit a transaction to a database, agreeing on the identity of a leader, state machine replication, and atomic broadcasts.

Slide 50

Slide 50 text

Pause.

Slide 51

Slide 51 text

Og når vi stemmer, så er det fordi vi skal opnå konsensus. Demokrati er en form for konsensus i den virkelige verden.

Slide 52

Slide 52 text

Altså hvis en server crasher, fx. Hvad sker der så hvis det hele går op i hat og briller?

Slide 53

Slide 53 text

Evnen til at håndtere og udbedre fejl er essentiel. Transaktioner skal som udgangspunkt være persisteret, altså gemt et sted, så de kan genskabes om nødvendigt. Hvis en server ikke svarer, så kan der anvendes en timeout, som opgiver at få svar efter noget tid. Ergo: et distribueret system skal som minimum kunne håndtere forsinkelser (latency) og nedbrud (failures).

Slide 54

Slide 54 text

Et beslutningsdygtigt ﬂertal. 2/3.

Slide 55

Slide 55 text

Som i livet generelt er det ofte flertallet som bestemmer. Et quorum er et udtryk for et givent flertal, der skal til for at et distribueret system kan overleve nedbrud. Et quorum på to tredjedele betyder at et system med alle noder intakte kan overleve at en tredjedel af dem dør på grund af systemfejl eller lignende. Et quorum kan samtidig anvendes til at løse konflikter omkring data i systemer, der er eventually consistent.

Slide 56

Slide 56 text

Bitcoin er et eksempel på distribuerede transaktioner, der kan overleve nedbrud.

Slide 57

Slide 57 text

Det er humlen i det. Bitcoin har en block chain, som er en stor log over alt det, der er sket.

Slide 58

Slide 58 text

Mine 0,08 Bitcoin ligger altså i block chain’en et sted.

Slide 59

Slide 59 text

Mine 0,08 Bitcoin ligger altså i block chain’en et sted.

Slide 60

Slide 60 text

Hvis ja, hvorfor? Hvad forventer I at få ud af det? Er der nogen af jer, som har købt Bitcoin?

Slide 61

Slide 61 text

Der ﬁndes andre cryptocurrencies, som også bygger på idéen om en block chain.

Slide 62

Slide 62 text

En beskrivelse af Ethereum. Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference. These apps run on a custom-built blockchain, an enormously powerful shared global infrastructure that can move value around and represent the ownership of property. This enables developers to create markets, store registries of debts or promises, move funds in accordance with instructions given long in the past.

Slide 63

Slide 63 text

Yes! Vi skal tilbage til Leslie Lamport.

Slide 64

Slide 64 text

Leslie Lamport er de distribuerede systemers grand old man.

Slide 65

Slide 65 text

Det ser måske kringlet ud, men symbolerne dækker over simple sammenhænge.

Slide 66

Slide 66 text

En tidlig deﬁnition af kausalitetsbegrebet. Leslie Lamport fremsætter i juli 1978 idéen om begivenheder, der er indtruﬀet før hinanden. a → b

Slide 67

Slide 67 text

Et simpelt koncept, egentlig. Han omtaler clocks som en logisk konstruktion, der tæller når en værdi bliver ændret. hvis a → b, så C(a) < C(b)

Slide 68

Slide 68 text

Også det her. Brugen af clocks gør det muligt at opstille en samlet rækkefølge over begivenheder i et distribueret system. a 㱺 b eller Ci(a) < Cj(b) eller Ci(a) = Cj(b) og Pi ≺ Pj

Slide 69

Slide 69 text

Sidstnævnte er en vigtig pointe. Når der er opstillet en samlet rækkefølge for begivenheder i et distribueret system, så kan hver node vedligeholde en liste over hvilke ressourcer, der er ledige hvornår - og sørge for at sende forespørgsler på ressourcer når der er behov for det. Det kræver dog at alle noder kender til hinanden i det distribuerede system.

Slide 70

Slide 70 text

Yes. En node kan få adgang til en ressource når den har en forespørgsel på en ressource i sin liste, og den forespørgsel kommer før andre forespørgsler i henhold til den samlede rækkefølge. a 㱺 b

Slide 71

Slide 71 text

Så måske er det en god idé at anvende rigtige ure i stedet for tilnærmede. Problemet er at en begivenhed kan være vigtig, men hvis den ankommer for sent, så honoreres den reelle rækkefølge ikke.

Slide 72

Slide 72 text

Altså: rigtige ure. I stedet for en værdi, der stiger løbende, så kan der anvendes rigtige ure til at afgøre den reelle rækkefølge af begivenheder i et distribueret system. Det skal selvfølgelig forstås som ure i en computer - og ikke det armbåndsur, du har på armen.

Slide 73

Slide 73 text

Strong clock condition optræder når forsinkelser ikke ændrer i en faktisk rækkefølge. One of the mysteries of the universe is that it is possible to construct a system of physical clocks which, running quite independently of one another, will satisfy the Strong Clock Condition.