Drios

路由算法



使用固定的虚拟节点，和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一致性也不行了