事情是这样的，我今天做了图片接口，接触到了现有图片的存放策略，觉得这里面有些东西值得好好想想。
从物理结构上说，现在的存放模型是这样的：
1.目前只有一个MongoDb,所有的图片都存放在这里面。
2.在这个MongoDb里只有两个桶：big,small分别用来存放大图和小图。
从下面几方面进行分析：
1.存放，很方便，但当图片数量和体积大到一定程度，会放不下，也很难配置集群，比如把一个桶里面的内容分配到好几个文件系统里面，这个可能做不到。
还有就是在存放的时候，因为没有根据业务进行划分，只是简单的大图小图的区分，在保存图片位置的时候，往往在mongodb生成的id中加上前缀后缀，
无法解决过虑重复图片，存在大量的图片冗余。
2.查询，很不方便，目前在mysql表里存放的就是mongodb生成的id，而没有指明是哪个库的哪个桶的图片（因为现在只有一个库两个桶，还能区分的开），这样就导致复杂的判断步骤，要通过前缀和后缀来判断，有时候只能通过表的列名来判断，这样不仅让代码晦涩难懂，开发效率低下，也不存在扩展的可能了。
我做的图片读取的接口这样定义：
/{request_context}/{mongodb_name}/{bucket_name}/{id}
request_context:请求上下文，每个请求都会有这样一个上下文信息，也可以配置解决，我用一个theadlocal解决请求上下文在请求线程上传递，（是一种松耦合的实现方式，struts2,spring mvc都在用这种方式，进行接解耦）。
mongodb_name：mongodb的名字，方便以后扩展，以后可以增加多个库我这个接口都不用改动。
bucket_name：桶的名字，可以根据不同的业务来区分这些桶，比如用户，物品，话题，官方推荐，都可以有自己的桶。也是方便以后扩展，只要知道桶的名字接口就可以到指定的桶中查找。
id：在存放图片的时候，mongodb生成的id，能过它可以定位一个图片的最终位置。
从上面的接口定义可以看出来，以后不管是如何更改mongodb或是添加新的库 桶 都不会影响到我的接口。