0% found this document useful (0 votes)
22 views73 pages

Chapter 7

The document discusses consistency and replication in distributed systems. It introduces reasons for replication like reliability and performance. It then discusses various consistency models like sequential consistency, linearizability, and causal consistency. It also covers concepts like serializability and transactions. Finally, it discusses consistency models that group operations together like entry consistency.

Uploaded by

Farah osman
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
22 views73 pages

Chapter 7

The document discusses consistency and replication in distributed systems. It introduces reasons for replication like reliability and performance. It then discusses various consistency models like sequential consistency, linearizability, and causal consistency. It also covers concepts like serializability and transactions. Finally, it discusses consistency models that group operations together like entry consistency.

Uploaded by

Farah osman
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 73

Distributed Systems

(4th edition, version 01)

Chapter 07: Consistency and Replication


Consistency and replication Introduction

Replication
Why replicate
Assume a simple model in which we make a copy of a specific part of a system
(meaning code and data).
• Increase reliability: if one copy does not live up to specifications, switch
over to the other copy while repairing the failing one.
• Performance: simply spread requests between different replicated parts
to keep load balanced, or to ensure quick responses by taking proximity
into account.

The problem
Having multiple copies, means that when any copy changes, that change
should be made at all copies: replicas need to be kept the same, that is, be
kept consistent.

Reasons for replication


Consistency and replication Introduction

Performance and scalability


Main issue
To keep replicas consistent, we generally need to ensure that all conflicting
operations are done in the the same order everywhere

Conflicting operations: From the world of transactions


• Read–write conflict: a read operation and a write operation act
concurrently
• Write–write conflict: two concurrent write operations

Issue
Guaranteeing global ordering on conflicting operations may be a costly
operation, downgrading scalability. Solution: weaken consistency requirements
so that hopefully global synchronization can be avoided

Reasons for replication


Consistency and replication Data-centric consistency models

Data-centric consistency models


Consistency model
A contract between a (distributed) data store and processes, in which the data
store specifies precisely what the results of read and write operations are in
the presence of concurrency.

Essential
A data store is a distributed collection of storages:
Consistency and replication Data-centric consistency models

Some notations
Read and write operations
• Wi (x)a: Process Pi writes value a to x
• Ri (x)b: Process Pi reads value b from x
• All data items initially have value NIL

Possible behavior
We omit the index when possible and draw according to time (x-axis):

Consistent ordering of operations


Consistency and replication Data-centric consistency models

Sequential consistency
Definition
The result of any execution is the same as if the operations of all processes
were executed in some sequential order, and the operations of each individual
process appear in this sequence in the order specified by its program.

A sequentially consistent data store

A data store that is not sequentially consistent


Consistent ordering of operations
Consistency and replication Data-centric consistency models

Example
Three concurrent processes (initial values: 0)
Process P1 Process P2 Process P3
x ← 1; y ← 1; z ← 1;
print(y,z); print(x,z); print(x,y);

Consistent ordering of operations


Consistency and replication Data-centric consistency models

Example
Three concurrent processes (initial values: 0)
Process P1 Process P2 Process P3
x ← 1; y ← 1; z ← 1;
print(y,z); print(x,z); print(x,y);

Example execution sequences

Consistent ordering of operations


Consistency and replication Data-centric consistency models

How tricky can it get?


Seemingly okay

Consistent ordering of operations


Consistency and replication Data-centric consistency models

How tricky can it get?


Seemingly okay

But not really (don’t forget that P1 and P2 act concurrently)

Possible ordering of operations Result


W1 (x)a ; W1 (y)a ; W2 (y)b; W2 (x)b R1 (x)b R2 (y)b
W1 (x)a ; W2 (y)b; W1 (y)a ; W2 (x)b R1 (x)b R2 (y )a
W1 (x)a ; W2 (y)b; W2 (x)b ; W1 (y )a R1 (x)b R2 (y )a
W2 (y)b; W1 (x)a ; W1 (y)a ; W2 (x)b R1 (x)b R2 (y )a
W2 (y)b; W1 (x)a ; W2 (x)b ; W1 (y )a R1 (x)b R2 (y )a
W2 (y)b; W2 (x)b ; W1 (x)a ; W1 (y )a R1 (x)a R2 (y )a

Consistent ordering of operations


Consistency and replication Data-centric consistency models

How tricky can it get?


Linearizability
Each operation should appear to take effect instantaneously at some moment
between its start and completion.

Operations complete within a given time (shaded area)

With better results


Possible ordering of operations Result
W1 (x)a ; W2 (y)b; W1 (y)a ; W2 (x)b R1 (x)b R2 (y )a
W1 (x)a ; W2 (y)b; W2 (x)b; W1 (y)a R1 (x)b R2 (y )a
W2 (y)b; W1 (x)a ; W1 (y)a ; W2 (x)b R1 (x)b R2 (y )a
W2 (y)b; W1 (x)a ; W2 (x)b; W1 (y)a R1 (x)b R2 (y )a

Consistent ordering of operations


Consistency and replication Data-centric consistency models

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 by different
processes.

A violation of a causally-consistent store

A correct sequence of events in a causally-consistent store


Consistent ordering of operations
Consistency and replication Data-centric consistency models

Consistency models, serializability, transactions


Overwhelming, but often already known
Again, from the world of transactions: can we order the execution of all
operations in a set of transactions in such a way that the final result matches a
serial execution of those transactions? The keyword is serializability.

BEGIN TRANSACTION BEGIN TRANSACTION BEGIN TRANSACTION


x = 0 x = 0 x = 0
x = x + 1 x = x + 2 x = x + 3
END TRANSACTION END TRANSACTION END TRANSACTION
Transaction T1 Transaction T2 Transaction T3

A number of schedules
Time −→
S1 x=0 x=x+1 x=0 x=x+2 x=0 x=x+3 Legal
S2 x=0 x=0 x=x+1 x=x+2 x=0 x=x+3 Legal
S3 x=0 x=0 x=x+1 x=0 x=x+2 x=x+3 Illegal
S4 x=0 x=0 x=x+3 x=0 x=x+1 x=x+2 Illegal

Consistent ordering of operations


Consistency and replication Data-centric consistency models

Grouping operations
Entry consistency: Definition
• Accesses to locks are sequentially consistent.
• No access to a lock is allowed to be performed until all previous writes
have completed everywhere.
• No data access is allowed to be performed until all previous accesses to
locks have been performed.

Consistent ordering of operations


Consistency and replication Data-centric consistency models

Grouping operations
Entry consistency: Definition
• Accesses to locks are sequentially consistent.
• No access to a lock is allowed to be performed until all previous writes
have completed everywhere.
• No data access is allowed to be performed until all previous accesses to
locks have been performed.

Basic idea
You don’t care that reads and writes of a series of operations are immediately
known to other processes. You just want the effect of the series itself to be
known.

Consistent ordering of operations


Consistency and replication Data-centric consistency models

Grouping operations
A valid event sequence for entry consistency

Observation
Entry consistency implies that we need to lock and unlock data (implicitly or
not).

Question
What would be a convenient way of making this consistency more or less
transparent to programmers?

Consistent ordering of operations


Consistency and replication Data-centric consistency models

Eventual consistency
Definition
Consider a collection of data stores and (concurrent) write operations. The
strores are eventually consistent when in lack of updates from a certain
moment, all updates to that point are propagated in such a way that replicas
will have the same data stored (until updates are accepted again).

Srong eventual consistency


Basic idea: if there are conflicting updates, have a globally determined
resolution mechanism (for example, using NTP, simply let the “most recent”
update win).

Program consistency
P is a monotonic problem if for any input sets S and T , P(S) ⊆ P(T ).
Observation: A program solving a monotonic problem can start with
incomplete information, but is guaranteed not to have to roll back when
missing information becomes available. Example: filling a shopping cart.

Eventual consistency
Consistency and replication Data-centric consistency models

Eventual consistency
Definition
Consider a collection of data stores and (concurrent) write operations. The
strores are eventually consistent when in lack of updates from a certain
moment, all updates to that point are propagated in such a way that replicas
will have the same data stored (until updates are accepted again).

Srong eventual consistency


Basic idea: if there are conflicting updates, have a globally determined
resolution mechanism (for example, using NTP, simply let the “most recent”
update win).

Program consistency
P is a monotonic problem if for any input sets S and T , P(S) ⊆ P(T ).
Observation: A program solving a monotonic problem can start with
incomplete information, but is guaranteed not to have to roll back when
missing information becomes available. Example: filling a shopping cart.

Important observation
In all cases, we are avoiding global synchronization.
Eventual consistency
Consistency and replication Data-centric consistency models

Continuous Consistency
We can actually talk about a degree of consistency
• replicas may differ in their numerical value
• replicas may differ in their relative staleness
• there may be differences regarding (number and order) of performed
update operations

Conit
Consistency unit ⇒ specifies the data unit over which consistency is to be
measured.

Continuous consistency
Consistency and replication Data-centric consistency models

Example: Conit

Conit (contains the variables g, p, and d)


• Each replica has a vector clock: ([known] time @ A, [known] time @ B)
• B sends A operation [⟨5, B⟩ : g ← d + 45]; A has made this operation
permanent (cannot be rolled back)

Continuous consistency
Consistency and replication Data-centric consistency models

Example: Conit

Conit (contains the variables g, p, and d)


• A has three pending operations ⇒ order deviation = 3
• A missed two operations from B; max diff is 70 + 412 units ⇒ (2, 482)

Continuous consistency
Consistency and replication Client-centric consistency models

Consistency for mobile users


Example
Consider a distributed database to which you have access through your
notebook. Assume your notebook acts as a front end to the database.
• At location A you access the database doing reads and updates.
• At location B you continue your work, but unless you access the same
server as the one at location A, you may detect inconsistencies:
• your updates at A may not have yet been propagated to B
• you may be reading newer entries than the ones available at A
• your updates at B may eventually conflict with those at A
Consistency and replication Client-centric consistency models

Consistency for mobile users


Example
Consider a distributed database to which you have access through your
notebook. Assume your notebook acts as a front end to the database.
• At location A you access the database doing reads and updates.
• At location B you continue your work, but unless you access the same
server as the one at location A, you may detect inconsistencies:
• your updates at A may not have yet been propagated to B
• you may be reading newer entries than the ones available at A
• your updates at B may eventually conflict with those at A

Note
The only thing you really want is that the entries you updated and/or read at A,
are in B the way you left them in A. In that case, the database will appear to be
consistent to you.
Consistency and replication Client-centric consistency models

Basic architecture
The principle of a mobile user accessing different replicas of a
distributed database
Consistency and replication Client-centric consistency models

Client-centric consistency: notation


Notations
• W1 (x2 ) is the write operation by process P1 that leads to version x2 of x
• W1 (xi ; xj ) indicates P1 produces version xj based on a previous version
xi .
• W1 (xi |xj ) indicates P1 produces version xj concurrently to version xi .

Monotonic reads
Consistency and replication Client-centric consistency models

Monotonic reads
Example
Automatically reading your personal calendar updates from different servers.
Monotonic reads guarantees that the user sees all updates, no matter from
which server the automatic reading takes place.

Example
Reading (not modifying) incoming mail while you are on the move. Each time
you connect to a different e-mail server, that server fetches (at least) all the
updates from the server you previously visited.

Monotonic reads
Consistency and replication Client-centric consistency models

Monotonic reads
Definition
If a process reads the value of a data item x, any successive read operation on
x by that process will always return that same or a more recent value.

A monotonic-read consistent data store

A data store that does not provide monotonic reads

Monotonic reads
Consistency and replication Client-centric consistency models

Monotonic writes
Example
Updating a program at server S2 , and ensuring that all components on which
compilation and linking depends, are also placed at S2 .

Example
Maintaining versions of replicated files in the correct order everywhere
(propagate the previous version to the server where the newest version is
installed).

Monotonic writes
Consistency and replication Client-centric consistency models

Monotonic writes
Definition
A write operation by a process on a data item x is completed before any
successive write operation on x by the same process.

OK Not OK

Not OK OK

Monotonic writes
Consistency and replication Client-centric consistency models

Read your writes


Definition
The effect of a write operation by a process on a data item x, will always be
seen by a successive read operation on x by the same process.

OK

Not OK

Read your writes


Consistency and replication Client-centric consistency models

Read your writes


Definition
The effect of a write operation by a process on a data item x, will always be
seen by a successive read operation on x by the same process.

OK

Not OK

Example
Updating your Web page and guaranteeing that your Web browser shows the
newest version instead of its cached copy.

Read your writes


Consistency and replication Client-centric consistency models

Writes follow reads


Definition
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.

OK

Not OK

Writes follow reads


Consistency and replication Client-centric consistency models

Writes follow reads


Definition
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.

OK

Not OK

Example
See reactions to posted articles only if you have the original posting (a read
“pulls in” the corresponding write operation).

Writes follow reads


Consistency and replication Client-centric consistency models

Example: ZooKeeper consistency


Yet another model?
ZooKeeper’s consistency model mixes elements of data-centric and
client-centric models

Take a naive example

Example: client-centric consistency in ZooKeeper


Consistency and replication Replica management

Replica placement
Essence
Figure out what the best K places are out of N possible locations.

Finding the best server location


Consistency and replication Replica management

Replica placement
Essence
Figure out what the best K places are out of N possible locations.
• Select best location out of N − K for which the average distance to clients
is minimal. Then choose the next best server. (Note: The first chosen
location minimizes the average distance to all clients.) Computationally
expensive.

Finding the best server location


Consistency and replication Replica management

Replica placement
Essence
Figure out what the best K places are out of N possible locations.
• Select best location out of N − K for which the average distance to clients
is minimal. Then choose the next best server. (Note: The first chosen
location minimizes the average distance to all clients.) Computationally
expensive.
• Select the K -th largest autonomous system and place a server at the
best-connected host. Computationally expensive.

Finding the best server location


Consistency and replication Replica management

Replica placement
Essence
Figure out what the best K places are out of N possible locations.
• Select best location out of N − K for which the average distance to clients
is minimal. Then choose the next best server. (Note: The first chosen
location minimizes the average distance to all clients.) Computationally
expensive.
• Select the K -th largest autonomous system and place a server at the
best-connected host. Computationally expensive.
• Position nodes in a d-dimensional geometric space, where distance
reflects latency. Identify the K regions with highest density and place a
server in every one. Computationally cheap.

Finding the best server location


Consistency and replication Replica management

Content replication
Distinguish different processes
A process is capable of hosting a replica of an object or data:
• Permanent replicas: Process/machine always having a replica
• Server-initiated replica: Process that can dynamically host a replica on
request of another server in the data store
• Client-initiated replica: Process that can dynamically host a replica on
request of a client (client cache)

Content replication and placement


Consistency and replication Replica management

Content replication
The logical organization of different kinds of copies of a data store into
three concentric rings

Content replication and placement


Consistency and replication Replica management

Server-initiated replicas
Counting access requests from different clients

• Keep track of access counts per file, aggregated by considering server


closest to requesting clients
• Number of accesses drops below threshold D ⇒ drop file
• Number of accesses exceeds threshold R ⇒ replicate file
• Number of access between D and R ⇒ migrate file

Content replication and placement


Consistency and replication Replica management

Content distribution
Consider only a client-server combination
• Propagate only notification/invalidation of update (often used for caches)
• Transfer data from one copy to another (distributed databases): passive
replication
• Propagate the update operation to other copies: active replication

Note
No single approach is the best, but depends highly on available bandwidth and
read-to-write ratio at replicas.

Content distribution
Consistency and replication Replica management

Content distribution: client/server system


A comparison between push-based and pull-based protocols in the
case of multiple-client, single-server systems
• Pushing updates: server-initiated approach, in which update is
propagated regardless whether target asked for it.
• Pulling updates: client-initiated approach, in which client requests to be
updated.

Issue Push-based Pull-based


1: List of client caches None
2: Update (and possibly fetch update) Poll and update
3: Immediate (or fetch-update time) Fetch-update time
1: State at server
2: Messages to be exchanged
3: Response time at the client

Content distribution
Consistency and replication Replica management

Content distribution
Observation
We can dynamically switch between pulling and pushing using leases: A
contract in which the server promises to push updates to the client until the
lease expires.

Make lease expiration time adaptive

Content distribution
Consistency and replication Replica management

Content distribution
Observation
We can dynamically switch between pulling and pushing using leases: A
contract in which the server promises to push updates to the client until the
lease expires.

Make lease expiration time adaptive


• Age-based leases: An object that hasn’t changed for a long time, will not
change in the near future, so provide a long-lasting lease

Content distribution
Consistency and replication Replica management

Content distribution
Observation
We can dynamically switch between pulling and pushing using leases: A
contract in which the server promises to push updates to the client until the
lease expires.

Make lease expiration time adaptive

• Renewal-frequency based leases: The more often a client requests a


specific object, the longer the expiration time for that client (for that object)
will be

Content distribution
Consistency and replication Replica management

Content distribution
Observation
We can dynamically switch between pulling and pushing using leases: A
contract in which the server promises to push updates to the client until the
lease expires.

Make lease expiration time adaptive

• State-based leases: The more loaded a server is, the shorter the
expiration times become

Content distribution
Consistency and replication Replica management

Content distribution
Observation
We can dynamically switch between pulling and pushing using leases: A
contract in which the server promises to push updates to the client until the
lease expires.

Make lease expiration time adaptive


• Age-based leases: An object that hasn’t changed for a long time, will not
change in the near future, so provide a long-lasting lease
• Renewal-frequency based leases: The more often a client requests a
specific object, the longer the expiration time for that client (for that object)
will be
• State-based leases: The more loaded a server is, the shorter the
expiration times become

Question
Why are we doing all this?

Content distribution
Consistency and replication Replica management

Managing replicated objects


• Prevent concurrent execution of multiple invocations on the same object:
access to the internal data of an object has to be serialized. Using local
locking mechanisms are sufficient.
• Ensure that all changes to the replicated state of the object are the same:
no two independent method invocations take place on different replicas at
the same time: we need deterministic thread scheduling.

Managing replicated objects


Consistency and replication Replica management

Replicated-object invocations
Problem when invocating a replicated object

Managing replicated objects


Consistency and replication Replica management

Replicated-object invocations

Forwarding a request Returning the reply

Managing replicated objects


Consistency and replication Consistency protocols

Primary-based protocols
Primary-backup protocol

Sequential consistency: Primary-based protocols


Consistency and replication Consistency protocols

Primary-based protocols
Primary-backup protocol

Example primary-backup protocol


Traditionally applied in distributed databases and file systems that require a
high degree of fault tolerance. Replicas are often placed on the same LAN.
Sequential consistency: Primary-based protocols
Consistency and replication Consistency protocols

Primary-based protocols
Primary-backup protocol with local writes

Sequential consistency: Primary-based protocols


Consistency and replication Consistency protocols

Primary-based protocols
Primary-backup protocol with local writes

Example primary-backup protocol with local writes


Mobile computing in disconnected mode (ship all relevant files to user before
disconnecting, and update later on).
Sequential consistency: Primary-based protocols
Consistency and replication Consistency protocols

Replicated-write protocols
Quorum-based protocols
Assume N replicas. Ensure that each operation is carried out in such a way
that a majority vote is established: distinguish read quorum NR and write
quorum NW . Ensure:
1. NR + NW > N (prevent read-write conflicts)
2. NW > N/2 (prevent write-write conflicts)

Correct Write-write conflict Correct (ROWA)

Sequential consistency: Replicated-write protocols


Consistency and replication Consistency protocols

Continuous consistency: Numerical errors


Principal operation
• Every server Si has a log, denoted as Li .
• Consider a data item x and let val(W ) denote the numerical change in its
value after a write operation W . Assume that

∀W : val(W ) > 0

• W is initially forwarded to one of the N replicas, denoted as origin(W ).


TW [i, j] are the writes executed by server Si that originated from Sj :

TW [i, j] = ∑{val(W )|origin(W ) = Sj & W ∈ Li }

Implementing continuous consistency


Consistency and replication Consistency protocols

Continuous consistency: Numerical errors


Note
Actual value v (t) of x:
N
v (t) = vinit + ∑ TW [k, k ]
k=1

value vi of x at server Si :
N
vi = vinit + ∑ TW [i, k ]
k=1

Implementing continuous consistency


Consistency and replication Consistency protocols

Continuous consistency: Numerical errors


Problem
We need to ensure that v (t) − vi < δi for every server Si .

Implementing continuous consistency


Consistency and replication Consistency protocols

Continuous consistency: Numerical errors


Problem
We need to ensure that v (t) − vi < δi for every server Si .

Approach
Let every server Sk maintain a view TWk [i, j] of what it believes is the value of
TW [i, j]. This information can be gossiped when an update is propagated.

Implementing continuous consistency


Consistency and replication Consistency protocols

Continuous consistency: Numerical errors


Problem
We need to ensure that v (t) − vi < δi for every server Si .

Approach
Let every server Sk maintain a view TWk [i, j] of what it believes is the value of
TW [i, j]. This information can be gossiped when an update is propagated.

Note

0 ≤ TWk [i, j] ≤ TW [i, j] ≤ TW [j, j]

Implementing continuous consistency


Consistency and replication Consistency protocols

Continuous consistency: Numerical errors


Solution
Sk sends operations from its log to Si when it sees that TWk [i, k] is getting too
far from TW [k , k ], in particular, when

TW [k , k ] − TWk [i, k ] > δi /(N − 1)

Implementing continuous consistency


Consistency and replication Consistency protocols

Continuous consistency: Numerical errors


Solution
Sk sends operations from its log to Si when it sees that TWk [i, k] is getting too
far from TW [k , k ], in particular, when

TW [k , k ] − TWk [i, k ] > δi /(N − 1)

Question
To what extent are we being pessimistic here: where does δi /(N − 1) come
from?

Implementing continuous consistency


Consistency and replication Consistency protocols

Continuous consistency: Numerical errors


Solution
Sk sends operations from its log to Si when it sees that TWk [i, k] is getting too
far from TW [k , k ], in particular, when

TW [k , k ] − TWk [i, k ] > δi /(N − 1)

Question
To what extent are we being pessimistic here: where does δi /(N − 1) come
from?

Note
Staleness can be done analogously, by essentially keeping track of what has
been seen last from Si (see book).

Implementing continuous consistency


Consistency and replication Consistency protocols

Implementing client-centric consistency


Keeping it simple
Each write operation W is assigned a globally unique identifier by its origin
server. For each client, we keep track of two sets of writes:
• Read set: the (identifiers of the) writes relevant for that client’s read
operations
• Write set: the (identifiers of the) client’s write operations.

Implementing client-centric consistency


Consistency and replication Consistency protocols

Implementing client-centric consistency


Keeping it simple
Each write operation W is assigned a globally unique identifier by its origin
server. For each client, we keep track of two sets of writes:
• Read set: the (identifiers of the) writes relevant for that client’s read
operations
• Write set: the (identifiers of the) client’s write operations.

Monotonic-read consistency
When client C wants to read at server S, C passes its read set. S can pull in
any updates before executing the read operation, after which the read set is
updated.

Implementing client-centric consistency


Consistency and replication Consistency protocols

Implementing client-centric consistency


Keeping it simple
Each write operation W is assigned a globally unique identifier by its origin
server. For each client, we keep track of two sets of writes:
• Read set: the (identifiers of the) writes relevant for that client’s read
operations
• Write set: the (identifiers of the) client’s write operations.

Monotonic-read consistency
When client C wants to read at server S, C passes its read set. S can pull in
any updates before executing the read operation, after which the read set is
updated.

Monotonic-write consistency
When client C wants to write at server S, C passes its write set. S can pull in
any updates, executes them in the correct order, and then executes the write
operation, after which the write set is updated.

Implementing client-centric consistency


Consistency and replication Consistency protocols

Implementing client-centric consistency


Read-your-writes consistency
When client C wants to read at server S, C passes its write set. S can pull in
any updates before executing the read operation, after which the read set is
updated.

Implementing client-centric consistency


Consistency and replication Consistency protocols

Implementing client-centric consistency


Read-your-writes consistency
When client C wants to read at server S, C passes its write set. S can pull in
any updates before executing the read operation, after which the read set is
updated.

Writes-follows-reads consistency
When client C wants to write at server S, C passes its read set. S can pull in
any updates, executes them in the correct order, and then executes the write
operation, after which the write set is updated.

Implementing client-centric consistency


Consistency and replication Example: Caching and replication in the Web

Example: replication in the Web


Client-side caches
• In the browser
• At a client’s site, notably through a Web proxy

Caches at ISPs
Internet Service Providers also place caches to (1) reduce cross-ISP traffic
and (2) improve client-side performance. May get nasty when a request needs
to pass many ISPs.
Consistency and replication Example: Caching and replication in the Web

Cooperative caching
Consistency and replication Example: Caching and replication in the Web

Web-cache consistency
How to guarantee freshness?
To prevent that stale information is returned to a client:
• Option 1: let the cache contact the original server to see if content is still
up to date.
• Option 2: Assign an expiration time Texpire that depends on how long ago
the document was last modified when it is cached. If Tlast modified is the
last modification time of a document (as recorded by its owner), and
Tcached is the time it was cached, then

Texpire = α(Tcached − Tlast modified ) + Tcached

with α = 0.2. Until Texpire , the document is considered valid.


Consistency and replication Example: Caching and replication in the Web

Alternatives for caching and replication

• Database copy: the edge has the same as the origin server
• Content-aware cache: check if a (normal query) can be answered with
cached data. Requires that the server knows about which data is cached
at the edge.
• Content-blind cache: store a query, and its result. When the exact same
query is issued again, return the result from the cache.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy