听说 FaceBook 开放其网站的代码了，期前也算是了解过 FaceBook 的架构，所以重点就是看其代码的质量。

可以毫不夸张的说，FaceBook 的代码质量、风格都不亚于某个开放源代码的项目（当然，并不是每个开源的项目代码都很友好）。我可以用“教科书式”的代码，来形容我眼前所看到的 FaceBook 的源代码。

有点离题了，开发语言（或者工具）的本身，并不能说明系统会有多么的优秀。目前的网络上所能找到的、开源的工具，只要稍加都能很好的提升性能。

锦上添花的就是加上良好的 Cache（缓存）机制。在“上古时代”，人们对于性能上的考虑，还处在程序也算法的优化上。随着 Web2.0 的到来（什么是 Web2.0？）、Ajax 这样的技术的出现，造成服务器处理的请求比平时多得多，此时就需要从宏观上改进整个系统的机制。

很快就出现了大量的相应工具，首先是 Squid、然后是 Memcached，最后是具体到某个语言（比如 PHP）的扩展。正如期前所说的，Ajax 等前端技术的流行，Cache 技术逐渐从“后台”的点心，转成了“正餐”。

重新回到上述的 FaceBook 中，从上往下看（似乎这图不是完整的逻辑，搞不清楚为什么 Database 会在这个位置），所涉及到的 Cache 技术就有 APC、Memcached、CDN 以及 浏览器的缓存。基于这点就能够充分的表明，FaceBook 能够应对如此高的负载的因素之一就是合理的使用 Cache 机制。

Cache 的确是个好东西，但是有时候也带来了不少的麻烦。比如在前端开发过程中，往往就会碰到用户反应样式、脚本无法执行的情况，此时本人就会很机械的告诉他 Ctrl + F5 刷新。

坦白的说，本人认为使用 Cache 在项目中，不应该过分的乐观。Cache 所带来的用户重复刷新（虽然在良好的 Cache 机制下这种情况很少），空间上的逐渐增大（真的是用空间换取时间，想想 FaceBook TB 级别的 Cache 容量吧），这是使用 Cache 所带来的负面效果（但这往往有些技术人员会将此拿来当作炫耀的资本）。

不要将 Cache 作为提升性能的救命稻草。前段时间 Twitter 间歇性的罢工，虽然找到瓶颈是数据库。但本人同时也听到某些观点，诸如“如果 Twitter 有良好的 Cache 机制也许就不会这样”，在这里本人保留意见。

请容我胆大的猜想，也许 Cache 会和 Ajax 一样，最终有一天会消失。技术这玩意也就是这样，没有更好的只有最合适的。退一步讲真的到了那一天，Cache 的替代方案也会造成另外的问题也说不准 -- 以后的事情谁知道呢？

想起了一句话，就是

“计算机原先是为了解决麻烦才搞出来的，但是后来它本身就成了麻烦”。

Gracecode.com | Permalink(xHTML) | Trackback | Rss