数据一致性

Z时代
2024-01-10
分类：综合

database

在分布式环境下，为了避免设备与网络不可靠带来的影响，通常会存储多个数据副本。逻辑上的一份数据，同时存储在多个物理副本上，带来了数据已执行的问题。数据一致性问题的前提是发生读写操作，就是多个副本上的读写策略。

数据一致性从不同的视角，可以分为状态一致性和操作一致性。

状态一致性指数据所处的客观，实际状态体现的一致。

操作一致性指外部用户通过协议约定的操作，能够读到一致的数据。

从状态视角看，任何数据变更后，数据只有两种状态：所有副本一致或不一致。正常情况下，不一致是暂时的，状态会由不一致转变为一致。

由此衍生出强一致性和最终一致性。

以mysql举例，mysql的主从同步机制，有异步，全同步和半同步之分。

异步指mysql主库将事务信息写入binlog文件中的时候，此时主库会通过binlog dump线程给从库发送这些新的binlog变化，然后并不等待从库的响应继续提交事务并写入binlog，所以主库并不保证这些事务变化的binlog数据会传输并应用到任何从库。

全同步指当主库提交事务的binlog后，所有的从库节点必须全部收到事务并且apply并且提交这些内容之后，即io_thread和sql_thread完成所有binlog变化的接受的应用执行，主库的线程才可以继续进行后续操作，但是缺点是，主库完成一个事务的时间会被拉长，性能急剧降低。

半同步介于异步和全同步之间，主库只需要等待至少一个从节点，收到并且flush binlog到relay log文件即可，主库不需要等待所有从库给主库反馈，这里只是一个收到的反馈，而并不是从库已经完成并提交的反馈，即从库只应用完成io_thread内容即可无需等到sql_thread的执行完成。

全同步即强一致性，该模式存在比较大的问题：

1、性能差。需要将数据同步给从库，才给用户返回成功。主库的响应时间取决于从库中时延最长的那个。

2、可用性问题。任何设备都有可能出现故障。但在全同步复制模式下，集群中的节点被串联起来，如果单机可用性是 95%，那么集群整体的可用性就是 N个95%相乘，3个节点，可用性就是95%*95%*95%=85.7%，跟单机相比反而降低了。

所以再生产上很少会采用全同步这种方案。

最终一致性可以理解为主节点执行写操作并反馈成功时，不要求其他副本与主副本保持一致，但在经过一段时间后这些副本最终会追上主副本的进度，重新达到数据状态的一致。

从状态视角看，也存在很多问题，此时就需要从操作视角看。

最终一致性，在语义上包含了很大的不确定性，所以很多时候并不是直接使用，而是加入一些限定条件，也就衍生出了若干种一致性模型。

假设有一主两从三台数据库

1、写后读一致性

你发了一条朋友圈，你可以立刻看到这条消息，此时你刷新朋友圈，也应该看到这条消息，这就是写后读度一致性。从数据的角度来解析：

你发送的信息，保存在主库中，此时主库会同步给两个从库，数据都同步成功了，你一直刷新，自然都会看到。

如果只写入了主库，主库还没来得及同步给两个从库，此时你刷新一下，请求被分配到从库去读，这条消息就暂时看不到了。

如果主库成功同步给一个从库A，还有一个从库B在同步过程中，刷新请求落在从库A，你可以看到消息，然后再次刷新，请求落在从库B，又突然看不到你发的消息了，此时你不会崩溃吗？

写后读一致性要求我们写了一条数据进主库，之后不管有没有同步成功，我们都能看到自己写入的这条记录。

实现方式：可以将自己写后的读，指向主库。

2、单调读一致性

当你的朋友看到你发的朋友圈（从库A读取的数据）并点赞后，再刷新一次（从库B读取数据），结果发现消息没有了（从库A同步成功，从库B还在同步过程中），当从库A和B都同步成功，你朋友再刷新朋友圈，又看到你发的朋友圈，你朋友也会很懵逼。

单调读一致性就是说用户读到一个值，不会读到比这个值更旧的值。

假如X被赋值3次，分别是10，20，30，当你读到20时，后续只能读到20或30，不能再读到10。

实现方式：用户和副本做映射关系，比如通过hash把用户id固定在某一副本上。

3、前缀一致性

假如你朋友发了朋友圈，你在下面问他“中午吃的什么？”，你朋友在朋友圈回复你“中午吃的鱼”。你们远在国外的朋友看到朋友圈评论是“中午吃的鱼”“中午吃什么”。两个评论顺序反了。这可能是因为数据同步时，网络传输问题，导致从节点接受顺序和写入顺序不一致。

问题和回答存在一定的因果关系，但是同步时，忽略了这种关系。所以需要前缀一致性，可以考虑在原有的评论数据上增加一种显式的因果关系，这样系统可以据此控制在其他进程的读取顺序。

4、线性一致性

前缀一致性是显式指定一种关联关系，但实际场景可能更加复杂，不可能显式的加关系，所以就有了线性一致性。

线性一致性（Linearizability）就是建立在事件的先后顺序之上的。在线性一致性下，整个系统表现得好像只有一个副本，所有操作被记录在一条时间线上，并且被原子化，这样任意两个事件都可以比较先后顺序。

但是，集群中的各个节点不能做到真正的时钟同步，这样节点有各自的时间线。那么，如何将操作记录在一条时间线上呢？这就需要一个绝对时间，也就是全局时钟。

5、因果一致性

线性一致性强依赖于时间，还是有其弊端，因此有了因果一致性。因果一致性弱于线性一致性，但是有更好的并发性能。

因果一致性的基础是偏序关系，也就是说，部分事件顺序是可以比较的。至少一个节点内部的事件是可以排序的，依靠节点的本地时钟就行了；节点间如果发生通讯，则参与通讯的两个事件也是可以排序的，接收方的事件一定晚于调用方的事件。

因果一致性没有依赖于全局时钟，但依赖于逻辑时钟，借助逻辑时钟仍然可以建立全序关系，当然这个全序关系是不够精确的。因为如果两个事件并不相关，那么逻辑时钟给出的大小关系是没有意义的。

打赏

微博

微信

打印

docker笔记

Linux性能优化--针对CPU的一些指标

幽

幽冥领域

粉丝 2

博文 33

码字总数 21369

作品 0

成都

关注

私信

提问

加载中

请先登录后再评论。

删除一条评论

评论删除后，数据将无法恢复

取消

确定

数据一致性

幽冥领域

OSCHINA 社区

在线工具

微信公众号

OSCHINA APP

数据一致性

幽冥领域

OSCHINA 社区

在线工具

微信公众号

OSCHINA APP

其他人也看了：