分布式存储和一致性模型当单片系统达到它们的极限时,它们开始被扩展的分布式系统所取代 。这一趋势始于20年前的计算领域,当时大型机被服务器群所取代 。然后进入了存储领域(数据库、文件系统) 。在数据库世界中,关系与NoSQL的争论已经激烈了一段时间 。
今天,我想和大家谈谈分布式数据存储平台和一致性模型 。在规划存储基础设施时,这是一个非常重要的需求 。
让我们从一些基础知识开始 。在分布式系统中,假设单个节点会失效 。系统必须对节点故障具有弹性 。因此,为了冗余,数据必须跨多个节点进行复制 。
在这种情况下,让我们问以下问题:“如果我在一个节点上执行写入(或更新)操作,我是否总是能看到所有节点上更新的数据?”
这似乎是一个无关痛痒的问题 。每个人都会给出肯定的回答 。“咄,当然!” 。但不要这么快 。
这在分布式系统中实际上是一个很难解决的问题,特别是在保持性能的时候 。做出这种保证的系统被称为“严格一致” 。然而,许多系统采取了简单的方法,只提供最终的一致性 。
最终一致性vs严格一致性让我们定义最终一致性和严格一致性 。
最终一致性下面的视频演示了最终一致性的过程 。
过程总结
- 从客户机写到节点1
- 从节点1向客户端确认
- 最终写入通过集群传播到节点2
- System finally return latest write:通过添加单词“finally”来削弱一致性条件
- 如果节点失败可能导致数据丢失:添加“假设没有永久故障”的条件 。
过程总结
- 从客户机写到节点1
- 写入通过集群传播,从节点1传播到节点2
- 从节点2到节点1的内部确认
- 从节点1向客户端确认
- 系统总是返回最新的写操作:对于任何传入的写操作,一旦客户端确认了写操作,从任何节点读取的更新值都是可见的 。
- 有保证的数据弹性:对于任何传入的写操作,一旦向客户端确认了写操作,更新就会受到冗余节点故障的保护 。
文章插图
严格与最终一致性
为什么不总是使用严格的一致性?主要是因为实现严格的一致性会显著影响性能 。具体来说,延迟和吞吐量将会受到影响 。影响的程度取决于具体情况 。
严格的一致性并不总是必需的,在某些用例中最终的一致性可能就足够了 。例如,在购物车中,假设添加了一个项目,但数据中心失败了 。对客户来说,再次添加该项目并不是一种灾难 。在这种情况下,最终的一致性就足够了 。
然而,你不希望你的银行账户刚刚存入的钱发生这种情况 。因为节点失败而导致资金消失是不可接受的 。财务交易要求严格的一致性 。
为什么企业存储需要严格的一致性在企业存储中,存在最终一致性是正确模型的情况,例如跨站点复制的例子 。但在绝大多数情况下,严格的一致性是必需的 。让我们看几个需要严格一致性的例子 。
扩展文件存储碰巧有一种主要的扩展文件存储系统只提供最终的一致性 。数据只写入一个节点(NVRAM上)并被确认 。一个企业客户曾经向我解释说,在负载过重的情况下,一个节点可能会被标记为脱机 。实际上,它是关闭的,导致客户端在几秒钟前成功编写的文件出现“文件未找到”错误 。这对它们的应用程序造成了严重破坏 。
从备份中即时恢复下一代扩展备份解决方案提供了从备份中即时恢复VM 。这样的解决方案从备份系统上的备份映像副本引导虚拟机 。备份系统在恢复期间充当主存储,直到可以使用storage vMotion将数据移动回原始数据存储为止 。好处很明显:你可以尽快恢复业务 。
然而,许多扩展备份解决方案只提供写操作的最终一致性 。因此,如果恢复节点上发生故障,应用程序就会失败,系统就会丢失生产VM的实时数据 。
数据保护严格的一致性保证用户总是能看到最新的数据,并且数据一旦写入就受到保护 。由于严格的一致性,即使基础设施出现故障,也能保证应用程序可用性/正常运行时间和没有数据丢失 。
推荐阅读
- 改过自新的词 改过自新过的意思
- 烂大街的Nginx+Redis分布式锁+MQ+MDB架构设计
- 「分布式架构」“一切都是分布式”说最终一致性
- 图解Raft:应该是最容易理解的分布式一致性算法
- 开启WSL之旅
- 探索3种顶级「集成框架」Apache、Spring和Mule
- 分布式系统核心问题简介
- Python流程控制语句详解
- 四阶行列式的计算方法是什么?
- 什么是链路追踪?分布式系统如何实现链路追踪?