中国IDC质量问题与Yo2的解决方案
刚在 Yo2Mass 看到《从豆瓣宕机看IDC单点问题》 一文，自己是深有感触的。刚好今天我们电信的服务器也出了故障，断网4个多小时。从Yo2开张到现在，我们都不知道换多少个IDC。就是没能找到一个很稳定的（当然太贵的我们是租不起）。
豆瓣所在的机房是北京实力比较厚的IDC之一，我们也有台服务器在他们的天津机房。一直用着，感觉还可以。虽然偶尔会出现某些地区访问速度慢的问题，但因它在教育网的访问速度挺好的，所以一直在用。万没想到，我一直说算稳定的IDC也会出现如此长时间的断网故障《2008.10.31 豆瓣访问故障》。刚查了下豆瓣的服务器信息，发现他们已经把服务器出口切换到其他机房。他们的数据估计都在原来的机房，新的出口应该是直接 Proxy 代理，访问速度并不理想。
做网站的技术都知道什么是单点故障和它所造成的影响。传统的解决方案是使用LVS把访问请求分发到多个服务器，如果某台服务器故障，它可自动分发到另外的服务器，能很好的解决单点故障问题。但你再看远一点，在前端的LVS不是一个非常大的单点吗？万一它出现故障，那么它后面的N台服务器都无用武之地！大家都在努力解决单点故障的问题，却未意识到自己在制造一个更大的单点故障风险。
Yo2也有单点故障的情况发生，但它的影响不至于扩散到全局，因为我们使用了CDN技术。我们目前在几个网络、分几个机房，架设了访问加速节点。CDN利用域名智能解析技术把用户的访问指向到不同的服务器，部分用户间是相对独立的，如网通用户与电信用户，甚至可以精确到某个省份和地区。比如今天电信服务器出现故障，就不会影响到网通和教育网用户的访问，并且我们及时在CDN上把电信的访问切换到其他的机房，能快速恢复服务（当然域名解析耗时比较长，大概1个小时左右）
但CDN也不是灵丹妙药，不是什么网站应用都能使用CDN。比如一些动态页面就无法使用CDN系统的缓存功能，只能直接Proxy。如果网站应用是以动态内容为主，那么建立CDN系统也就等于把成本扩大1倍。因为它只能直接Proxy到后台服务器，CDN跑多高的带宽，后台的服务器都会跑这么高；后台服务器需要处理的数据量跟没使用CDN是一样的，并不会减少。除非把内容缓存在CDN的加速节点上，这样不仅能节约服务器的成本，并且访问速度会快很多。但目前商业运营的服务商，还未能提供这个完美的解决方案。
Yo2是在成长过程中就意识到单点故障问题的严重性，我们必须把影响降低到最低。因没找到能提供解决方案的服务商和需要考虑运营成本，所以我们选择了自主根据Yo2作针对性的开发。目前我们是拥有一个算完美的解决方案。当然目前的加速节点还很少，单点故障的影响还是比较大。只是从以前的影响100%降低到40%左右，随着Yo2的成长，我们会继续增加更多的访问节点，单点故障的影响将会降到更低 
快速链接:http://oneoo.com/go/635004.html
十一月 1st, 2008 at 3:16 上午
每次都能在YO2老大这学习东西。
虽然有点软，基本还是硬的
十一月 1st, 2008 at 3:04 下午
顺带再次介绍CDN技术
十一月 1st, 2008 at 7:32 下午
我推荐一家，为避免广告嫌疑，我给你QQ留言了。另外你文章的模板在IE下面文章栏有点显示不出来，一列字。
十一月 1st, 2008 at 11:54 下午
不错不错，学习了，祝yo2越办越好，越走越远！
十一月 2nd, 2008 at 11:01 上午
很赞了。。
对了。我写了一篇关于yo2的新日志。。请你这位yo2的老大去看看。。
虽然说话随便点。。但我不好用什么正式点的方式哦。呵呵~~~
十一月 5th, 2008 at 11:48 上午
十一月 16th, 2008 at 5:04 下午
您好 请问下文章后面“收藏到网摘”这个功能怎么弄 需要什么插件支持？yo2目前有这个插件么？
十一月 17th, 2008 at 11:58 下午
@konoko 在后台-设置-输出，页面上可以选择是否显示网摘按钮
十一月 25th, 2008 at 10:24 上午
[...] 图片服务的特点就是：不修改，少量新增/极少删除，存储量大，需要尽量避免迁移和复制；旧的集群锁定后：对于原来的文件基本上就只删不增了；虽然目前有很 多开源的分布式文件系统，但是目前比较便宜的解决方法还是本地硬盘服务器不断一组一组的增加，相互备份的一组服务器作为基础存储，然后前端使用缓存服务 器；通过LVS或者CDN进行负载/分布的均衡。另外如果希望前端存储使用的域名一直保持不变，通过目录规则进行rewrite的方式也是可以的，比如：将要发布的内容，后端按时间建立一个域名进行存储； 200711.foo.example.com 200712.foo.example.com 200801.foo.example.com … 200811.foo.example.com [...]
二月 8th, 2009 at 1:10 上午
[...] 图片服务的特点就是：不修改，少量新增/极少删除，存储量大，需要尽量避免迁移和复制；旧的集群锁定后：对于原来的文件基本上就只删不增了；虽然目前有很多开源的分布式文件系统，但是目前比较便宜的解决方法还是本地硬盘服务器不断一组一组的增加，相互备份的一组服务器作为基础存储，然后前端使用缓存服务器；通过LVS或者CDN进行负载/分布的均衡。 [...]
三月 7th, 2009 at 12:32 上午
[...] 基于ID的分片机制实现存储的分布化会遇到一个问题：固定存储空间随着时间增加再次达到系统的空间/负载的瓶颈。观察了一下Flickr的图片存储地址：好像是在定期启用新的集群，各个时期的域名分布如下： <blockquote>http://farm1.static.flickr.com 2006年中以前； http://farm2.static.flickr.com 2006年底； http://farm3.static.flickr.com 2007年底； http://farm4.static.flickr.com 2008年底；</blockquote> <a onclick=”javascript:pageTracker._trackPageview (’/outbound/www.chedong.com’
;” href=”http://www.chedong.com/blog/archives/001422.html“>《构建可扩展的Web站点》</a>上没有提到这个策略，猜测Flickr应该是不断在启用新的服务器集群，当地一个集群用到90%的时候，开始启用下一个集群。一个用户的所有图片地址则存储在数据库中：记录会包含当时的存储所在的集群： <blockquote>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</blockquote> 图片服务的特点就是：不修改，少量新增/极少删除，存储量大，需要尽量避免迁移和复制；旧的集群锁定后：对于原来的文件基本上就只删不增了；虽然目 前有很 多开源的分布式文件系统，但是目前比较便宜的解决方法还是本地硬盘服务器不断一组一组的增加，相互备份的一组服务器作为基础存储，然后前端使用缓存服务 器；<a onclick=”javascript:pageTracker._trackPageview (’/outbound/oneoo.com’ 
;” href=”http://oneoo.com/articles/idc-china-yo2-quality-problems-and-solutions.html“>通过LVS或者CDN进行负载/分布的均衡</a>。另外如果希望前端存储使用的域名一直保持不变，通过目录规则进行rewrite的方式也是可以的，比如：将要发布的内容，后端按时间建立一个域名进行存储； <blockquote>200711.foo.example.com 200712.foo.example.com 200801.foo.example.com … 200811.foo.example.com</blockquote> 而前端则通过前端目录规则，将请求rewrite访问后台不同的存储服务器上： <blockquote>foo.example.com/200711/ >> 200711.foo.example.com foo.example.com/200712/ >> 200712.foo.example.com … foo.example.com/200811/ >> 200811.foo.example.com</blockquote> </div> <div id=”more” class=”entry-more”> [...]
五月 21st, 2009 at 10:26 上午
希望yo2越来越好