无责任猜测某视频分享网站的系统架构

今天听了 lighty modcache 的讲座，晚上和 suchasplus 谈论这个讲座时，注意到以下细节，于是我开始自说自话的猜测他们的系统架构。

1. modcache 本身不会自动删除磁盘缓存文件，需要 tmpwatch 程序配合或者被动 PURGE
2. 缓存目标的老化只根据 refresh-pattern 决定，没有多余的信息和缓存目标保存在一起，缓存目录中的文件格式很简单

从这些细节中，我猜测该视频分享网站有个主控端，负责通过发请求或者直接推送文件到缓存目录的方法推送文件到前端缓存服务器 ，而这些傻得可爱的前端缓存不会主动删除缓存文件。这样，主控端对“某台前端服务器拥有哪些内容”了如指掌，配合性能测量机制，可以动态的向客户端发送指向不同前端服务器的播放列表，从而达到均衡各服务器、各网段负载的目的。在网络流量低潮，还可以偷偷的向前端发送热门内容文件，或者遥控前端服务器删除过期内容等。

这样看来，其实前端的服务器并不能算做传统意义上的反向代理缓存服务器，而是 web 服务器，但为什么用缓存代理的方式来实现这个功能呢？我认为主要是可以通过向缓存代理发送一个 GET 请求的方式，轻松的向该前端服务器推送内容；缓存目录中的文件没有特殊格式和多余信息，恐怕也是出于这个考虑。

声明：本文为无责任猜测。如果与实际情况相同，并不表明我窃取了该企业的机密；如果不同，则说明我已经独立发明了一种较通用的大型网站系统架构。