本篇文章转载于 FastCFS 作者 余庆 大佬的 FastDFS分享与交流 公众号。
上一篇文章介绍了 FastCFS 服务端两大核心组件：FastDIR 和 FastStore。其中 FastDIR 管理文件元数据，FastStore 以分块方式存储文件内容。FastDIR 和 FastStore 均采用 Master/Slave 结构，Master 不需要手工配置，由程序自动选举产生，并且做到了 failover。FastDIR 架构是FastStore 架构子集（特例），因此我们着重介绍 FastStore 的架构及其特点。
无图无真相，先上 FastStore 的架构图。
FastStore 对服务器和数据均采用分组方式，服务器分组简称 SG，为物理分组；数据分组简称 DG，为逻辑分组。
FastStore 的 server 各自管理数据块（文件块）索引，数据块的元数据采用无中心的分布式架构。FastStore 本质是一个分布式 KV 系统，key 是数据块所属的对象 ID（inode） + 偏移量（offset），value 是数据块内容。
FastStore 采用的数据路由规则：数据块 key 按数据分组数（DGC）求模得出所在的数据分组，即：block_hash_code % DGC。可见 DGC 一旦确定就不可更改，否则将导致数据访问混乱！如果数据增长远超预期需要增大 DGC，只能搭建一套新集群，在新旧两套集群并存的情况下，把原有数据手工迁移到新集群，迁移完成后切换到新集群。
一个 SG 由一台到多台服务器组成，组内的数据是冗余关系（服务器数即数据副本数）。一个 SG 可以容纳多个 DG，为了充分利用 CPU 等硬件资源，建议生产环境一个 SG 配置的 DG 数量不少于 CPU核数 / 2，开发测试环境至少配置 16 个。建立 FastCFS 集群时，可以只有一组服务器（即一个SG）。为了便于以后增加 SG 进行扩容，DG 数量（DGC）必须事先充足地预估数据规模后确定下来，生产环境建议最小配置 256。友情提示：尽可能乐观地预估数据增长规模，宁多勿少，不存在过犹不及的问题。
FastStore 服务器扩容采用数据分裂的做法，支持在线扩容，可以一次扩容一组服务器。当集群规模较小（比如 SG数 <= 4）时，建议一次扩容一倍。
总结一下 FastStore 的架构特点：
- 基于数据块的无中心设计（类一致性Hash），理论上可以无限扩容；
- 分组方式（SG 和 DG），简单高效；
- 数据分组内采用 Master/Slave 结构，简单有效的数据一致性保证。
保证数据一致性是分布式系统面临的挑战，FastCFS 是如何做到的呢？
敬请期待下回分解。
