FastCFS架构之连接篇

    上一篇文章讲到了FastCFS核心组件faststore的架构及特点，大家可能有些蒙圈，这次补上FastCFS各个模块之间的关系说明。老规矩，上图为敬：

    FastCFS的两大核心组件 faststore 和 fastDIR相互独立，通过clien端封装的file api library将二者连接起来。 这种做法有两点好处：1. faststore 和 fastDIR不直接依赖，降低服务端复杂性；2. 如果不需要使用fastDIR提供的元数据服务，可以直接使用 faststore api访问faststore cluster。比如后续实现块设备访问方式的话，只需要使用 faststore即可。

    faststore cluster有三个服务端口：cluster、replica和service， fastDIR cluster有两个服务端口：cluster和service。cluster和replica端口用于集群内部通信，其中replica端口用于server之间的数据复制，service端口对外提供服务。

    FastCFS交流群有朋友问了，一个端口不行吗，为啥需要两个甚至三个端口呢？FastCFS的设计和实现目标是支持跑数据库，除了保证数据一致性为核心的高可靠外，还需做到极高性能。FastCFS采用多个端口的做法，实现外部访问和集群内部通信相互隔离，最大程度降低外部和内部相互影响，提升网络吞吐量，从而提升整体性能。

    FastCFS服务端支持多块网卡，出于性能考虑，强烈推荐集群内部通信和对外服务使用不同的网卡。再次解答FastCFS为什么采用多端口方案，因为FastCFS允许只使用一块网卡（内部通信和对外服务均使用同一块网卡）。

    友情提示：使用多块网卡时，简单起见，每块网卡最好使用不同的网络分类地址，比如内部通信的网卡1使用192打头的IP，对外服务的网卡2使用 172打头的IP。

   最后是广告时间：经过不懈努力，我们最近刚建立FastCFS yum源，并且整理了简明扼要的安装和配置文档，欢迎有需要的朋友测试、使用和反馈。FastCFS使用交流群在gitee项目首页可以找到，欢迎感兴趣的朋友扫码加入。附gitee项目地址：https://gitee.com/fastdfs100/FastCFS