Tag Archives: LAMP

Digg 网站架构

本篇描述一下 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–

学习 Flickr 的基于 LAMP 的容量规划经验

好久没怎么正式更新 Blog 了，快荒芜了，长满了 Spam 的荒草。

最近其实发现了不少可以和大家一起学习的好内容。Flickr 的 John Allspaw 在 MySQL Conf 2007 作了一个题为 Capacity planning for LAMP (下载PDF文件) 的技术报告，说起容量规划，多少有点空对空的意思，不过这个 PPT 还是介绍了不少 Flickr 的网站运维经验。

Flickr 的数据量的确越来越惊人了，根据文档中透漏的数据：

Squid Cache 中共有 3500 万张图片；
在 Squid RAM 中有 200 万张图片；
4.7亿的图片，每张图片有4到5种尺寸；
每秒钟 38000 个到 memcached 的请求;
2 PB 裸存储容量(周日需要消耗1.5T 的空间)

三个主要步骤：

计划

基于实际业务，而不是抽象的理论。John Allspaw 认为基准测试(Benchmark) 作用并不大，这一点我也很赞同。在业务频繁变化的环境中，Benchmark 根本不能与实际业务情况匹配。

部署

Flickr 使用SystemImager/SystemConfigurator(自动化安装、软件分发)，CVSup(网络中的文件分发、更新)，Subcon(配置管理工具)提高部署效率。

度量(图形化展现)

Flickr 使用了 Ganglia 来进行容量数据的展现。Ganglia 最初设计是用于高性能集群计算的监控上面，也是以 RRDTool 为基础来进行图形展示。Ganglia 最主要的优点还是管理的方便性: Client/Server 结构, 各自跑 Demon 进行数据交互(XML形式)。相比起来， Cacti + Collectd 需要进行很多手工配置，在面对大量需要监控的主机的时候的确不那么方便。

Web 2.0 站点的运维似乎大家都在摸索着走。期望这次阿里巴巴组织的侠客行大会上也有有朋友坐下来聊聊这个话题(Flickr 的架构师本来可以来的，因为时间的问题不能成行，挺遗憾的)。

–EOF–

LAMP 与 LAOP

Oracle 这只大鲨鱼胃口越来越好了。LAMP (Linux, Apache, MySQL, PHP) 一直以来被视为一个非常完美的组合形式，现在 Oracle 或许有了想把 LAMP 中的 “M” 替换为 “O” -Oracle 的想法。LAOP, LAOP? 现在这还是我的猜测，起因是看到了这篇 Drupal + Oracle: Inside the OraDrup Project。
现在 OraDrup 项目还只是刚刚起步，Oracle XE 的确拉近了使用者与 Oracle 之间的距离，这个易于部署的版本一改 Oracle 过去”重”的形象，多少有点”轻量级”的意思，在中小应用上开始抢 MySQL 的地盘。LAOP 中的 O 有点牵强，却也是可以为之。
LAOP 中的 “P” (PHP)呢? Oracle 对 PHP 也是下了不少力气的。与 Zend 的倾力合作时间也不短了，Oracle 在 PHP 这一块的技术社区也逐渐做了起来。
至于 Linux 和 Apache ，对 Oracle 来说也是必争之地，苦心经营了多年。尤其是 Linux 服务器这一块，甚至不惜与多年的合作伙伴 Red Hat 交恶。
Oracle 会花多大力气来争夺这最关键的一环还真不好说，也或许只是一些 Oracle 技术爱好者的一厢情愿(或许更多是我的猜测:))。
再过一段时间没准 LAOP 这个缩写就流行起来喽，谁知道呢。
–EOF–

没有了MySQL，能用Linux做的事情多着呢

最近 Oracle 频繁收购开源厂商, 也有消息说 Oracle 也曾经试图收购 MySQL 未果, 一连串的事情引起了开源界的恐慌，估计也让不少开源爱好者都很闹心，今天居然在 CSDN 头条上看到了没有了MySQL，我们使Linux还能干什么这样的观点：

我宁可看到微软收购 Redhat、Mandrake等，也不愿看到 MySQL 被收购，因为在这之后将可能是 PostgreSQL 的覆灭，到了那时，我们还有什么理由继续使用 Linux 呢?

没错，这居然是 CSDN 的头条新闻. 这不知道这位开源爱好者怎么会作出这个有些可笑的结论.有必要讨论一下了。
　
被收购并不意味着会修改软件许可证方式.假定现在 MySQL 现在已经被某个大厂收购, 那么并不意味着这家收购方会冒天下大不韪，收购方可能会继续采用当前的许可模式，这样对那些期待免费使用的最终用户来说没甚么影响; 开源运动的实际推动者还是那些千千万万的软件爱好者,这一点不是以某个公司的意志能转移的。
修改软件许可方式不一定不是免费的. 我不知道那些 MySQL 的爱好者与使用者是重点关心软件价格的免费还是代码的开放, 据我的观察, 国内的 MySQL 最终用户中，直接因为某项功能而 Hack MySQL 源代码的少之又少，更多的都是直接拿来应用.　如果我的这一判断出入不大,那么 MySQL 被收购后不再开源，用户未必就一下子跑光了。
MySQL 不是唯一的开源数据库. 放眼望去,PostgreSQL、Ingres、FireBird等等优秀的开源数据库产品还有很多; 除了流行程度, 软件功能和 MySQL 相差都不大; 即使收购方扼杀了 MySQL; 广大开源用户还是有的”吃”。
MySQL 本身的血统并不那么高贵. MySQL 本来就是由商业公司在背后运作, 甚至本身的技术也多少依赖于开源软件界。如果说他被更大的商业公司收购的话，只能说他的商业运作成功，修成正果而已。咱何必奢求?
更多厂商的推出免费数据库. Oracle 推出了免费的 Express Edition DB, IBM 紧跟对手推出免费的 DB2 Express-C, Sybase、EnterpriseDB 等厂商也都有免费或开源的 DB 产品推出, 即使没有了 MySQL，我们的选择只会更多. “死了张屠户，也不用吃混毛猪”.
如果这些理由还没有解除你的顾虑, 现在我们看看数据库之外的东西。

继续阅读 →