Drios

发布于: 21 小时前

路由算法

使用固定的虚拟节点,和redis一样

 

client写数据

为了提高数据的一致性,会同时写两个节点,一个节点失效了,另外一个节点还是可以写入

client请求失败时,会请求configserver,configserver也请求失败,就确定该节点失败

 

 

处理可用性——3种失效状态

  •  瞬时失效:间隔几百毫秒,连续写,失败次数不超过3次

  • 临时失效:

  •  产生:

  1. 连续写失败超过3次,上报给configserver

  2. configserver请求上报的节点

a.也失败,确定该节点为临时失效状态

b.成功,通知上报的client,你自己的问题 

为什么需要configserver仲裁?因为如果只是你不能访问,你不写,别的节点可以写,这样会导致数据不一致

  • 处理:

1. 同时写两个节点时,当其中一个节点临时失效,client会在集群种找一个备份节点,继续同时写两个节点:一个旧节点,一个备份节点,备份节点数据以操作记录格式写入,类似于mysql的binlog;

2. 当临时节点恢复,物理节点X将操作记录同步到节点2,同时client也写开始写节点2,两种写入数据冲突时,通过比较时间戳来覆盖。

3. X日志都同步完后到节点2后,节点2完全恢复,可读写。

 

  • 永久失效:处于失效状态超过2小时    

  • 处理:

  1. 写正常节点和备份节点两小时后,node2还是没恢复,下线node2机器

  2. 将一个正常节点的数据A1 scp到空白节点node3上(上线时,会额外配置一个空节点来备用)

  3. 复制完数据后,空白节点以临时失效状态启动,重复失效节点恢复的操作(一边将备份节点的两小时操作同步到node3,一边client将最新数据写入node3),直至节点数据完全同步。

  • 实际上,并没有使用这个状态:

  • 由于一直挂着台空白机器,机器挂的概率很低,机器有点浪费;

  • 由于还有一个剩余节点可用,足够时间处理节点临时失效。

 

风险点:node1也失效了

 

集群扩容

1. 将node2设为临时失效,停止读写,node1继续提供服务

2. 将node2数据(只由一个数据文件保存)scp到新增节点X

3. 对node X执行临时失效时的操作,直至nodeX数据和node1完全同步 

 

   风险:此时node1挂了

 

CAP分析

A可用性不行了,常常C一致性也不行了

发布于: 21 小时前 阅读数: 5
用户头像

GalaxyCreater

关注

还未添加个人签名 2019.04.21 加入

还未添加个人简介

评论

发布
暂无评论
Drios