中等规模网站的UGC图片存放规划

　　好像现在是个网站就允许用户上传头像，其中一部分还允许上传相册、个性背景图之类的东西。对图片的规划各村都有各村的高招，这里只是抛砖引玉、提个醒：当文件膨胀到一定规模的时候再去改就来不及了，在一个项目的草创时期，让一个人多花两个星期的时间来琢磨这个“小”问题也绝对称不上是过度设计。
　　我对中等的定义：图片所占空间在1T数十T之间。
　　功能需求
　　基本的就两点：排除重复，和可扩展性。
　　排重并不为很多人所重视，因为对很多人来说短期可以承受，实际经验重复的占了50（一些流行的图片会被重复上传很多次），但问题是这里还关系到另外一件事：审核。例如一些很流行的黄图会被频繁的被不同人重复上传，这也是不小的审核工作量。
　　具体设计
　　简单的说就是MySQL单点来保证唯一，将文件MD5转换为递增ID，再将固定数量的文件分成组，例如最简单的MySQL表可以这样。
　　CREATETABLEIFNOTEXISTSuploadpic（
　　idbigint（20）unsignedNOTNULLAUTOINCREMENT，
　　hashbinary（16）NOTNULL，
　　PRIMARYKEY（id），
　　UNIQUEKEYhash（hash）
　　）ENGINEMyISAMDEFAULTCHARSETucs2AUTOINCREMENT1；
　　每次有上传，先MD5、INSERT，成功就返回ID，失败就重新SELECT找以前的ID
　　文件就是整个ID的补零切三段，如12345保存为实际的文件upload000012345，不保留扩展名，统一发送HeaderContentTypeapplicationoctetstream
　　首要原则是只新增，不改写（除了审核后删除的）
　　调优
　　上面所述只为了方便理解的最精简的方案，还有很多事情可以做。
　　用于发号的MySQL仅仅是写入单点，对于已经生成的hash，可以定期生成Archive引擎的只读表。然后新上传时以SELECTINSERTSELECT的顺序获取ID（这时候，第三步的SELECT是极其罕见的）。
　　如果是nfs挂载，初期可以挂整个upload，后期可以以一级子目录为单位，分散在不同机器上。如upload001和upload002挂在机器A上，诸如此类。这样我们可以每M个图片为一个挂载单位（下面简称MUMountedUnit）。如果图片的平均大小是200K左右，则每个MU的平均大小应该在1M200K200G左右。由于内容不再改写，老的MU可以到处搬动、甚至分散到不同机房，其实是类似flickr的farm。static子域名。
　　实际磁盘问题是个大问题，这方面网友DruggoYang给了我很多经验，他最早面临的问题是大量随机读写、几乎没热点，大概是文件实在太碎，硬盘反倒在网卡之前成为瓶颈，银弹是有：SSD，不过太tmd贵了。最后他们是用的LVS，那已经是我知识体系以外的东西了。
　　我想到的解决方法被DruggoYang评价为自己做软RAID：不同MU挂到不同盘，用nginx访问，或者系统本身瓶颈，那就若干个Server有相同的MU，做轮询。但总之我不推荐做磁盘RAID，这可能是我还没搞明白，也可能真的如此，就拿最简单的两块硬盘做RAID0来说，按我的理解，每读一个文件的时候，两块磁盘都需要定位，而两块独立的磁盘却可以分别各定位一个文件，据说也会受磁盘控制器的限制，但大体上不影响我的我的结论：RAID的优势应该在连续读写上，而随机读写反而会因为短板效应而略微降低IOPS。总之这问题我只能纸上谈兵，有条件应该拿几块硬盘测一下的。
　　此外，诸如目录分级是1000还是100个文件一组，还是用其他进制，都可以细测。记得以前看过一个单目录文件数的Benchmark，可惜后来再也找不到了（有谁能提示一下？），隐约记得500比较合适，因为这里需要频繁手工搬动，索性就弄个人脑容易识别的数了
　　另外为了防止遍历需要加个扰码，这也很容易了。
　　至于缩略图接口，另算
　　应用特例：头像
　　其实每个网站都有的图片机制是头像，现在普遍的规则是用户ID补码，补码可以是更新次数（如douban）、时间戳（如t。sina）、文件名（如twitter）之类的。补码的主要目的是为了靠改变URL而绕开HeaderExpires
　　但直到上家公司的产品部门在全面模仿Facebook运动中，想要实现Facebook里的一个功能：所有图片的大一统，如新上传的图片进相册、可以将任意一张图片设为头像，而收藏功能的流程跟自己上传几乎是一样的，等等，虽然这个改动过于底层以至于辞职一年多后公司彻底黄掉也没能看到它实现，但我还是很喜欢这个大一统的：不去考虑一张图片被哪些地方引用，只管存就是了，而所有涉及到图片的地方，都保存的是图片ID，因此只看某一张图片的URL，你不知道头像的主人是谁：有可能其他人也用相同的图片做头像，或者在某人的相册里。
　　问题