好久没有写文章了。今天的主角FastCFS让我有兴致拿起键盘，向大家来推荐它。
FastCFS项目背景介绍
FastCFS 项目在gitee和github上同时开源，地址分别为：-
- https://gitee.com/fastdfs100/FastCFS
- https://github.com/happyfish100/FastCFS
作者是存储系统方面的大佬余庆老师，如果你对FastCFS不熟悉，但是FastDFS我相信大家都耳熟能详，FastDFS作为一款分布式对象存储系统，以开源、简洁、易用、高性能而著称，像一股清流深受大家喜欢。
说回今天的主角FastCFS。
当前，云原生已经成为应用开发者在选择架构设计时的首选，Kubernetes（以下简称k8s）逐渐成为云原生时代的基础设施，熟悉k8s的同学都知道k8s中网络和存储是两大难点。
特别是支持云原生的存储系统，大家在选择的时候都没有比较好的解决方案，商业话的存储买不起，开源的云原生存储要么性能达不到要求，要么运维复杂，并且基本上都是不是国人开发的，比如：Ceph，OpenEBS，Longhorn等。
在这样的背景下，FastCFS在余庆老师团队努力下横空出世。
私底下问了余老师，这个项目他2020年1月份全职开发，到现在已经有两年了时间了。在现在这样的社会环境下，余老师不忘初心的做法确实令人由衷的敬佩，忍不住想给他点赞。FastCFS秉承了fastDFS的气质：简洁、开源、高性能、支持云原生，关键是符合中国人的使用习惯，好交流（有需求或建议直接用中文撩他，哈哈)。
FastCFS 介绍
官方的一句话介绍是：
可以跑数据库的高性能通用分布式文件系统
不过我觉得更准确的是：
FastCFS是一款开源的，支持云原生的高性能分布式存储系统。
余老师在他的技术文章中提到：
FastCFS在保证数据强一致的前提下，同时做到了高性能，完全满足数据库对IO性能和数据一致性的严格要求。软件本身不应该成为系统的性能瓶颈，这是我奉行的原则并一直为之实践。若有朋友发现FastCFS在高端服务器上性能发挥不出来，欢迎来找我（tiguan）。
这是一种霸气且有底气的态度，并且更难的是FastCFS完全自主研发，用C语言原生实现，除了依赖libfuse实现文件挂载外，不依赖任何第三方软件。
那么FastCFS是怎么做的呢？
FastCFS的基本概念和核心组件
FastCFS分成服务端、客户端、 CSI三个部分，另外还贴心的提供了运维工具。
- 服务端有三个核心组件是 FastStore 、 FastDIR、FastAuth。
- 客户端是利用libfuse实现的文件挂载服务，可以直接以文件的方式访问FastCFS的存储系统
- FastCFS CSI 是一个基于k8s CSI标准来实现的，用于支持k8s来使用FastCFS，实现存储卷的创建、加载和读写操作。
1、FastDIR介绍
FastDIR作为通用分布式文件系统FastCFS核心组件之一，FastDIR是一款高性能、大容量分布式目录服务，除了支持文件系统基本特性外，还实现了如下特性：
- 支持全部类型：如socket、字符设备、符号链接等，还支持硬链接；
- 文件锁：完全支持POSIX文件锁，支持按范围加/解锁；
- 文件扩展属性（x-attribute），V2.0开始支持，用于保存存储池相关属性。
FastDIR支持命名空间，一个命名空间对应一套目录结构，多个命名空间的目录结构相互独立，可以通过命名空间隔离不同应用。FastCFS 对应k8s的支持就是通过存储池来实现的，一个存储池对应FastDIR的一个命名空间，在k8s中对应的一个PV。
另外FastDIR通过插件方式实现数据存储引擎，采用binlog + 存储引擎插件，按需加载inode数据，单机以有限内存（如64GB）支持100亿级的海量文件。
2、FastStore介绍
上次来自余老师的技术文章，由上图可以看出 FastStore对服务器和数据均采用分组方式，服务器分组简称 SG，为物理分组；数据分组简称 DG，为逻辑分组。FastStore的server各自管理数据块（文件块）索引，数据块的元数据采用无中心的分布式架构。FastStore本质是一个分布式KV系统，key是数据块所属的对象ID（inode） + 偏移量（offset），value是数据块内容。FastStore采用的数据路由规则：数据块key按数据分组数（DGC）求模得出所在的数据分组，即：block_hash_code % DGC。
因此，部署集群需要注意：
DGC一旦确定就不可更改，否则将导致数据访问混乱！
如果数据增长远超预期需要增大DGC，只能搭建一套新集群，在新旧两套集群并存的情况下，把原有数据手工迁移到新集群，迁移完成后切换到新集群。
另外，为了便于以后增加SG进行扩容，DG数量（DGC）必须事先充足地预估数据规模后确定下来，生产环境建议最小配置 256。友情提示：尽可能乐观地预估数据增长规模，宁多勿少，不存在过犹不及的问题。
FastStore架构有如下特点：
* 基于数据块的无中心设计（类一致性Hash），理论上可以无限扩容；
* 分组方式（SG和DG），简单高效；
* 数据分组内采用Master/Slave结构，简单有效的数据一致性保证。
3、FastAuth
FastAuth的目的就是为了更好地对接虚拟机和K8s，实现了存储池和访问权限控制，并支持配额。
FastAuth核心功能就是用户和权限体系，为了保证高性能且不依赖第三方组件，auth模块精心设计，采用基于session的分布式访问控制，session由Auth server生成并分发给上次提到的FastDIR 和FastStore两大组件 ，实现了session本地验证。
一句话总结：FastCFS的用户权限体系采用集中管理，分布式验证的做法，做到了极致性能。
4、FastCFS-Fuse客户端
FastCFS-Fuse客户端是基于FUSE的标准文件接口已经实现。可以使用FastCFS的fused模块mount到本地，为数据库、虚拟机以及其他使用标准文件接口的应用提供存储，同时也方便运维人员去查看文件内容。
5、FastCFS CSI
FastCFS CSI ， 是标准的容器存储接口实现，该驱动器为容器编排器k8s管理FastCFS类型卷的生命周期提供 CSI 支持。
主要功能包括
- 静态供应 - 创建一个新的或迁移现有的 FastCFS 卷, 然后从 FastCFS 卷创建持久卷 (PV) 并使用 PersistentVolumeClaim (PVC) 从容器中消费 PV。
- 动态供应 - 使用PersistentVolumeClaim (PVC)请求 Kuberenetes 代表用户创建 FastCFS 卷，并从容器内部消费该卷，支持StorageClass。
- 挂载选项 - 可以通过在持久卷 (PV) 中指定挂载选项，来定义卷的挂载方式。
- 卷扩充 - 扩充卷的大小。
需要注意的是：FastCFS-CSI 不支持删除静态卷。PV 规范中的 persistentVolumeReclaimPolicy 必须设置为 Retain，以避免在 csi-provisioner 中尝试删除 PV。
随便提一句，FastCFS CSI 有两种实现，一种是fastCFS-fuse客户端和fuse客户端代理模式。
以上对应FastCFS的基本概念和组成，来自于余老师的技术博客文章，可能有表述错误或者理解偏差，请直接移步余老师博客：https://my.oschina.net/u/3334339
总结：
FastCFS定位为一款强一致性、高性能、高可用、支持百亿级海量文件的通用分布式文件系统，可以作为MySQL、PostgresSQL、Oracle等数据库，k8s和NAS的后端存储。
到现在2022年1月份最新版本是V3.1.0已经具备了基本生产可用的状态，经过笔者的测试性能正如余老师所说非常好（后面的文章会提到）。当然在文档、自动化扩容、监控、运维上还有一些欠缺，但是这些都在一步一步的按计划进行中，并且速度非常快。
做一款产品非常不容易，做一款分布式云原生存储产品更加困难，让我们一起参与到FastCFS的共建中，让FastCFS早日成为云原生存储的标杆。
本篇对FastCFS的介绍先到此，后面会把笔者部署体验FastCFS集群，并在k8s中通过CSI连通FastCFS集群的过程写出来，希望能够帮助到搭建FastCFS碰到问题的同学，或者想尝试FastCFS的同学。