第四天：没看书+解决存储问题方案

果然，由于各种出其不意，又是两天没写博客，也没看书，坚持这事果然不容易。

今天也没什么记得，只有一个问题还值得唠两句。

一个论坛，上传下载文件都到一个目录下面。最初的架构是这个文件夹下通过NFS挂载一个RAID5磁盘阵列，6T*10的阵列理论上已经是相当吓人了。可偏偏现在60tb的数据就这样华丽的写满了。结果现在NFS只能挂一个节点，麻烦大了。

当然了最简单无耻的方法就是在代码里在改吧改吧存到另一个文件夹里然后在另一个文件夹挂另一个阵列，到时候判断判断什么的，但是个人觉得审视不美观，现在还没办法动手术处理那60T的数据。

方案1：NFS + ln-s 应用服务器认不出这个路径，失败

方案2：ln-s + NFS 这回是阵列认不出路径，失败

方案3：NFS+LVM LVM没有加速，处理60T的数据不能接受，失败

好吧，我承认我选择了最简单无耻的方案

其实最初在软件架构设计上就应该考虑到会有今天，设计好良好的负载均衡和分布式文件策略。当然了，现在做也来得及，只要能应付那60T数据就可以

说的这不得不说说facebook的图片存储系统，最典型的nfs集群策略，大量使用cdn，RAID6+nfs的上千个磁盘阵列节点。再加上google的Haystack技术，完美

下一步，老老实实的看完企业应用架构吧。加上php的手头那点事。