这篇论文主要描述了6种不同的读操作一致性保证，并用棒球比赛中不同人群的角度来说明不同一致性适用的例子。
这里的一致性讨论的是数据在不同副本之间由于同步策略的关系，对于客户端的数据可见性。
六种数据一致性
- 强一致性很容易理解，它保证每次都能读到最新更新的数据，在读操作之前的所有写操作都会被读到
- 最终一致性是很弱的一致性保证，读操作可能读到之前写操作的任意部分
- 一致性前缀保证了读操作可以按操作顺序读到数据。也就是说，可以读到某个时间的旧版本数据
- 有界延迟保证了读操作可以读到“不太过时”的数据，比如说保证读到不超过5分钟延迟的数据
- 单调读通常也被叫做会话保证，客户端可能读到最终一致性的数据，但单个客户端多次读取操作每次都会按照数据更新顺序更新
- 读本身写保证了客户端的任何数据更新操作一定可以被本身在随后的读操作读取到
下图是这六种一致性保证的简单总结：
六种一致性保证的比较
下面是以棒球比赛为例，假设双方比赛结果存储在一个分布式KV存储中，一个key为“visitor”存储客队分数，一个key为“home”存储主队分数：
Write (“visitors”, 0);
Write (“home”, 0);
for inning = 1 .. 9
outs = 0;
while outs < 3
visiting player bats;
for each run scored
score = Read (“visitors”);
Write (“visitors”, score + 1);
outs = 0;
while outs < 3
home player bats;
for each run scored
score = Read (“home”);
Write (“home”, score + 1);
end game;
假设一场实际比赛产生如下写入操作：
Write (“home”, 1)
Write (“visitors”, 1)
Write (“home”, 2)
Write (“home”, 3)
Write (“visitors”, 2)
Write (“home”, 4)
Write (“home”, 5)
对于上面六种不同的一致性保证，可能读到分数结果如下：
可能读到不同的比分
下面就从不同角色角度来看，他们分别需要采用哪种一致性保证：
- 官方记分员
记分员负责根据比赛进展更新实时比分，如下示意：
# when visitor get one score
score = Read("visitors");
Write("visitors", score + 1);
# when home get one score
score = Read("home")
Write("home", score + 1)
那么，记分员需要哪种程度的一致性保证呢？显而易见的，他需要获取最新的实时数据，以便数据更新操作不会出错，由于在这里记分员是唯一的数据写入者，所以对于他的读操作，读本身写的保证能够满足需求。
- 裁判
对于裁判，它的读取操作如下：
if first half of 9th inning complete then
vScore = Read (“visitors”);
hScore = Read (“home”);
if vScore < hScore
end game;
在九局五胜的赛制中，在第五局及其之后的比赛中，裁判都需要获取实时数据，以便判断是否提前结束比赛，由于裁判本身不写入数据，只读取数据，所以裁判需要强一致性保证
- 电台解说员
在棒球比赛中，电台解说员需要每隔一段时间播报一次比分，这里以30分钟时间间隔为例：
do {
vScore = Read (“visitors”);
hScore = Read (“home”);
report vScore and hScore;
sleep (30 minutes);
} while during baseball game
这里并不要求强一致性保证。如果采用最总一致性保证会出现什么问题呢？它可能会读取到不存在的比分（两个分数一个更新了，一个没更新）。这里采用一致性前缀+单调读来保证读取逐步更新的比分
- 体育新闻作家
体育新闻作家的行为通常描述如下：
While not end of game {
drink beer;
smoke cigar;
}
go out to dinner;
vScore = Read (“visitors”);
hScore = Read (“home”);
write article;
这里对于比分没有实时要求，最弱的最终一致性保证就能满足需求，但是为了保险起见，可以采用有界延迟的保证，确保在写作时能够拿到准确的最终比分
- 数据分析师
数据分析师通常需要记录以赛季记的比分数据，他们的行为如下：
Wait for end of game;
score = Read (“home”);
stat = Read (“season-runs”);
Write (“season-runs”, stat + score);
对于统计数据的读取，为了防止读取旧数据覆盖新数据，可以采用读自己写的一致性保证
- 统计观察者
需要做数据的长时间存储处理，每天更新一次，行为如下：
do {
stat = Read (“season-runs”);
discuss stats with friends;
sleep (1 day);
}
这里对于实时性没有什么要求，只需要最弱的最终一致性保证就能满足需求
不同角色对于一致性的不同要求
