当数据库遇到分布式，你会怎么做？

因果一致性实现的难点在于如何定义和捕获因果关系，你需要知道哪个操作发生在哪个操作之前(happen before)。但是这种因果关系更多是来自上层应用，底层存储是无法感知的，所以跟踪所有的因果关系是不及实际的。

因果关系的操作在时序上一定是有先后，所以通过全序的的序列化或时间戳(逻辑时钟)来排序操作，这样所有的操作都有了时间上的因果先后关系。所以线性一致性是所有操作都满足因果一致性(即使大部分操作没有依赖关系)。

最终一致性

最终一致性不能算是一致性模型，没有任何一致性保证，只是说在没有更新的情况下，副本之间会在一定时间内保持一致。因为由于网络延迟的存在，应用任何时候都可能读取到不一致的数据。可以说是可接受的最弱的一致性模型。

以客户端为中心

上面讨论的以数据存储为视角的一致性，在因果一致性以及更强的一致性模型中，从客户端而言是不会发生预料之外的读写问题的。但是在更弱的一致性模型而言，出现各种读写问题。

以客户端为中心的一致性为单一客户端提供一致性保证，保证该客户端对数据存储的访问的一致性，但是它不为不同客户端的并发访问提供任何一致性保证。

以客户端为中心的一致性包含了四种模型：

单调读一致性(Monotonic-read Consistency)：如果一个进程读取数据项 x 的值，那么该进程对于 x 后续的所有读操作要么读取到第一次读取的值要么读取到更新的值。即保证客户端不会读取到旧值。

单调写一致性(Monotonic-write Consistency)：一个进程对数据项 x 的写操作必须在该进程对 x 执行任何后续写操作之前完成。即保证客户端的写操作是串行的。

读写一致性(Read-your-writes Consistency)：一个进程对数据项 x 执行一次写操作的结果总是会被该进程对 x 执行的后续读操作看见。即保证客户端能读到自己最新写入的值。

写读一致性(Writes-follow-reads Consistency)：同一个进程对数据项 x 执行的读操作之后的写操作，保证发生在与 x 读取值相同或比之更新的值上。即保证客户端对一个数据项的写操作是基于该客户端最新读取的值。

但是真实情况是，由于服务器负载均衡以及服务器故障的存在，会导致客户端会话会发生转移，因此基于客户端访问的一致性模型是不靠谱的。

共识协议

Lamport时间戳

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!