今天听了 lighty modcache 的讲座，晚上和 suchasplus 谈论这个讲座时，注意到以下细节，于是我开始自说自话的猜测他们的系统架构。
- modcache 本身不会自动删除磁盘缓存文件，需要 tmpwatch 程序配合或者被动 PURGE
- 缓存目标的老化只根据 refresh-pattern 决定，没有多余的信息和缓存目标保存在一起，缓存目录中的文件格式很简单
从这些细节中，我猜测该视频分享网站有个主控端，负责通过发请求或者直接推送文件到缓存目录的方法推送文件到前端缓存服务器 ，而这些傻得可爱的前端缓存不会主动删除缓存文件。这样，主控端对“某台前端服务器拥有哪些内容”了如指掌，配合性能测量机制，可以动态的向客户端发送指向不同前端服务器的播放列表，从而达到均衡各服务器、各网段负载的目的。在网络流量低潮，还可以偷偷的向前端发送热门内容文件，或者遥控前端服务器删除过期内容等。
这样看来，其实前端的服务器并不能算做传统意义上的反向代理缓存服务器，而是 web 服务器，但为什么用缓存代理的方式来实现这个功能呢？我认为主要是可以通过向缓存代理发送一个 GET 请求的方式，轻松的向该前端服务器推送内容；缓存目录中的文件没有特殊格式和多余信息，恐怕也是出于这个考虑。
声明：本文为无责任猜测。如果与实际情况相同，并不表明我窃取了该企业的机密；如果不同，则说明我已经独立发明了一种较通用的大型网站系统架构。
主控端就是CDN调度，该网站的调度据说是php写的, 谨慎猜测调度程序没你想象的那么智能.
我现在关心的是两点,1.后端存储架构，2.CDN调度的策略，阙总声称缓存命中率大于99%，能这么高命中率的除了小文件，flv的调度选择算法才是关键，要么这个缓存命中率就是到存储最顶端的命中率.要么就是绝大多数长尾视频根本没有浏览量。
哦对了，最后阙总说漏嘴了，说该网站现在每天新增5~6万个视频,容量我没听清，好像是1T? 还是几百个G
可以看看这个
http://highscalability.com/youtube-architecture
还有视频
http://video.google.com/videoplay?docid=-6304964351441328559
如果把访客引导到预先推送过的那个前端服务器上的话，命中率确实挺高的。但至于是不是能高达99%，我还没试过。