第 5 讲 一致性与复制

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 • 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? • Consistency Model • 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 • 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 7-10. 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 • (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 7-11. 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