1、互联网上用户交分散，需要用CDN的模式，分层分区域部署NameNode，NameNode上数据汇总到上级，上级数据按需分发到下级。同一个区域的用户（DataNode）分配到同一个NameNode
2、用户DataNode机器可用性极差，按10%算，平均一个数据需要10个备份。不过可以有一定策略改进，比如让用户活跃时间跟用户等级挂钩，等级跟功能挂钩，以鼓励用户增加在线时间；存储数据可以分级别，高级别数据备份更多，可用性安全性速度更高，级别低备份少。
3、安全性考虑，其他用户存储在NameNode上的数据，不能被宿主机破解查看和修改
暂时想了这些，感觉再想下去要变成百度网盘或者迅雷了

讲技术不讲技术脉络的也都是流氓啊。那些去中心化存储的区块链项目，就没谁写出去中心存储应是借鉴或发展于hdfs等分布式存储方案。raid到hdfs立马好理解多了。我是看过ipfs，storj，sia等几个去中心化的存储方案。通过看今天的内容，我突然感觉开窍了，他们整得太复杂了，基于hdfs加上存储时空证明就能实现去中心化存储，实现高可用的技术细节考虑的当然不同了，而存储时空权益就把终端的高可用工作分散到具体用户了。当然，namenode是中心化部署还是代理节点部署还是要考虑一下。另，通过用户贡献的存储时长和空间换来的受益，这对用户的约束可能会随时间变化而减少，进而存储的可用性是不稳定的，但这里我想了两个方案:1，用户贡献出来的资源是为了储值的，获得权益是要零存整取，加大惩罚成本(这个估计他们实际做的会想到，我当时看时反正没看到)；2，整个分布式系统加一套蓝光备份系统，这种低成本数据存储方案是对要求高可用数据的备选项。

关于DataNode 故障容错感觉处理起来好复杂啊 假设numReplicas=2 由于机器故障导致DataNode 1宕机 此时为了保证numReplicas=2会复制数据 像下面的情况怎么处理呢
- 等全部复制完了 DataNode1重启了 那此时numReplicas=3 这种情况会处理吗？
- 或者复制到一半（即有些Block还没来得及复制） DataNode1重启了 这种情况又怎么办
- 或者集群勉强够用 实在没有多余的机器来复制DataNode1对应的数据了 又该如何

并且要是掉电或是网络异常 可能不是一个DataNode宕机 可能是怎个机架整个机房的DataNode的都宕机了

这个产品复刻 HDFS 原理是可以的。
NameNode 必须由运营者管理，解决了目录控制权就解决了绝大部分问题。
用户终端全是 DataNode，架构模型上没问题，但细节问题很多。
一类客观问题：网络环境、容量、读写速度这种，可以通过市场手段调节分配，比如在分享时可以设置该文件需要分几片、分多少节点、在哪些地域分散、最多存多久，付费者甚至可设置奖金激励存储者提供服务。当然最好的做法的是把这些规则打包成一个花“多少钱享受多少 SLA”的大众可理解的服务套餐，把存储节点的分布规则设成基于大数据统计预测后动态匹配的，淘汰表现不佳的存储节点，促使贡献者买“矿机”哈哈。
二类安全问题：如何防止存储者作恶，数据加密、校验是基本的安全设计也不难解决，最要命的是如何审计数据，识别用户谎报的信息，这个场景就像网络游戏外挂攻防一样，要做好全方位的通信安全，防止分享者花小钱存大文件，防止存储者用小流量赚大佣金，APP 也不能被破解，否则通信的来源也是不可信的，很容易造成恶意节点发送错误数据。

这东西要做肯定要费老功夫，如果研发难度太高，还是选择租机房开展云存储服务或卖终端级 CDN 设备（优酷路由宝、迅雷赚钱宝这种），这个容易些，商业逻辑也成立。