简介：分布式文件存储解决核心知识介绍和面试题
数据爆炸的时代，产生的数据量不断地在攀升，基本都离不开文件存储
存储单位从KB、MB、GB、TB、PB到ZB级别的数据
图片、文档、素材、静态化页面、长短视频、安装包等一系列文件
业务应用内存储
传统的javaweb项目, 文件数量达到一定后占据大量的内存、磁盘和带宽, 无法满足海量请求的业务
开发容易-扩容难
分布式文件系统（Distributed File System)
海量数据对存储提出了新的要求，从而诞生了分布式文件存储
是文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点（可简单的理解为一台计算机) 相连，或是若干不同的逻辑磁盘分区组合在一起而形成的完整的有层次的文件系统
自研：扩容容易-开发难
面试题：做分布式文件存储，主要是想实现文件存储访问的高性能与高可用，如何保证分布式存储的高性能与高可用？
大家可以想到基本就是副本备份、双活、多活这种架构
在系统中通过复制协议将数据同步到多个存储节点，并确保多个副本之间的数据一致性，当某个存储节点出故障时，系统能够自动将服务切换到其他的副本
在分布式存储中高性能与高可用是矛盾的，比如要设计一个分布式存储系统，CAP定理也可以推断出来
对性能的考虑，记录数据时先写一个份数据到某个机器上并立即返回，然后异步发起多个数据备份过程。这种设计的性能最好，但存在“容错性”的风险，加入返回后，还没来得及同步给其它节点就宕机了，则数据就丢失（异步复制，也存在是写主节点到内存还是落到磁盘）
如果同时写多个副本，每个副本写成功以后再返回，则又导致性能下降，这个过程取决于最慢的那台机器的性能 (同步多写，是同步每个副本节点还是一个副本先)
那应该如何选择呢？
根据业务而定，如果要求性能更高，偶尔出现文件丢失或访问出错则可以异步复制
要求文件系统一定要高可用，则用同步多写的策略，牺牲一定的性能也要保证高可用数据一致性
基于上述的，大家还知道有一个很类似的消息队列就是支持这种操作
RocketMQ消息高可用里面的
同步双写、异步刷盘，即同时写到两个节点上的内存才返回，然后异步持久化到磁盘里面
本文作者为DBC，转载请注明。
