前言：

关于Digg的架构，之前Fenng已经写过一篇Digg 网站架构的文章，Fenng在文章开头说“越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。”，其实是Fenng过谦了，我就是从DBA notes一点一滴开始学习的。

原文在Scaling Digg and Other Web Applications，Todd Hoff总能给我们带来一些有意思的文章。这里既不直译也不全译，保持原文骨干加上肤浅的理解。

Digg用户在3000W左右，网站每秒请求数达到13000个，规模算是很大了，Lamp（Linux+Apache+MySQL+PHP）结构，Web2.0网站中钟情PHP的不少，国外的Facebook、Digg、Flickr…，国内的新浪博客、开心网、51.com等等，扩展的不是编程语言而是网站架构，因为编程语言从来都不会是网站瓶颈，每种语言都有自己适合做和不适合做的事情。喜欢比较语言快慢的可以看看http://shootout.alioth.debian.org/，看看而已不要用速度去衡量编程语言的优劣。

Digg的扩展战略：

• 扩展是有特殊性的，当已有的方案不能满足需求时，你需要根据自己的特殊需求来建立方案。要熟悉自己的业务需求，找出系统的短板，解决问题，避免过度优化。
• 编程语言不需要扩展，因为语言从来都不是瓶颈，把PHP提速300％不会是什么大问题。
• 去中心化，分布式处理高并发请求。
• 水平扩展，用更多更便宜的机器代替更高效更昂贵的机器。
• 数据库驱动的网站需要作水平分区和垂直分区扩展，水平分区就是把数据放到不同的机器上，比如按照时间划分：2009年的数据一组服务器，2009年的数据一组服务器，或者按照用户ID划分：每200W用户一组服务器；垂直分区把一个表分成多个表，每个表只包含一部分字段，可以按照业务分或者常用的“动静分离”，比如对文章计数的字段大可以和文章内容字段分开。
• 建立数据应用层，程序不要直接操作数据库分区，这样可以保持好的扩展性。这一点非常重要，如果没有数据应用层API，一旦对数据库分区做了修改，你的程序就需要大改了。程序的稳定性和持续性就不能保证。比较常见的MVC开发模式，数据层和逻辑层分开，一旦数据库底层改变了，只需要对数据层做简单的修改，不影响既有业务。
• 一致性、高可用性、分区容忍性（Partition Tolerance）三者只能取其二，具体的阅读http://camelcase.blogspot.com/2007/08/cap-theorem.html，一致性：每个人看到的都一样，哪怕当时就有更新；高可用性：部分故障不影响使用；分区容忍性：数据分区还能保持系统所有属性。
• 数据分区要求反常规化，这是在Digg是大问题，同样的数据要复制到多个对象上去，而且还好保持同步。
• 采用异步的队列架构，把任务放到队列中交由多台机器处理，而不是一次同步处理，关于异步任务处理可以阅读 Flickr – Do the Essential Work Up-front and Queue the Rest和The Canonical Cloud Architecture
• icons和图片采用MogileFS存储，MogileFS是一个分布式的文件系统，由memcached作者开发，国内的好看簿也有使用MogileFS。
• 采用APC作为PHP加速器，Facebook用的也是这个，PHP5.30以后将自带APC加速器，同样的产品还有eAccelerator和Xcache，国内可能用eAccelerator的比较多，windows的版本我一般用这个网站编译的
• 缓存策略：永久性缓存和失效期缓存；基本不更新的内容采用文件缓存；动态缓存采用memcached；极少修改的数据采用APC缓存，APC不是分布式缓存，直接缓存的机器内存中，所以速度更快，适合缓存那些配置文件，比如MySQL的配置信息；缓存采用链责任模式，首先看PHP全局变量，如果没有就查APC，再没有就查memcached，最后没有就查数据库，这个觉得不太必要，你的缓存存在哪来你自己还不清楚阿。
• Digg的推荐引擎是一个自定义的图形数据库，数据库最终保证一致性，先写如一个分区，然后再逐步写到其他的分区。在更新的过程中，可能取出来的数据不一致，是因为有不同的数据库分区处理，最终将会是一致。

MemcacheDB：性能革命性的一步

想象一下Kevin Rose，Digg的创建者，当前有4000个追随者，如果Kevin Rose一天digg一次，将会有4000个写操作，最热门的digg有最多的追随者，这会导致巨大的性能瓶颈：

• 你不能同时更新4000个追随者的帐号信息，幸运的是我们可以通过前面提到的异步队列方式解决。
• Digg面临的海量写操作，如果平均每个人有100个追随者，一天就有3亿条写操作，平均到每秒有3000个写操作，每天有5GB的数据存储，在50～60台服务器之间有5TB的数据交换。

如果是MySQL的话估计早就挂了，Digg在笔记本上的测试是memcachedb每秒可以处理15000个写操作，memcachedb的测试结果表明每秒可以支持23000个写操作或者64000个读操作，足以应付Digg洪水般的请求。

memcachedb是一个分布式的kye-value型数据持久化解决方案，提供兼容memcached协议接口，由Sina工程师Steve Chu开发。

提到Digg为什么采用memcachedb，Digg的工程师给出的理由是：需要持久化缓存数据，与memcached协议兼容，Digg已经有很多业务应用了memcached，可以很方便的切换到memcachedb上去，开源。

后记：

很高兴的看到除了Sina，memcachedb又有一个超重量级的应用了，性能和可靠性都得到了极大的检验，大可放心应用生产环境中。我还说今年有空写个玩具版的类memcachedb项目，还是不要了，有时间还是去做些更有意义的事情，无谓重复发明。