保证数据一致性是对存储系统的基本要求，对于分布式文件系统来说挑战比较大，本文将介绍FastCFS采用的数据一致性模型及基础结构。
说到数据一致性，大家会想到分布式系统必须符合CAP理论：一个分布式系统，不可能完全满足CAP，只能做到其中的两个，即 CA、AP或CP。
FastCFS的目标是支持跑数据库，保证数据一致性是基本要求；保证可用性也是分布式系统的一个基本要求，因此FastCFS选择全力做到 CA，万一发生网络分区，可用性可能会受到影响，但不会破坏数据一致性。FastCFS采用leader选举过半数等机制防止脑裂，并且有数据校验及自动修复功能；v3.5支持数据复制过半数机制，保证极端情况下数据一致性和可靠性。FastCFS的leader和master不是基于中心节点，而是以服务器分组为单元自洽的。由此可见FastCFS在架构和实现机制上采用分而治之的局部化做法，最大程度地规避了发生网络分区的风险。
FastCFS对数据分组采用master/slave结构，对于服务器分组采用leader/follower结构。细心的朋友会有这样的困惑：FastCFS居然有leader和master两种角色，只要其中一种不就可以了吗？二者都是大家所熟知的概念，我相信业界一定有leader + master的做法，但将二者并存于一组服务器，并且以原生方式实现，也许是FastCFS的独创。
FastCFS采用的是数据强一致模型，客户端的更新操作只能在master上执行，然后master通过RPC调用将更新操作同步给ACTIVE状态（此状态方可提供在线服务）的slave。因服务重启或网络严重抖动等异常导致slave掉线，slave将进入数据恢复阶段，追上master的数据后，才能切换为ACTIVE状态。
那么引入 leader/follower目的何在呢？因为一组服务器上通常会包含多个数据分组（为了便于集群扩容会预分配较大的数据分组，比如1024个；一组服务器上配置的数据分组建议不少于64个），每个数据分组的master选举如果按照选举流程来一遍，这个消耗太大。因此FastCFS创新地引入leader角色，由leader直接任命其管辖的若干个数据分组的master。一句话总结leader和master的产生机制：leader通过组内服务器选举产生，而master则由leader直接任命。
最后小结一下，本文介绍了FastCFS采用的数据一致性模型和基础结构，包括leader/follower和master/slave两种。
