Understanding Consistency Models in Distributed Systems, Slides de Sistemas Distribuídos

Baixe Understanding Consistency Models in Distributed Systems e outras Slides em PDF para Sistemas Distribuídos, somente na Docsity!

Consistency and

Replication

Why Replicate Data?

 Enhance reliability.

Improve performance.

But: if there are many replicas of the same

thing, how do we keep all of them up-to-

date? How do we keep the replicas

consistent?

Consistency can be achieved in a number of

ways.

We will study a number of consistency

models , as well as protocols for implementing

the models.

Concurrent Object Access:

Problem

 (^) Organization of a distributed remote object shared by two different clients. But, how do we protect the object in the presence of multiple simultaneous access?

5

Concurrent Object Access:

Solutions

a) A remote object capable of handling concurrent invocations on its own. b) A remote object for which an object adapter is required to handle concurrent invocations (relies on middleware).

Replication and Scalability

 (^) Replication is a widely-used scalability technique: think of web clients and web proxies.  (^) When systems scale, the first problems to surface are those associated with performance – as the systems get bigger (e.g., more users), they get often slower.  (^) Replicating the data and moving it closer to where it is needed helps to solve this scalability problem.  (^) A problem remains: how to efficiently synchronize all of the replicas created to solve the scalability issue?  (^) Dilemma: adding replicas improves scalability, but incurs the (oftentimes considerable) overhead of keeping the replicas up- to-date!!!  (^) As we shall see, the solution often results in a relaxation of any consistency constraints.

Data-Centric Consistency

Models

 (^) A data-store can be read from or written to by any process in a distributed system.  (^) A local copy of the data-store (replica) can support “fast reads”.  (^) However, a write to a local replica needs to be propagated to all remote replicas.

• (^) Various consistency models help to understand the various mechanisms used to achieve and enable this.

Consistency Model Diagram

Notation

 W

i

(x)a – a write by process ‘i’ to item ‘x’

with a value of ‘a’. That is, ‘x’ is set to ‘a’.

 (Note: The process is often shown as ‘P

i

 R

i

(x)b – a read by process ‘i’ from item ‘x’

producing the value ‘b’. That is, reading ‘x’

returns ‘b’.

Time moves from left to right in all

diagrams.

Strict Consistency Diagrams

 (^) Behavior of two processes, operating on the same data item: a) A strictly consistent data-store. b) A data-store that is not strictly consistent.

• (^) With Strict Consistency , all writes are instantaneously visible to all processes and absolute global time order is maintained throughout the DS. This is the consistency model “Holy Grail” – not at all easy in the real world, and all but impossible within a DS.
• (^) So, other, less strict (or “weaker”) models have been developed …

Sequential Consistency Diagrams a) A sequentially consistent data-store – the “first” write occurred after the “second” on all replicas. b) A data-store that is not sequentially consistent – it appears the writes have occurred in a non-sequential order, and this is NOT allowed. In other words: all processes see the same interleaving set of operations, regardless of what that interleaving is.

Problem with Sequential

Consistency

With this consistency model, adjusting the

protocol to favour reads over writes (or

vice-versa) can have a devastating impact

on performance (refer to the textbook for

the gory details).

For this reason, other weaker consistency

models have been proposed and developed.

Again, a relaxation of the rules allows for

these weaker models to make sense.

Linearizability and Sequential Consistency (2)  (^) Four valid execution sequences for the processes of the previous slide. The vertical axis is time. x = 1; print ((y, z); y = 1; print (x, z); z = 1; print (x, y); Prints: 001011 Signature: 001011 (a) x = 1; y = 1; print (x,z); print(y, z); z = 1; print (x, y); Prints: 101011 Signature: 101011 (b) y = 1; z = 1; print (x, y); print (x, z); x = 1; print (y, z); Prints: 010111 Signature: 110101 (c) y = 1; x = 1; z = 1; print (x, z); print (y, z); print (x, y); Prints: 111111 Signature: 111111 (d) But, for instance, 001001 is not allowed.

Causal Consistency

This model distinguishes between events

that are “causally related” and those that

are not.

If event B is caused or influenced by an

earlier event A, then causal consistency

requires that every other process see event

A, then event B.

Operations that are not causally related are

said to be concurrent.

19

Another Causal Consistency

Example

a) Violation of causal-consistency – P2’s write is related to P1’s write due to the read on ‘x’ giving ‘a’ (all processes must see them in the same order). b) A causally-consistent data-store: the read has been removed, so the two writes are now concurrent. The reads by P3 and P are now OK. incorrect correct

FIFO Consistency

 (^) Defined as follows: Writes done by a single process are seen by all other processes in the order in which they were issued, but writes from different processes may be seen in a different order by different processes.  (^) This is also called “PRAM Consistency” – Pipelined RAM.  The attractive characteristic of FIFO is that it is easy to implement. There are no guarantees about the order in which different processes see writes – except that two or more writes from a single process must be seen in order.