上一篇文章介绍了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是如何做到的呢？敬请期待下回分解。
本文分享自微信公众号 - FastDFS分享与交流（fastdfs100）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。