Pinboard 的 PHP/MySQL 架构

Pinboard 是一个提供在线书签服务的网站,和 Delicious 类似,不同的是 Pinboard 不是免费的,而且是从一开始就收费——采用有趣的渐进式收费,也就是说每增加一个人、后来的人就需多付0.001美元(按照 number of users * 0.001 的公式),这样的收费方式利用了人们的 “趁便宜赶快买,明天会更贵” 的心理,提供了一套独特的收费模式。让 VPSee 惊讶的是他们背后的技术出奇的简单,没有 Fotolog 那种 MySQL 集群+Memcached 集群,也没有 Netlog 那么复杂的数据库切分。在他们的 About 页面上,这位来自罗马利亚的创始人说:

Pinboard is written in PHP and Perl. The site uses MySQL for data storage, Sphinx for search, and Amazon S3 to store backups. There is absolutely nothing interesting about the Pinboard architecture or implementation; I consider that a feature!

数据

1亿6千多万个书签
5200多万个标签
9400多万个 urls
989 GB 的数据

平台

MySQL
PHP
Perl
Ubuntu
APC
Sphinx
Cron jobs
Amazon S3

硬件

服务器 1:64 GB, 主数据库(master),用来存储用户数据和搜索;
服务器 2:32 GB, 备用主数据库(failover master),用来爬 feeds 等一些后台任务
服务器 3:16 GB, web 服务器和从数据库(slave)
另外提一下,他们租用的这三台服务器有两台是从 DigitalOne 租用的,还有一台是从 ServerBeach 租的。

pingboard arch

架构

  • 他们运行的是 Ubuntu 操作系统;
  • 每台服务器上(一共3台)均保留一份整体数据库的拷贝;
  • 网站运行在 16GB 的服务器上,数据库完全放在内存里,页面装载时间提高了10倍;
  • 采用 master-master 数据库架构加上一个只读的 slave,所有写操作都在一个数据库上进行,第二个 master 数据库服务器主要用来计算,比如统计全局链接数,用户统计等;每天晚上数据库用 mysqldump 备份,然后备份的数据以压缩的形式储存在 Amazon S3 上。
  • Perl 脚本用来运行后台任务,比如下载 feeds、缓存页面、处理 email、生成 tag 云标签、备份数据等。他们选择 Perl 的理由是因为自己很熟悉而且有大量的库可以使用。像 “最受欢迎的书签” 这样的功能一般都是在晚上里通过后台的定时任务(cron job)完成。PHP 用来生成 HTML 页面,没有使用任何 templating engine,也没有使用任何框架(framework)。APC 用来做 PHP 缓存,没有用其他缓存技术,Sphinx 用来做搜索引擎。

经验

  • 使用成熟、老掉牙的技术,这样保证网站和程序运行快而且不会因为软件 bug 丢失数据。(VPSee 非常赞同这点,使用简单和可以理解的技术,我们相信技术是拿来用的,不是拿来炫的。)
  • 保持小规模会有趣得多,当你自己亲自提供客服支持和与客户打交道的时候你会发现很有价值;
  • 服务器成本用每 GB 内存(或存储)的价格来衡量,Pinboard 最初使用的是 Linode 和 Slicehost 的 VPS,后来发现 VPS 不够用,随着内存增大 VPS 越来越贵,价格不如独立服务器。(按照 VPSee 的个人经验,低端(<= 4GB)用 VPS 划算、高端(>=16GB)用独立服务器划算。)
  • 按照服务划分服务器,比如 web 服务器就拿来做 web 服务器,最好不要拿来干别的。

SunRay/Sun VDI 和 JavaOne

在今年的 JavaOne 大会上,Sun 为7000多个参会者部署了 SunRay 瘦客户端,每个参会者可以通过150台 SunRay 登录 OpenSolaris 2009.06/Ubuntu 8.10/Windows 7 RC 三种不同的操作系统,Sun 通过 Sun VDI 和 VirtualBox 为用户提供了约21000个虚拟桌面。参会者在注册的时候会领到一张 Smart Card,通过这张卡可以在任意一台 SunRay 上登录自己的桌面系统。

sunray users

VDI 架构

这次 JavaOne 提供了150个 SunRay,设计目标是让400-500个桌面同时运行。大会使用了以下一些服务器和架构:

  • 4台 VDI 服务器,每台配置为 Sun Fire X4450/4 CPUs/64GB RAM;
  • 5台 VirtualBox 服务器,每台配置为 Sun Fire X4450/4 CPUs/6 cores per CPU/64 GB RAM,每台服务器可以应付100个虚拟桌面;
  • 3台存储服务器,每台配置为 Sun Storage 7210 Unified Storage System/2 Opteron CPUs/4 cores per CPU/64GB RAM/48X250GB 3.5 SATA HDD,每台服务器其实可以应付1000个虚拟桌面,但是考虑到很多参会用户来了就启动一个虚拟操作系统查查 Email,然后就关闭虚拟系统走人,这种频繁启动/关闭系统的行为会造成大量 IO,所以用了3台存储服务器来分担负载。

sun vdi architecture

只有2个管理员

21000个虚拟桌面系统 + 12台服务器 + 150台 SunRay,只有2个系统管理员!VPSee 深有体会,现在我们部署了60台 SunRay + 2台服务器后实际只有0.1个系统管理员在管理(相当于一个星期只用半天),比起 PC + Windows 的方案要省钱省力绿色得多。

only 2 system administrators

GitHub 的 Rails/Git 架构

GitHub 上个月宣布把所有服务器转移到 Rackspace,他们原先在 Engine Yard 使用的是云计算和虚拟机 10 VMs/39 VCPUs/54GB RAM,移到 Rackspace 后使用的物理服务器配置为 16 Servers/128 Cores/288GB RAM. GitHub 在最近的一篇博客:How We Made GitHub Fast 中分享了他们的架构和经验。

Load Balancer

GitHub 使用了一对 Xen 虚拟机(lb1a 和 lb1b)做 load balancer,运行的是 ldirectord.

前端服务器

Load balancer 把请求发给4台前端服务器中的1台,每台服务器配置为 8 cores/16GB RAM,运行 Nginx,前端(frontend)服务器分别命名 fe1, …, fe4. 在 Nginx 接受到连接请求后转发给 Unix domain socket,并由 16个 Unicorn worker 进程进行处理,其中的某个 worker 会取得请求后开始运行 rails 代码。每个前端服务器还运行4个 ProxyMachine instances,由 HAProxy 来路由。

数据库服务器

MySQL 数据库运行在2台 8 cores/32GB RAM/15000 RPM SAS drivers 的服务器上,命名为 db1a 和 db1b. 其中一台做 Master,另一台做 slave,MySQL 由 DRBD 来做 replication. GitHub 还在数据库服务器上运行 Redis 来保存一些信息。

文件服务器

目前有4对文件服务器,每台配置为 8 core/16GB RAM /6× 300GB 15000 RPM SAS drives/RAID 10,命名为 fs1a, fs1b, …, fs4a, fs4b. 任何时候每对服务器里面都有一台是 active 的,另一台在一旁等候,随时准备接手。每对服务器的数据同步也是通过 DRBD 来实现的。每个文件服务器还运行2个 Ernie RPC 服务,由 HAProxy 来路由,每个 Ernie 运行 15个 ruby works 来响应 RPC 调用。

Memcache 服务器

上面每对文件服务器里面都有1个 master (active) 和1个 slave,多数时候 slave 都很空闲,所以 GitHub 巧妙的利用了这些空闲资源,在每台 slave 文件服务器上拿出 12GB RAM 做分布式 memcache 服务器,服务器别名为 memcache1, …, memcache4.

Google 数据中心和服务器的一些信息

Google 工程师 Jeff Dean 在刚过去的 LADIS 2009 Workshop 上做了一个 keynote talk:Designs, Lessons and Advice from Building Large Distributed Systems,并且透露了 Google 正在进行一个叫做 “Spanner” 的计划,设计目标是能扩展到1000万台服务器。Google 按照 Servers -> Racks -> Clusters -> Data centers 这样的顺序把服务器从机柜扩展到多个数据中心。VPSee 最近在部署 SunRay 和虚拟化,需要采购更多的服务器,基本选定就 SUN 了,因为有买一台送一台的优惠,剩下的问题就是每台服务器配置多大的处理器、内存和硬盘能充分发挥服务器的能力,达到最佳性价比,这篇 pdf 提到了每台 Google 服务器的配置,CNET 的这篇报道还提供了 Google 服务器的照片。

Google 服务器:

The Google server was 3.5 inches thick–2U, or 2 rack units, in data center parlance. It had two processors, two hard drives, and eight memory slots mounted on a motherboard built by Gigabyte. Google uses x86 processors from both AMD and Intel.

google server

有意思的是 Google 服务器用到了电池,原因是比 UPS 要便宜的多:

“This is much cheaper than huge centralized UPS,” he said. “Therefore no wasted capacity.”

google server

Server: DRAM: 16GB, 100ns, 20GB/s, Disk: 2TB, 10ms, 200MB/s
Rack (80 servers): DRAM: 1TB, 300us, 100MB/s, Disk: 160TB, 11ms, 100MB/s
Clusters (30+ racks): DRAM: 30TB, 500us, 10MB/s, Disk: 4.80PB, 12ms, 10MB/s

一些经验和数据:

1-5% of your disk drives will die
Servers will crash at least twice (2-4% failure rate)

一些每个人都应该知道的数据:

L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns
Mutex lock/unlock 25 ns
Main memory reference 100 ns
Compress 1K bytes with Zippy 3,000 ns
Send 2K bytes over 1 Gbps network 20,000 ns
Read 1 MB sequentially from memory 250,000 ns
Round trip within same datacenter 500,000 ns
Disk seek 10,000,000 ns
Read 1 MB sequentially from disk 20,000,000 ns
Send packet CA->Netherlands->CA 150,000,000 ns

一个新 cluster 通常第一年会发生的事情:

~0.5 overheating (power down most machines in <5 mins, ~1-2 days to recover) ~1 PDU failure (~500-1000 machines suddenly disappear, ~6 hours to come back) ~1 rack-move (plenty of warning, ~500-1000 machines powered down, ~6 hours) ~1 network rewiring (rolling ~5% of machines down over 2-day span) ~20 rack failures (40-80 machines instantly disappear, 1-6 hours to get back) ~5 racks go wonky (40-80 machines see 50% packetloss) ~8 network maintenances (4 might cause ~30-minute random connectivity losses) ~12 router reloads (takes out DNS and external vips for a couple minutes) ~3 router failures (have to immediately pull traffic for an hour) ~dozens of minor 30-second blips for dns ~1000 individual machine failures ~thousands of hard drive failures slow disks, bad memory, misconfigured machines, flaky machines, etc.

Craigslist 的 LAMP 架构

关于 Craigslist 的介绍以及一些访问量多大、负载多强大的数据就省略了,VPSee 关心的是背后的技术架构,主要参考文章:MySQL and Sphinx at CraigslistDatabase War Stories #5: craigslist.

架构

硬件环境: Supermicro 4U 7043-P8、Dual Intel Xeon 3.2 512KB CPU、16GB 内存、16个硬盘组成的 Raid 10;
软件系统: Suse Linux 操作系统,网站大部分用 Perl 编写,使用标准的 LAMP 组合,memcached 做缓存,使用 Sphinx 全文搜索。

craigslist internals overview

数据库

所有数据库服务器都运行 64 位的 Linux,每个服务器有 16GB 内存和16个硬盘。几台数据库服务器组成一个 db cluster,每个 db cluster 运行一个 Craigslist 服务。

forums:1个 master + 1个 slave,slave 主要用来备份,表使用 myIsam 引擎,DataDir 大小达到 17GB(包括索引在内),最大一个表有近4200万行。

classifeds:1个 master + 12个 slaves,多种不同用途的 slaves,其中 teamreader, longreader, thrashbox 用来备份以及一些非常耗时的特殊查询。还有1个离线 slave 以应付突发情况,比如 colo 崩溃了。其中数据库容积达到 114G(包括索引),最大一个表达到5600万条记录,数据表也是使用 myIsam 引擎。

archivedb:1个 master + 1个 slave,用来归档那些时间超过3个月的帖子,除了比上面的 classifeds 存的数据量大以外,其结构非常类似 classifeds,238G 的数据,9600万条记录。不同的是数据表使用的是 mrg_mylsam,MySQL 的 merge 引擎,方便把 archive 上分散的数据 merge 成更容易管理的块。这也是 merge 表的好处,这里一张表,那里一张表不方便管理,合成一张表更容易管理一些,不过 merge 引擎要求相似的表才能 merge,不是随便什么表都可以 merge 的。

searchdbs:4个 clusters(16台服务器),把 live 的帖子按照 area/category 切分,每个 cluster 只包含 一部分的 live 帖子,使用 myIsam 全文索引。不过要注意的是,全文索引(Indexing)很耗资源,很烧钱。

authdb:1个 master + 1个 slave,这个最小了,只是存一些临时、短暂的数据(transient data)。

MySQL 似乎在 64 位的机器上运行得更好一些。

全文搜索

Craigslist 刚开始使用了 MySQL 全文搜索(Full text indexing and searching),随着规模变大,MySQL 全文搜索逐渐不能应付要求,不能 scale,改用 Sphinx 做搜索,一段时间后发现 Sphinx 也不能满足需求,不能 scale,最后不得不 patch sphinx 以满足日益增长的庞大数据库和搜索需求。Craigslist 的经验是,在一张很大的表上做全文索引和搜索是行不通的,因为用户没有耐心去等待漫长的搜索过程,搜索结果往往不能在用户期望的时间内返回。

Ravelry 的 Rails 架构

看多了超大规模高性能、超大数据库架构,有必要回到现实看看中等规模网站是如何架构的,毕竟不是每个网站、web app 都有机会做成 Google/Yahoo/Facebook/Amazon 那样。Ravelry 是一家用 Ruby on Rails 搭建的社区网站,学习一下 Ravelry 的 Rails 架构经验。

数据

数据和资料来源(2009):Ravelry

43万注册用户
每个月约20万用户上线,每天约7万用户登录
每天约360万 PV(只包括注册用户,不包括其他途径访问),实际 PV 大概1000万每天
每天约900新用户注册
论坛每天发布约5万个新帖
网站有230万个项目、190万个帖子、130万条消息、800万张图片(大部分保存在 Flickr)
包括创始人在内公司一共才3.5个人(其中一个是 part time)

技术架构

Ravelry 使用了以下一些 Open Source 项目和技术:

Gentoo Linux
MySQL
Ruby Enterprise Edition
Memcached
Nginx/HAProxy/Apache + mod_passenger
Tokyo Cabinet/Tyrant
Sphinx
Xen
Munin/Nagios/Syslog-ng
Amazon S3/Cloudfront

Ravelry 刚开始运行在一个 VPS 上,随着网站规模的变大逐渐转向自己的硬件,服务器是从 Silicon Mechanics 购买的,托管在 Hosted Solutions 和 Cogent。Ravelry 使用 Amazon S3 做存储,Amazon CloudFront 做 CDN。

Ravelry 目前总共有7台物理服务器,Xen 虚拟化后成13台,使用 Gentoo Linux 操作系统。其中:

  • 1台用来备份,1台用来测试;
  • 1台用来做 master 数据库服务器,1台做 slave 数据库服务器 + Sphinx 搜索引擎;
  • 另外3台用来做应用服务器,运行 Passenger,Ruby Enterprise Edition 和 Memcached。使用 Passenger 和 Ruby GC patches 节省了大量内存。

前端服务的架构大概像这样:nginx -> haproxy -> apache + mod_passenger,Ravelry 的创始人 Casey 提到他们主要的 scaling/tuning/performance 方面的工作还是集中在数据库部分。

Ravelry 使用 Capistrano 来快速部署新版本的网站程序,使用 Munin 来监测服务器资源、Nagios 来警告、Syslog-ng 来做日志,使用 Memcached 来缓存数据库对象,部分需要缓存 larger object 的地方用到了 Tokyo Cabinet/Tyrant。Ravelry 几乎把站内所有的用到 Markdown 标记语法的页面都缓存成了普通的 HTML。

Ravelry 在开始上线的头几个月几乎每天都会修正 bug、推出新版本,得益于 Ruby 的快速开和 prototype 的能力。Casey 说,Ruby is fun! Fun is important.