key-value系统设计

本文探讨了构建高效、高可用和可扩展的键值存储系统的关键技术,如hash映射、数据分片、一致性保证方法(如复制、向量时钟和QuorumConsensus)、CAP理论和BASE理论,以及向量时钟和Markletree在解决数据一致性问题中的应用。
摘要由CSDN通过智能技术生成

一个key-value存储属于非关系型存储,为了保证高效的存储和读取,功能可以尽可能简单,主要的两个功能点put(key,value)/get(key),一个高可用和易扩展的k-v系统应该具备一下特点。

  1. 效率要高
  2. 如何存储海量数据
  3. 高可用
  4. 高扩展
  5. 自动扩缩容
  6. 可调节一致性
  7. 低延时

保证每种特性应对策略

1、效率要高
采用hash映射可以快速确定元素的位置。

2、如何存储数据
对数据进行分片

3、高可用
复制多个数据副本,使用向量时钟,保证所有的请求能够写入成功,不会因为请求不会阻塞得不到响应。

4、高扩展
为了能够方便扩展,减少扩缩容过程中的改动和数据迁移,使用一致性hash

5、自动扩缩容
一致性hash算法

6、可调节一致性
使用鸟群算法,又叫法定人数选举(Quorum Consensus)的共识算法,通过设置不同阈值满足不同场景的数据一致性。
N = 节点副本数量
W = 成功写入的节点数量。
R = 成功读取的节点数量
If R = 1 and W = N, 系统希望读快速读
If W = 1 and R = N, 系统希望写高效
If W + R > N, 要求强一致性保证 (通常 N = 3, W = R = 2).
If W + R <= N, 不要求强一致性

7、低延时
数据分区,使得查找变快;使用向量时钟保证一致性,而不是使用加锁的方式,避免其它请求因为获所取资源加锁、增加等待时间,而增加RT。

遇到的问题

1、为了解决单机最致命的内存空间有限,使得系统高可用、易扩展,需要设计成分布式系统,为了使得设计的系统,面临CAP类型选择问题,CAP每个含义,每种特性如何保证,其中partition torlence中的partition应该理解为分裂,表示网络的断开?牺牲就是不用保证吗,真实中CP不会存在,是因为这种保证了这两项系统不可用?不同组合适用的系统类型是什么?

设计可靠、高可用的分布系统,希望系统能同时满足CAP三点,而CAP理论也叫分布式理论,主要为了说明在设计分布式系统时,最多满足三个点中的其中两个,其中
C全程是consistency,一致性,所有客户端在同一个时间对于相同请求访问任意一个服务节点,看到的数据都是相同的,这里指的是强一致性。
A全称为Avaiability,可用性,即使在某个服务节点下线的情况下,客户端的每个请求都能够得到响应。
P全Partition Torlence,分区容错性,即使在节点之间断开通信的情况下,系统整体依然可以提供服务。

首先,网络断开造成节点间网络分区在真实世界中是不可以避免的,如果节点网络分区,整体系统就无法对外提供服务,违背高可用,在大多情况是无法接受的,不能保证这一点的系统,会经常造成系统不可用,系统设计出来的意义也不大,所有P往往是要满足的。当节点间网络分布,数据无法通信,C和A就无法同时满足,要是满足一致性,在数据节点网络分区期间,就要有一些节点不可用,这就违背了Avaiability(暂时不考虑请求重路由),反过来,如果所有节点都可用,节点间数据无法及时同步,consistency就无法满足,综上,在设计可靠和高可用的分布是系统时,需要在CP和AP之间做权衡。

基于各大厂的实践总结经验,在CAP的基础上,提出了BASE分布式理论,基本可用(Basically avaiable)、软状态(soft state)和最终一致性(Eventually consistency),核心思想是即使系统无法达到强一致性,每个系统都可以根据自身特点,采用适当的方式达到最终一致性,更准确来说,BASE理论是在保证AP两点情况下演进得来的,从这一点,也说明了系统设计时高可用的重要性,这种高可用时牺牲强一致性换来的。

Basically avaiable是指系统出现不可预知故障时,允许部分功能不可用,但绝不等价于系统整体不可用,比如因为断电或者网络故障,导致请求时间增加,再或者出现某些故障进行降级。

Soft state 允许系统中数据存在中间状态,并且该状态不会影响系统整体可用性,也即允许不同数据节点之间同步存在一定延迟。

Eventually consistency是指允许系统中所有数据副本,经过一段时间后,可以达到最终一致性。

https://juejin.cn/post/6844903929839353864

2、什么是强一致性、弱一致性和最终一致性,弱一致性和最终一致性二者区别?为什么说弱一致性不能保证subsequent read operations 可能无法看到最新更新的值?
强一致性,一旦一个数据写入成功,后续的任何读都是最新写入的数据。
弱一致性,是指系统中某个数据更新后,即使过了“不一致时间窗口”,后续读到的数据也不一定是最新的;
最终一致性,是指过了一段时间后,系统中各数据副本最终会达到一致,这也是二者的区别。

3、向量时钟是如何解决冲突的?
向量时钟是为每个数据发生所有事件在所有节点的一个版本,用来跟踪时间发生先后顺序和检测是否发生冲突,具体冲突的解决方式还要结合具体的业务。当数据同步的时候,发现对于同一份服务器版本小于当前数据版本,就是发生了冲突。向量时钟缺点是,向量时钟只能检测出来冲突,需要手动实现冲突解决逻辑,同时当向量时钟中的长度不断增加时,超过阈值需要删除旧的记录,会导致无法追踪完成的变更历史,但在Dynamo的论文中提高,亚马逊实际生成环境中没有遇到过向量时钟中数据项超过阈值,向量时钟中每个数据项对应一个节点,通常服务器节点数量是有限的。

4、一个服务节点有问题为什么至少需要两个节点才能判定?
1)网络的不可靠性:可能由于网络通信问题,导致一个服务无法联系上另外一个服务,认为联系不上的服务已经下线。
2)故障检测误报:例如一个服务资源过载,导致无法及时对某次请求及时响应。
3)延时或者异步的故障信息传播:服务因为一些临时故障或问题终止了服务,很快又恢复了,但是服务下线的消息依然在传播,集群中节点对该节点的状态感知不一致。
需要两个独立信息确定一个节点已经下线,是为了提高可信度和准确性,在实际应用中,可以设置不同的数量还标示一个节点已经下线。

5、如果是因为S0和S2之间有网络分区导致S0没有接受到S2的心跳,其它节点收到S2下线的信息如何处理,这样对于统一个节点,服务中不同节点的判断逻辑就会出现不一致,如何处理?
首先S0判断一个节点下线,会发送确认信息给其它节点,如果有其中一个节点返回了true,加上当前节点本身,就有两个节点认为该节点下线,同理,返回为true的节点想其它节点发送确认信息时,当前节点也会放回true。

6、如何判断一个节点是临时故障还是永久故障?
首先系统很难通过某种方式直接确定系统是临时故障还是永久故障,一般通过设置一个时间区间,多长时间内恢复为临时故障,超过设置区间认为是永久故障。

7、markle tree是如何进行大数据的差异性比较的?为什么使用Markle tree进行副本之间数据进行比较,而不是逐个元素进行比较,创建Markle tree的过程中也需要对所有元素进行遍历?
首先Markle tree 也叫hash tree,是一种二叉树数据结构,每个节点包含子节点的hash值,树的根节点包含所有叶子节点的hash值,真正的数据存储在叶子节点中,通过比较根节点可以快速缺点连个数据副本之间的差异节点,Markle tree除了用在分布式系统中,在区块链中也广泛使用。
使用Markle tree比较数据节点之间的差异性,每次只用传输根节点进行比价,减少了副本之间数据传输,同时Markle tree一旦创建完成,比较的速度也比逐个元素比较快。

8、为什么在调节一致性中,W+R > N可以保证强一致性,又为什么在现实环境中是不存在的?

为什么W+R > 就是可以保证强一致性,W+R>N,表示一定有一个节点写入和读都都是成功的,强一致性是指,一旦一个数据写入成功,后续的任何读获取的都是写入成功的数据。写读的里面一定有个写入成功的,如果我们只要判断剩余R-1个和这个写入成功的节点读取到的数据是否一致就可以判断数据是否是否一致,这也就可以保证时刻监控我们的数据是否强一致性。
如果每次写入和读取都要求多个节点,一则会增加系统服务的响应时间,而来,如果某些节点宕机,可能导致服务无法正常对外提供服务。通常W和R都是1,失败了可以进行重试,写入成功后,异步的将数据在多个副本之间进行同步。

  • 17
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值