基于ID的分片机制实现存储的分布化会遇到一个问题：固定存储空间随着时间增加再次达到系统的空间/负载的瓶颈。观察了一下Flickr的图片存储地址：好像是在定期启用新的集群，各个时期的域名分布如下：

http://farm1.static.flickr.com 2006年中以前；
http://farm2.static.flickr.com 2006年底；
http://farm3.static.flickr.com 2007年底；
http://farm4.static.flickr.com 2008年底；

《构建可扩展的Web站点》上没有提到这个策略，猜测Flickr应该是不断在启用新的服务器集群，当地一个集群用到90%的时候，开始启用下一个集群。一个用户的所有图片地址则存储在数据库中：记录会包含当时的存储所在的集群：

user_foo - farm1.static....../20060124_003.jpg
\ farm1.static....../20060324_005.jpg
\ farm1.static....../20060824_021.jpg
\ farm2.static....../20070124_006.jpg
\ farm3.static....../20080124_002.jpg
\ farm4.static....../20081124_001.jpg

图片服务的特点就是：不修改，少量新增/极少删除，存储量大，需要尽量避免迁移和复制；旧的集群锁定后：对于原来的文件基本上就只删不增了；虽然目前有很多开源的分布式文件系统，但是目前比较便宜的解决方法还是本地硬盘服务器不断一组一组的增加，相互备份的一组服务器作为基础存储，然后前端使用缓存服务器；通过LVS或者CDN进行负载/分布的均衡。

另外如果希望前端存储使用的域名一直保持不变，通过目录规则进行rewrite的方式也是可以的，比如：将要发布的内容，后端按时间建立一个域名进行存储；

200711.foo.example.com
200712.foo.example.com
200801.foo.example.com
...
200811.foo.example.com

而前端则通过前端目录规则，将请求rewrite访问后台不同的存储服务器上：

foo.example.com/200711/ >> 200711.foo.example.com
foo.example.com/200712/ >> 200712.foo.example.com
...
foo.example.com/200811/ >> 200811.foo.example.com

工作职责：
-根据豆瓣的品牌及市场策略，制定整体公关传播策略
-负责公司品牌的统一规范及管理，建立品牌管理体系
-组织及主导产品推广项目的执行，并对推广执行效果进行评估
-进行日常的媒体维护工作
-配合公司其他部门开展必要的辅助工作

职位要求：
-三年以上公关、营销、传媒或相关行业工作经验
-拥有成熟的媒体关系、良好的沟通能力
-自我管理能力强，工作态度认真、负责
-良好的文字驾驭能力，较强的数据敏感度和分析能力
-对豆瓣有一定的认知，具备团队意识和合作精神

工作地点位于北京。有兴趣或者问题请email至 team(a)douban.com。请注明“PR”。

欢迎转载。谢谢！

针对企业级环境下多个项目的管理需求，BugFree 2.03最重要的改动是增加项目管理员的功能，将项目的管理分发给项目管理员，彻底把系统管理员解放出来。

主要功能描述如下：

• 系统管理员原有功能保持不变，增加指派项目管理员的功能。
• 分组管理变更为用户组管理，将用户的管理和项目指派彻底分开。
• 项目管理员的权限
  • 和项目管理员一样，都可以编辑用户和用户组
  • 可以对所管理的项目指派用户组
  • 可以维护所管理的项目Bug模块和Case模块
• 项目管理员的限制：
  • 只能查看并修改自己管理的项目，并且不允许新增、禁用或激活项目
  • 不能删除或指派其他项目管理员
  • 不能查看用户日志
  • 在项目管理员不属于任何项目情况下，禁止登录BugFree

预计BugFree 2.03在12月中上旬推出，敬请期待。