乐观复制算法-8. 保证内容质量
8. 保证内容质量
乐观复制算法不能保证单个副本的一致性。一致性仅能保证副本在静止状态是一致的，或者在过去的某一个虚拟点上是一致的。因为更新请求的到达可能是乱序，以及没有严格的传输延时限制，乐观复制难以向用户提供某一个时间点上副本内容的一致性保证。
一些复制服务在采用弱一致保证时仍工作的很好。Usenet和Porcupine邮件服务就是这样的例子；副本不一致不会比NNTP和SMTP中的潜在问题更糟糕，比如消息的延迟发送和重复发送。很多服务，受益于更加严格的内容质量保证。本节将分析多种用来控制副本内容在瞬时质量的方法。8.1.2小节讨论保证对象读和写请求因果一致性的技术。8.2节讨论明确限定不一致副本数量的算法。8.3节讨论了保证副本内容质量的概率技术。
这些方法并不是灵丹妙药，当副本内容太旧它们会禁止对对象的访问，或者需要进行内部站点的同步通信。换句话说，它们也无法避免在可用性和一致性之间进行权衡。
8.1 保证访问请求间的因果关系
按因果关系对请求进行排序是任何乐观复制系统的基本特征。它保证了最终对象的内容是用户期望的结果，虽然它无法保证瞬时内容的质量。例如，密码数据库问题（1.3.2小节）就是因为缺少内容质量的保证。一种解决方法就是让用户来声明哪些更新请求应该在读请求之前发生，然后延迟处理这些读请求直到更新被所有的节点处理。类似的技术包括下面几种：
8.1.1 明确的因果依赖
这种方法简单地让用户来明确说明，对于每一次读请求，在副本节点上哪些更新请求应该被执行后才能执行读请求。该方法可以使用版本向量控制，对于状态和操作传输系统都很容易实现。这里，一个副本节点的状态被表示为一个版本向量。请求依赖同样采用VV（Version Vector），这样请求将会被延迟处理，直到该请求所依赖的VV被副本节点状态VV所包含。
8.1.2 Session保证
前一种方法的不足是，对于用户来说声明依赖关系并不是一件轻松的事。Session保证是一种自动化的方法来保证因果依赖特性。用户可以选择预先定义的下面几种因果关系。
(思考：Session Guarantees要考虑同一个用户，前后两次请求，交给不同的replica节点处理。)
“Read your writes”(RYW)保证对于同一个用户，从副本读取的内容包含了该用户之前执行的所有写操作。陈旧密码的问题可以通过强制RYW特性来解决；用户要么等待新密码被传送到副本，或者接收到一个“陈旧副本”错误，这两者相比读取到一个旧密码来说都不容易让人困惑。
“Monotonic reads”(MR)保证同一个用户两次连续的读请求能够获得及时的内容更新。例如，对于采用副本的邮件服务，用户可能会先获取一下邮箱的摘要，随后读取其中一封摘要对应的消息。MR保证用户不会获取到一个“non-existent message”错误。（除非，用户在两次读取操作之间删除掉了该信息）
（思考：这里保证的是，用户前后两次读请求，从不同副本节点能够获取到的内容是向前包含的。即第二次读请求获取的内容肯定要包含第一次读请求的内容，除非用户在这两次读操作之间执行了删除操作。）
“Writes follow reads”(WFR)保证对于同一个用户，在这个副本上，前一个读请求能够看到的更新已经在这个副本上被执行。
（思考：比如从副本上读取一个数A，执行A+1这个操作。如果没有WFR这个保证，当把A+1这个请求发送给另一个副本，该副本可能会出现保存的A值与前一个副本不一致的情况，这样会造成该副本执行A+1后的结果与用户预期的不一致。）
“Monotonic writes”(MW)属性保证对于一个副本节点，写请求只有在该用户之前所有的写请求被应用到该副本上时才执行。例如，一个源代码管理系统。一个库模块在一个节点被修改了，应用程序在另一个节点被修改，但它依赖更新后的库模块。MW保证库的更新在应用程序的更新之前进行。
当用户仅访问一个站点时，这些属性都自动得到保证，这些复制算法来保证更新间的happens-before顺序。在移动环境中，他们采用session的方式来实现。Session，被每个用户所保存，记录两个部分信息：由用户发出的写请求集（write-set），以及用户通过读取操作观察到的写请求集合(read-set)。Table 3总结了Session保证的实现。例如，保证RYW，用户发出的每一个更新请求被追加到该用户的write-set。因此，在返回一个读请求之前，副本确认用户的写请求集合是否是节点已应用写请求集合的子集。如果是，则读取成功；如果不是，用户要么等待，要么接收到一个“陈旧副本”的错误。类似的，对于MR保证，对于每一次读请求，副本要检查用户的read-set是该副本节点已应用写请求集合的子集。在回复请求后，用户将站点请求的更新情况添加到用户的read-set中。
8.2 限制不一致
一些系统明确地限制副本不一致状态的数量。对于非副本数据库，为了提高性能会放松两段锁协议，但在这之后仍有大量的工作要做。因此，他们并不适合移动和分布式广域网环境。尽管如此，这里仍有一些系统为乐观复制环境而设计，我们下面将要介绍到。
实时性保证，例如，限制传播延迟在网络服务中就十分流行。类似的系统比如，WWW、NFS、DNS以及quasi-copies。缓存对象，并保证该对象的陈旧状态小于一定秒数。这样的系统大部分是单Master，基于拉取操作的系统，因为他们可以简单地通过轮询方式来实现实时性的保证。
TACT提供了三种类型的一致性保证：实时，数值型，以及秩序边界。在TACT中，实时性保证与WWW服务有相似的语义，但它是通过按需推送的方式实现。
数值边界，在不同副本上设定数值限制。它给每一个master副本设定可接受更新的配额，在达到配额后需要将更新提交给远程副本。例如，一个用户的银行账务存在10个master副本，设定限制如下，当读取请求所含的金额小于$50时可以从任意节点读取，每个master节点有$5的配额。任意master节点接收到的账户修改请求累计超过$5时，它必须将更新发送到其它节点，才能接受后续更新。
其它边界限制要确保副本当前值与已提交的值之间不能超过X次更新，X的选取可由不同副本决定。这种保证相比数值边界可能更弱，因为后者保证副本的瞬时值与其它副本瞬时值间的差异不超过X次更新。当与瞬时值或提交值的差异超过限定时，副本节点通过从其它节点拉取更新来满足边界限制。
8.3用概率技术来降低不一致
本节所讨论的技术依赖对负载情况的了解，在最小的开销下降低副本节点变陈旧的平均概率。
Cho和Garcia-Molina根据web代理的页面更新频率以及顺序，来研究更新策略，他们基于更新间隔符合泊松分布的假设。他们发现为了最小化页面平均陈旧度，副本需要每次按照相同的顺序，在同一的时间间隔来获取更新，即使一些页面要比其它页面更新的更加频繁。
