主从异步复制的情况下会导致数据库中出现明显不一致,此时从不同的从节点读取就会得到不一样的结果。这种不一致只是一个暂时状态,如果停止写入数据,经过一段时间之后,从节点最终会赶上并与主节点保持一致。
这种效应被称为最终一致性。
主从异步复制的情况下会导致数据库中出现明显不一致,此时从不同的从节点读取就会得到不一样的结果。这种不一致只是一个暂时状态,如果停止写入数据,经过一段时间之后,从节点最终会赶上并与主节点保持一致。
这种效应被称为最终一致性。
tags: 分布式共识,一致性 一致性保证 分布式一致性主要针对延迟和故障等问题来协调副本之间的状态。 线性化:最强一致性模型 顺序保证:保证时间顺序,特别是因果关系和全局顺序 最终一致性:一种非常弱的保证,参见最终一致性效应 可线性化 分布式语义下对寄存器(单个对象)顺序的读写。应区别与可串行化。 可串行化针对不同事务的隔离,用来确保事务执行的结果与串形执行的结果相同 可线性化是读写寄存器(单个对象)的最新值的保证。 线性化依赖的条件 加锁与主节点选举 每个启动节点都试图获得锁,其中只有一个可以成功成为主节点。通过加锁来保证主节点选举「线性化」。 约束与唯一性保证 同一个用户名、电子邮件或系统中文件名需要唯一性的保证,也应该进行「线性化」。 跨通道的时间依赖 系统中存在其他通信渠道也需要「线性化」。 实现线性化系统 主从复制(部分支持可线性化) 共识算法(可线性化) 多主复制(不可线性化) 无主复制(可能不可线性化) 线性化与Quorum 一致性 Dynamo 风格的复制模型,读写遵从严格的 quorum 是无法支持可线性化的。 线性化的代价 多主复制和主从复制,网络中断都会导致同步暂停,从而无法保证客户端要求的线性化读写。 CAP 理论 可线性化与网络延迟 很少有系统真正满足线性化,现代多个 CPU 对同一个内存地址的读写都不能满足(参见硬件内存模型),如果需要强一致则需要内存屏障(栅栏)指令。 之所以放弃线性化的原因就是性能,而不是为了容错。由于网络延迟的不确定性,无论是否发生网络故障,线性化对性能的影响都是巨大的。 顺序保证 顺序与因果关系 顺序有助于保持因果关系。 因果顺序并非全序:因果关系是小范围集合的偏序,可线性化是一个全序操作。 可线性化强于因果一致性 捕获因果依赖关系:检测并发写 序列号排序 非因果序列发生器 适用于系统不存在唯一主节点。 每个节点都独立产生自己的一组序列号:一个奇数一个偶数,或者切入节点唯一标识符。 用足够高的分辨率的墙上时间戳附加到每个操作上。 预先分配区间范围,并及时扩容。 Lamport 时间戳 可以产生因果关系一致的序列号。Lamport 时间戳是一个值对 (计数器,节点 ID) : 节点 ID:每个节点都有一个唯一标志符。 计数器:每个节点都有一个计数器记录各自处理的请求总数。 优点: 两个节点可能存在相同的计数器,但是时间戳中的节点 ID 可以确保每个时间戳都是唯一的。 保证全序:比较两个 Lamport 时间戳,计数器较大的时间戳越大,计数器相同则节点 ID 大的那个时间戳越大。 通过节点排序保证了全局因果关系。Lamport 不同于版本矢量:...
是一种比强一致性弱但是比最终一致性效应强的保证,单调读保证: 如果某个用户依次进行多次读取,则绝不会看到回滚的现象,即在读取到较新的值之后又发生读旧值的情况。 场景 用户刷新网络,读请求被随机路由到某个从节点,先后从两个不同的从节点读取到了不同的内容,比如看到一个新添加的评论一次出现,一次消失。 解决方案 按照用户 ID 进行哈希方法取代随机路由。
异步同步的情况下出出现最终一致性效应复制滞后会导致:用户提交了修改到主节点,但是从从节点没有读取到最新的变更,比如看不到自己提交的评论等。 读写一致性:读自己的写 一旦用户的数据最近发生改变则路由用户请求从主节点进行读取,规避复制滞后的问题。 缺点:只保证单一用户写后读的的一致性,但是不保证多个用户的一致性。比如发了一条评论,自己能刷新到但是同在身边的朋友可能就刷新不到。 单调读一致性 前缀一致读 解决方案 应用层可以提供比数据库更强有力的保证。 事务是数据库提供的更强保证的一种方式。