加入收藏 | 设为首页 | 会员中心 | 我要投稿 应用网_阳江站长网 (https://www.0662zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > MySql教程 > 正文

当数据库遇到分布式,你会怎么做?

发布时间:2020-03-07 01:27:41 所属栏目:MySql教程 来源:站长网
导读:数据库通常有着完善的事务支持,但是局限于单机的存储和性能,于是就出现了各种分布式解决方案。最近读了《Designing Data-Intensive Applications》这本书,所以做一个总结,供大家做个参考,有什么不对的请大家指正,一起讨论。 数据模型 数据模型可以说

复制系统的一个重要细节是 复制 是 同步发生 还是 异步发生。同步复制会使得数据写入时间变长,而异步复制会使得副本之间的数据不一致,客户端可能会读取到历史的数据,并且在主库故障时有可能会丢失数据。所以复制系统的核心就是如何让副本保持一致,并且在主库故障时能够自动切换。

一致性模型

当数据库遇到分布式,你会怎么做?

一致性模型(consistency model)实质上是进程和数据存储存储之间的一个约定。即,如果进程同意遵守某些规则,那么数据存储将正常运行。正常情况下,一个进程在一个数据项执行读操作时,它期待该操作返回的是该数据在其最后一次写操作之后的结果。

在没有全局时钟的情况下,精确地定义哪次写操作时最后一次写操作是十分困难的。作为替代的方法,我们需要提供其他的定义,因此产生了一系列的一致性模型。每种模型都有效地限制了在一个数据项上执行一次读操作所应返回的值。

注意:不将数据库事务的一致性与其混淆,分布式副本的一致性指的是单个对象的写入和读取。

以数据为中心

线性一致性

线性一致性也称为严格一致性(Strict Consistency)或者原子一致性(Atomic Consistency),需要满足以下两个条件:

任何一次读都能读取到某个数据最近的一次写的数据。

所有进程看到的操作顺序都跟全局时钟下的顺序一致。

线性一致性的想法是让一个系统看起来只有一个数据副本,而且所有的操作都是原子性的。应用不用担心多个副本带来诸多问题,是一个完美的理想模型,作为其他模型的参考(最强一致性模型)。

在线性一致性的数据存储中不存在并发操作:必须有且仅有一条时间线,所有的操作都在这条时间线上,构成一个全序关系。

顺序一致性

顺序一致性最早出现在Shared-Memory Multi-Processor System单机模型中,为程序员提供了极强的内存可见性保证。顺序一致性内存模型有两大特性:

任何执行的结果都与所有处理器的操作按某种顺序执行的相同。

每个单独的处理器的操作顺序均按照其程序指定的顺序。

所有操作都必须相对于每个其他处理器立即或原子执行(立即可见)。

当数据库遇到分布式,你会怎么做?

在时间顺序上,C1发生于B2之后。对于线性一致性来说,C1一定在B2之后,但是对于顺序一致性B2可以发生在C1之后。

顺序一致性可能会产生不确定的结果。这是因为在程序的不同运行期间,处理器之间的顺序操作的顺序可能会有所不同。

对于顺序一致性来说,它要找到一个合法的顺序执行过程,该执行过程要保留线程/进程内部原有的顺序

对于线性一致性来说,它也是要找到一个合法的顺序执行过程。但是这个顺序执行过程,不仅要保留线程/进程内部的先后顺序,还要保留线程/进程之间的操作的先后顺序。

线性一致性可以定义为具有实时约束(real-time constraint)的顺序一致性。

个人理解,在分布式副本的领域中,不太可能找到 除了时序之外,各个进程能够一致认可的顺序。所以在分布式副本领域参考意义不大,更容易造成疑惑。

因果一致性

相对于线性一致性保证读写具有全局顺序,而因果一致性只需要保证具有相互依赖的读写操作保持相同的顺序即可。实际上因果一致性是性能和可用最高的强一致性模型。

因果一致性实现的难点在于如何定义和捕获因果关系,你需要知道哪个操作发生在哪个操作之前(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时间戳

(编辑:应用网_阳江站长网)

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