Eventually Consistent – Building reliable distributed systems at a worldwide scale demands trade-offs between consistency and availability.
可以从两个角度看待一致性。一个是从开发者、客户端的角度:它们如何观察数据更新。第二种是从服务器端看待:更新如何流通整个系统且系统对更新有什么保证。
客户端一致性:
客户端需考虑一下部分:
- 存储系统 它在本质上是大规模且高度分布的系统,其创建目的是为了保证耐用性和可用性。
- 进程A 对存储系统进行读写。
- 进程B和C 这两个进程完全独立于进程A,也读写存储系统。无论B、C是真正的进程还是进程内的现场,它们是相对独立的。B、C需要通信以分享信息。客户端一致性必须处理一个观察者(在此即进程A、B或C)如何以及何时看到存储系统中的一个数据对象被更新。
- 强一致性 在更新完成后,(A、B或C进行的)任何后续访问都将返回更新过的值。
- 弱一致性 系统不保证后续访问将返回更新过的值,在那之前要先满足若干条件。从更新到保证任一观察者看到更新值的时刻之间的这段时间被称为不一致窗口。
- 最终一致性。这是弱一致性的一种特殊形式;存储系统保证如果对象没有新的更新,最终所有访问都将返回最后更新的值。如果没有发生故障,不一致窗口的最大值可以根据下列因素确定:比如通信延迟、系统负载、复制方案涉及的副本数量。DNS是实现最终一致性的最流行的系统。
客户端一致性模型的变体有:
- 因果一致性。如果进程A通知进程B它已更新了一个数据项,那么进程B的后续访问将返回更新后的值,且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。
- “读己之所写”一致性。这是一个重要的模型。当进程A自己更新一个数据项之后,它总是访问到更新过的值,绝不会看到旧值。这是因果一致性模型的一个特例。
- 会话一致性。这是上一个模型的实用版本,它把访问存储系统的进程放到会话的上下文中。只要会话还存在,系统就保证“读己之所写”一致性。如果由于某种错误,会话被中止,一个新的会话需要创建,且系统的保证不会使两个会话重叠。
- 单调读一致性。如果进程已经看到过数据对象的某个值,那么任何后续访问都不会返回在那个值之前的值。
- 单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性,就非常难以编程了。
服务器端一致性
几个定义:
N = the number of nodes that store replicas of the data
W = the number of replicas that need to acknowledge the receipt of the update before the update completes
R = the number of replicas that are contacted when a data object is accessed through a read operation
N=节点内存储重复数据的数量
W=在更新完成之前需要确认收到更新的数据副本数
R=一个读操作需要访问的数据副本数
如果W+R>N, 那么读写数据集总是重叠的,这就保证了强一致性。在一个主备RDBMS场景中当实现了同步复制,N=2,W=2,R=1。在异步复制且从允许从备份数据库读数据的情况下,N=2,W=1,R=1。这种情况R+W=N,则一致性无法保证。
如何配置N,W,R,这依赖于系统一般的应用场景和哪一种性能(CAP)需要优化。当R=1,N=W是,我们优化读的情况,当W=1,R=N时,我们优化得到快速的写的能力。
弱/最终一致性的产生是当W+R<=N,这意味着存在读写重叠的可能。
“读己之所写”一致性、会话一致性和单调一致性是否可以达成,取决于客户端对为其执行分布式协议的服务器的“粘度”。如果每次都是同一台服务器,那么就比较容易保证“读己之所写”一致性和单调一致性。这样做会使管理负载平衡以及容错变得稍困难一些,但这是一种简单的方案。
客户端有时会实现“读己之所写”一致性和单调读一致性。通过给写入添加版本,对那些版本早于最后版本的值来说,客户端会丢弃这些值的读出。
在有些应用中,不可用的任何分区都是不能接受的,保证客户端能访问分割分区并操作是很重要的。这种情况下,服务器客户端分配新的存储节点接收数据,并在分区恢复后执行合并操作。例如,Amazon的购物车就是一个总是可写的系统。当出现分区时,客户可以继续往购物车添加东西,即使原有的购物车可能在其他分区。购物车应用在分区恢复后帮助存储系统合并购物车。
来自:
http://www.allthingsdistributed.com/2008/12/eventually_consistent.html
