1. 第5讲 一致性与复制 §5.1 副本管理 Replica Management §5.2 一致性模型 Consistency Models
§5.3 一致性协议 Consistency Protocols

2. Why Replication?
For Reliability
For Scalability
Number, location

3. Major Issues in Replication
Replica placement
Tradeoff between access benefit and update cost
Consistency among replicas
Consistency models
Consistency protocols

4. §5.1 Replica Management
To decide where, when, and by whom replicas should be placed
Replica Server Placement
Finding the best locations for replica servers
Data Content Placement
Finding the best servers for placing content
To distribute content to replicas

5. Replica Server Placement
K out of N locations
Client-aware method: high complexity
Objective function: average distance between clients and servers
Client-unaware method: lower than previous, but still high complexity
Assuming clients are uniformly distributed
Greedy: choose routers with the largest links
Region-based method: low complexity
A region is identified to be a collection of nodes accessing the same content, but for which the internode latency is low.

6. Region-based method The entire space is partitioned into cells.
The K most dense cells are then chosen.

7. Data Content Placement
Initial (Seed) replicas
Statically configured
Temporary replicas
Dynamically placed by server
Data “caches”
Managed by clients

8. Server-initiated Replicas
Two issues
To reduce the load of servers – near server
To reduce the access delay at clients – near client

9. Client-initiated Replicas
Client determine what to cache
Servers may be involved for consistency
Caches may be shared by more than one clients

10. Content Distribution To propagate update to replica servers
What to distribute
1. Propagate only a notification of an update.
2. Transfer data from one copy to another.
3. Propagate the update operation to other copies

11. Content Distribution How to distribute
Push: suitable for permanent/server-initiated replicas
High read-to-update ratio
Pull: suitable for caches
Low read-to-update ratio
Lease-based: hybrid of push + pull

12. §5.2 Consistency Models Consistency Model “Correctly”:
A contract between processes and the data store.
It says that: if processes obey certain rules, the store promises to work correctly.
“Correctly”:
If a process performs a read operation on a data item, the operation should return a value that shows the results of the last write operation on that data.
Which is the last write, without global clock?
Defines the values that a read operation can return.
Tradeoff between consistency level and maintenance cost

13. Consistency Models Data-centric consistency models
Continuous consistency (Data content consistency)
Update order consistency
Sequential consistency
Causal consistency
Grouping operations
Client-centric consistency models
Monotonic reads
Monotonic writes
Read your writes
Writes follow reads

14. Continuous Consistency
Inconsistencies
Deviation in numerical values between replicas
Deviation in staleness between replicas
Deviation with respect to the ordering of update operations
Consistency Unit (Conit)
the unit of in consistency maintenance.
E.g. a record of a single stock.
Fine-grained vs. Coarse-grained

15. Sequential Consistency
Notations
Definition: the result of any execution is the same as if
the (read and write) operations by all processes on the data store were executed in some sequential order and
the operations of each individual process appear in this sequence in the order specified by its program

16. Sequential Consistency
No “time” in the definition of sequential consistency model
A operation sequence is valid provided that all processes see the same sequence.
Figure 7-5. (a) A sequentially consistent data store (b) A NOT sequentially consistent data store.

17. Sequential Consistency

18. Causal Consistency Definition Recall “Causality”
Writes that are potentially causally related must be seen by all processes in the same order.
Concurrent writes may be seen in a different order on different machines.
Recall “Causality”
If event b is caused or influenced by an earlier event a,
Everyone else should first see a, then see b.
Weaker than sequential consistency

19. Causal Consistency
Figure 7-8. A causally-consistent sequence but not sequentially consistent

20. Causal Consistency
Is the operation sequence causally consistent?

21. Grouping Operations
Operation consistency with mutual exclusion mechanism
The consistency granularity is higher
Critical section: a group of reads and writes.
Operation:
Synchronization variables (locks)
Acquire  Read/Write  Release
ENTER_CS, R(), W(), R(),…, LEAVE_CS

22. Grouping Operations
At an acquire, all remote changes to the guarded data must be made visible.
An acquire access of a synchronization variable is not allowed to perform until all updates to guarded shared data have been performed with respect to that process.
The update of a shared data item should be done in critical section with exclusive mode
Before exclusive mode access to synchronization variable by process is allowed to perform with respect to that process, no other process may hold synchronization variable, not even in nonexclusive mode.
If a process wants to enter a critical region in nonexclusive mode, it must first check with the owner of the synchronization variable
After exclusive mode access to synchronization variable has been performed, any other process’ next nonexclusive mode access to that synchronization variable may not be performed until it has performed with respect to that variable’s owner.
Figure A valid event sequence for entry consistency

23. Client-centric Consistency Models
Weaker than data-centric ones
Assuming restricted concurrency
E.g.
A database may be rarely updated
Few write-write conflicts
A database may be updated by only a special process
No write-write conflicts
Users may allow a quite high degree of inconsistency
E.g. web pages

24. Eventual Consistency Suitable for Key point:
(large-scale) distributed and replicated databases that tolerate a relatively high degree of inconsistency.
Key point:
If no updates take place for a long time, all replicas will gradually become consistent.
( In the absence of updates, all replicas converge toward identical copies of each other. )
Eventual consistency essentially requires only that:
updates are guaranteed to propagate to all replicas.

25. Eventual Consistency
Figure Inconsistency in eventually consistent database

26. Client-centric Consistency
To avoid inconsistency in eventually consistent systems
Key point:
Provides guarantees for a single client concerning the consistency of accesses to a data store by that client.
No guarantees are given concerning concurrent accesses by different clients.
Four Models
Monotonic reads
Monotonic writes
Read your writes
Writes follow reads

27. Monotonic Reads
If a process reads the value of a data item x, then any successive read operation on x by that process will always return that same value or a more recent value.
( if a process has seen a value of x at time t, it will never see an older version of x at a later time.)
E.g. mail service

28. Monotonic Reads
Has an earlier update done at the new location?

29. Monotonic Writes
A write operation by a process on a data item x is completed before any successive write operation on x by the same process.
(If need be, the new write must wait for old ones to finish.)
E.g. software library

30. Monotonic Writes

31. Read Your Writes
The effect of a write operation by a process on data item x will always be seen by a successive read operation on x by the same process.
( A write operation is always completed before a successive read operation by the same process, no matter where that read operation takes place.)
E.g. Password changing

32. Read Your Writes

33. Writes Follow Reads
A write operation by a process on a data item x following a previous read operation on x by the same process is guaranteed to take place on the same or a more recent value of x that was read.
(Any successive write operation by a process on a data item x will be performed on a copy of x that is up to date with the value most recently read by that process.)
E.g. bbs, newsgroup

34. Writes Follow Reads

35. §5.3 Consistency Protocols
Data-centric consistency models
Continuous consistency (Data content consistency)
Update order consistency
Sequential consistency
Causal consistency
Grouping operations
Client-centric consistency models
Monotonic reads
Monotonic writes
Read your writes
Writes follow reads

36. Continuous Consistency Protocols
Bounding numerical deviation
When server Sk notices that Si, has not been keeping in the right pace with the updates that have been submitted to Sb it forwards writes from its log to Si.
Bounding stateless deviation
Whenever server Sk notes that T(k) - RVCk[i] is about to exceed a specified limit, it simply starts pulling in writes that originated from S, with a timestamp later than RVCk[i].
Bounding ordering deviations
When the length of this local queue exceeds a specified maximal length, ordering consistency should be enforced.

37. Update Order Consistency Protocols
Primary-based Protocols
Remote-write
Local-write
Replicated-write Protocols
Active replication
Quorum-based

38. Remote-write Protocol

39. Local-write Protocol

40. Active Replication Protocol
The operation is forwarded to all replicas
Operations to be carried out in the same order everywhere
Requires totally ordered multicasts using either Lamport timestamps (e.g.) or a central coordinator.

41. Quorum-Based Protocol

42. Client-centric Consistency Protocols
Simple to achieve
Each write is uniquely identified
Set of writes related to a client is kept
Check before read/write

43. A Summary Concept of replication Key issues in replication
Replica management
Consistency models
Consistency protocols

44. Homework Questions