FastCFS同步复制机制简介

本篇文章转载于 FastCFS 作者 余庆 大佬的 FastDFS分享与交流 公众号。

上一篇文章介绍了 FastCFS 采用数据分组的做法，一个数据分组的几个节点（如三个节点即三副本）之间是 Master/Slave 关系；FastCFS 采用数据强一致模型，通过 Master/Slave 结构的同步复制机制来保证数据一致性，本文将概要介绍这一机制的原理和关键点。

和单机系统相比，分布式系统因网络通信方面存在较大不确定性，要做到数据强一致的挑战非常大。业界分布式系统主流做法是采用 BASE 理论，有意避开数据强一致性这个难题。BASE 理论是 Basically Available (基本可用)，Soft State（软状态或中间状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE 理论比较偏工程实践，见文知意，需要进一步了解的朋友自行脑补。

采用 Master/Slave 结构，保证数据强一致的逻辑很简单。client 的更新操作只能由 Master 处理，然后 master 同步调用 slave 转发该请求。FastCFS 中 master 可以并发请求多个 slave，因此 client 的响应时间和 slave 数目（副本数）并不是线性关系。master 只会对在线（ACTIVE）的 slave 发起同步调用，那么 slave 因重启服务或网络通信异常导致掉线（OFFLINE），FastCFS 是如何处理的呢？

OFFLINE 状态的 slave 会进入数据恢复（追加数据）阶段，追上 master 的最新数据后，方可切换为 ACTIVE 状态。为了确保平滑切换，引入了 ONLINE 这一中间状态。

有朋友就说了，上面的同步复制方式很简单直接嘛，并没有多么高深的地方。嗯，简单的往往就是最有效的。有挑战的地方不在方案的复杂性，而在于工程实现。在保证数据一致性前提下，数据同步复制方案的两大关键点：维护精准的集群状态 和 slave状态平滑切换。

FastCFS 引入 leader/follower 这一机制来维护精准的集群状态。leader 通过选举产生，follower 和 leader 建立连接并每秒报告其自身状态（磁盘空间、数据版本号等）。当集群状态发生变化时，如 master 切换、slave 状态变化等，leader 会立即将变动消息推送给所有 follower。借助zookeeper 或者 etcd 也可以实现同样的功能，为什么要自造轮子呢？

原因有二：一、自主可控，减少依赖；二、简单高效，避免臃肿。

分布式系统在保证数据强一致性的前提下，还要做到高可用和高性能，挑战非常大。为了做到这一点，还有一个最为关键的地方，下一篇文章将为你揭晓。