数据一致性分析

常见三副本kv存储系统架构介绍

  目前很多常见的分布式存储系统都是基于三副本机制的，如ceph、小米的飞马系统等
  一般由三个部分组成，实现kv存储层（如ceph的osd）、client端（发起io操作）以及mds(metadata server)    

1. kv存储层实现持久存储和io复制
2. client实现io分发
3. mds管理包括kv存储层进程状态、数据分布

数据分布算法

  hash算法根据数据的key将数据映射到物理存储节点上，这种作为在存储节点扩减容时，会导致大量数据迁移。
  一致性hash是将物理节点组成一个环，计算出hash值后，将数据路由到hash值后面最近的一个节点上，这样当一个节点失效时，数据只用迁移到下一个节点上。
  这种物理节点直接参与映射的方式，可能导致数据倾斜，所以引入虚拟节点(ceph中的pg)，虚拟节点数目为物理节点的数倍。引入虚拟机节点有两个好处：

1. 数据是存放在固定虚拟节点上的
2. 我们管理虚拟节点到物理节点的映射时，可以根据物理节点是否在同一个机架等来影响数据的分布，减小故障域。

一次写io过程

1. mds节点管理着虚拟节点到数据副本的映射关系，包括虚拟节点对应的各个数据副本所在存储节点。
2. client节点缓存着虚拟节点到主副本信息，kv存储层缓存着虚拟节点到主副本信息和虚拟节点的三副本信息。

这些信息都是从mds查询的

3. client节点根据数据的key计算出虚拟节点，在根据虚拟节点找到主副本物理节点，然后将io发送给主副本节点。
4. 主副本节点收到请求后，将数据写入本地，同时复制给其他副本，等到副本都写成功后，响应给client。

常见三副本存储系统如何保证数据一致性呢？

  有如下三个要素：

1. 基于日志复制的方式，保证日志在各副本顺序一致，那么根据日志回放出来的数据，最终状态也将趋于一致。
2. 主副本会将更新操作发送到各个副本，只有各个副本都回复写成功后，才会响应client端。

如果一切正常，上面两点足够保证数据一致了，因为从client的视角看，各副本是强一致的，发生主副本切换，也不影响数据一致性。

3. 主副本故障时，mds选新主副本时，必须选状态正常的副本。（领导选举）

这里说的状态正常即新的主与原来的主数据一致。

一条条解释

请求ID

主副本对每个更新操作维护一个ReqID，收到更新操作ReqID++

任期

每次主副本切换，看成是一个新的任期，TermID++，ReqID置0

备副本切换，需要更新任期吗？？？
<TermID, ReqID>可以唯一定位一个更新操作

日志顺序一致

日志：记录了更新操作（写、删）的位置、长度、操作类型以及<TermID, ReqID>。可以看到日志中没有记录数据，所以，日志可以增加一个状态，表示数据部分是否以及落盘。注意日志本身也是持久化存储的，可以放在高速ssd中。

1. 主副本收到请求，会检查client端发送来的请求TermID是否与自己的相同，相同时，会自增ReqID，并本地记录一条日志。

不同时，会出发TermID较小的一方反查映射信息

2. 备副本收到请求时，会检查自己的<TermID, ReqID>是否比收到的主副本的仅仅小1，只有仅仅小1时才会接受。

等于1的时候 是否要接受???

备副本异常

各个副本节点都和mds保持心跳，每秒一次，5次mds将这个副本设置为异常。

1. 主副本将数据复制到备副本时，有超时重试机制，等待备回复ok
2. 如果备副本异常了，mds会通知主副本，备已经异常，无需等待这个副本回复。

这里非常重要，是mds通知主副本备异常了，所以如果这个场景，发生切主时，mds一定不会选择这个异常的备

备副本异常恢复

备副本从故障中恢复时，由于有部分io自己没有，这种状态的备会被mds标记为catchup状态，它也没有升主资格。
当这个备catchup完成时，会将自己catchup完成上报给mds，mds将起状态标记为正常，恢复了升主资格。
catchup过程：

1. 备先根据自己本地log中最新的<TermID, ReqID>去主副本上确认自己缺少哪些数据，然后从主上将这些数据读回来，写到本地
2. 在第一步的过程中，备副本收到的新io会记录到另一片区域（避免与catchup io发生写覆盖)，等第一步完成后，再将这部分数据写到真正的位置上。
3. 在第一二步都完成后，向mds上报自己catchup完成。

从以上介绍中，可以看出mds在备副本是否具有升主资格是绝对可靠的，所以在切主时，一定不会将主切到一个数据与老主不一致的副本上。