WordPress.com 母公司 Automattic刚收购 Gravatar 没几天，工程师就对 Gravatar 进行了一番手术，把 Gravatar 并入了 WordPress.com 的技术架构.
合并后的 Gravatar 在两个不同的数据中心各有一台应用服务器 + 1 台 Cache 服务器。Cache 服务器用的软件是 Varnish ，峰值能够处理 1000个/秒 的请求，效率很惊人，据说 Varnish 跑在 FreeBSD 6 或是Linux 2.6 上充分发挥性能，实际处理能力比这个还要强。
Web 服务器分两种：普通的为 Apache2 + Mongrel, 图片服务器则是 lighttpd + mod_magnet (看来 lighttpd 是图片服务器非常流行的使用啦 )，不过他们遇到了内存泄漏问题(Bug?)，每隔一段时间要重新启动一次，对这个的控制用的是 Monit
Monit 这个小工具我是第一次知道，功能也很有趣。
小成本，高性能，这帮老外玩的就是透。国内的 Feedsky 啥的也需要加把劲儿了，最起码也要向豆瓣看齐吧?
–EOF–
Slashdot 前一段时间搞 10 周年庆典，公布了网站的架构信息(软件、硬件)情况。国内的克隆站点 Solidot 有朋友对此做了介绍。看了之后感觉剩下没有介绍的还有嚼头，也写一篇记录一下。
前面本站介绍 Digg 网站架构的时候说他们只有 100 台左右的机器，Digg 在 Alexa 上排名是 100 名左右，而 Slashdot 大约在 750 多，相比之下，服务器也少多了。Web 服务器有 16 台。操作系统都是 Red Hat 9(比较古老)。Apache 是 1.3 版本，模块包括 mod_perl 和 lingerd（用以提高内存效率). 这 16 台中有一台是面向 https 的。MaxClients 设置都很小，面向动态内容的设置 5-15 ，面向纯静态内容的只有 25。因为瓶颈不在 IO 而在 CPU 上。
Web 服务器 IO 压力不大是因为用了 Pound 作为反向代理与负载均衡服务器，Cache 了大部分 IO 。
Slashdot 比较奇怪的一个地方是 NFS 的利用方式。 Web 服务器都用同样的软件， NFS 服务器输出一个只读的 目录，每台 Web Server Mount 该目录。NFS 服务器后台有任务定期写回。这个实现方式有点意思，看起来似乎 NFS 是个单点–写单点。
数据库有 7 台 MySQL，都运行在 CentOS 4 上。CentOS 是 RedHat Enterprise Server 的克隆版。一直以为是不登大雅之堂的。Slashdot 这次也披露了不少数据层的使用经验，感兴趣的朋友可以点击开头的链接仔细看看。
总的来说，Slashdot 毕竟算是个老网站了，和 Digg 这样的新贵来说，在架构上相对比较保守，但仍有许多东西值得借鉴。
–EOF–
我在 DBAnotes.net 上记录过不少比较大的网站架构分析(eg: eBay [1], eBay [2]) ，Amazon 一直找不到太多的资料。国庆期间读到了一篇关于 Amazon Dynamo 的论文，非常精彩。Amazon Dynamo 这个高可用、可扩展存储体系支撑了Amazon 不少核心服务.
先看一个示意图:
从上图可以看出，Amazon 的架构是完全的分布式，去中心化。存储层也做到了分布式。
Dynamo 的可扩展性和可用性采用的都比较成熟的技术，数据分区并用改进的一致性哈希(consistent hashing)方式进行复制，利用数据对象的版本化实现一致性。复制时因为更新产生的一致性问题的维护采取类似 quorum 的机制以及去中心化的复制同步协议。 Dynamo 是完全去中心化的系统，人工管理工作很小。
强调一下 Dynamo 的”额外”特点：
1) 总是可写
2) 可以根据应用类型优化
Key: Key 唯一代表一个数据对象，对该数据对象的读写操通过 Key 来完成.
节点(node)：通常是一台自带硬盘的主机。每个节点有三个 Java 写的组件：请求协调器(request coordination)、成员与失败检测、本地持久引擎(local persistence engine)
实例(instance)；每个实例由一组节点组成，从应用的角度看，实例提供 IO 能力。一个实例上的节点可能位于不同的数据中心内, 这样一个数据中心出问题也不会导致数据丢失。
上面提到的本地持久引擎支持不同的存储引擎。Dynamo 上最主要的引擎是 Berkeley Database Transactional Data Store(存储处理数百K的对象更为适合），其他还有 BDB Java Edition、MySQL 以及 一致性内存 Cache 等等。
第一个关键参数是 N，这个 N 指的是数据对象将被复制到 N 台主机上，N 在 Dynamo 实例级别配置，协调器将负责把数据复制到 N-1 个节点上。N 的典型值设置为 3.
复制中的一致性，采用类似于 Quorum 系统的一致性协议实现。这个协议有两个关键值：R 与 W。R 代表一次成功的读取操作中最小参与节点数量，W 代表一次成功的写操作中最小参与节点数量。R + W>N ，则会产生类似 quorum 的效果。该模型中的读(写)延迟由最慢的 R(W)复制决定，为得到比较小的延迟，R 和 W 有的时候的和又设置比 N 小。
(N,R,W) 的值典型设置为 (3, 2 ,2),兼顾性能与可用性。R 和 W 直接影响性能、扩展性、一致性，如果 W 设置 为 1，则一个实例中只要有一个节点可用，也不会影响写操作，如果 R 设置为 1 ，只要有一个节点可用，也不会影响读请求，R 和 W 值过小则影响一致性，过大也不好，这两个值要平衡。对于这套系统的典型的 SLA 要求 99.9% 的读写操作在 300ms 内完成。
–待续–
更多阅读：Dynamo学习 — http://donghao.org/2008/10/dynamoni.html
本篇描述一下 Digg 的网站架构.
国庆期间又收集了一些关于网站架构的信息。一直没有进行系统的整理。越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。--by Fenng
Digg 工程师采用 LAMP (Linux, Apache, MySQL and PHP) 模式。这个 Alexa 排名在 100 左右的、自我估价 1.5 亿美金的站点目前有超过 100 台的 PC 服务器(足够少了)，可以粗略分成三个部分：数据库服务器，Web 服务器，搜索服务器。
数据库方面，和其他成功的 Web 2.0 站点一样，也是 MySQL，不过 Digg 稍微”激进”一点，用 MySQL 5，而且号称从 MySQL 4 升级到 5 性能没有什么影响。 OLTP 应用用 InnoDB 引擎, OLAP 用 MyISAM。后端数据库的读比例达到 98%，写只有 2%，实际的读写比例应该高于这个数字，这应该是 Digg 在前端用 Memcached 以及 APC PHP accelerator / MCache 做缓存后的效果。在 IO 上似乎压力并不大。
数据库分割用 Sharding (分片)的机制。从透露出来的信息看，Digg 数据量并不大，仅仅刚超 30g . 看起来是只存储了一些元数据。至于这个 Sharding 或者 Shard, 其出发点有些类似于数据库的分区，差别可能就是不再一个库上吧，其实都是结合业务和应用来对一些数据对象进行分割。
搜索服务器用的是 Lucene。
进一步阅读：
–EOF–