-
大型网站架构技术方案集锦
-
具体内容
PlentyOfFish
网站架构学习
采取
Windows
技术路线的
Web 2.0
站点并不多，除了
MySpace
，另外就是这个
PlentyOfF
ish
。这个站点提供
服务。一个令人津津乐道的、惊人的数据
是这个只有一个人
< br>(
创建人
Markus
Frind
）的
站点价值
10
亿
，估计要让很多人眼热，更<
/p>
何况
Markus Frind
每天只用两个小时打理网站
--
可操作性很
强嘛。
之所以选择
Windows .NET
的技术路线是因为
Markus
Frind
不懂
LAMP
那一套东
西，会啥用啥。就这样，也能支撑
超过
3000
万的日点击率
(
从这个数字也能看出来人类
对自然天性的渴望是多迫切
)
。
Todd Hoff
收集了很多关于
PlentyOfFish
架构的细节
。
记录一下感兴趣的部分。
带宽与
CPU
PlentyOfFish
比较特殊的一个地方是
几乎不需要
Cache
，
因为数据变化过快，
很快就过
期。我不知道这是因为
的特点
带来的架构特点，还是业务就是这个样子的。至
于图片，则是通过
CDN
支撑的。对于动态出站
(
outbound)
的数据进行压缩，这耗费了
30%
的
CPU
能力，但节省了带宽资源。我最近才知道，欧美的带宽
开销也不便宜。
负载均衡
微软
Windows
网络负载均衡
(Network Load
Balancing)
的一个缺陷是不能保持
Session
状态
(
我没有用过这玩意儿，不能确认
)
，价格也不便宜，
而且复杂；网络负载均
衡对
Windows
架构的站点又是必须
--IIS
的总连接数是有限制的。
PlentyOfFish
用的
是
ServerIron
(Conf
Refer
)
，
ServerIron
使用简单，而且功能比
NLB
更丰富。
数据库
一共三台
SQL Server
，一台作为主库，另外两台只读数据库支撑查询。数据库性能监控
用
的是
“Windows
任务管理器
<
/p>
。因为
Cache
没啥用，所以要花大力气优化
DB
。每个页
面上调用
DB
次数越少越好，
越简单越好，
这是常识，
不过不是每个人都体会那么深而已。
微软好
不容易找到了一个宣传案例，
所以在
Channel 9
上有一个
PlentyOfFish
的访谈
。
PlentyOfFish
取自天涯何处无芳草
(Plenty of fish in
the sea)
的意思，还挺有文化的。
从这一点上看，比国
内那些拉皮条的网站好一些。
--EOF--
YouTube
的架构扩展
1
在
西雅
图扩展性的技术研讨会
上，
YouTube
的
Cuong Do
做了关于
YouTube
Scalability
的报告。视频内容在
Google
Video
上有
(
地址
)
，可惜国内用户看不到。
Kyle Cordes
对这个视频
中的内容做了
介绍
。里面有不少技术性的内容。值得分享一下。
(Kyle Cordes
的介绍是本文的主要来源
)
简单的说
YouTube
的数据流量
,
一天的
YouTube
流量相当于发送
750
亿封电子邮件
.
2006
年中就有消息说每日
PV
超过
1
亿
,
现在
?
更夸张了
,
每天有
10
亿次下载以及
6,5000
次
上传
真假姑且不论
,
的确是超乎寻常的海量
.
国内的互联
网应用
,
但从数据量
来看
,
怕是只有
有这个规模
.
但技术上和
YouTube
就没法子比了
.
Web
服务器
YouTube
出于开发速度的考虑，
大部分代码都是
Python
开发的。
Web
服务器有部分是
Apache
，
用
FastCGI
模式。对于视频内容则用
Lighttpd
。据我所知，
MySpace
也
有部分服务器用
Lighttpd
，但量不大。
YouTube
是
Lighttpd
最成功的案例。
(
国内用
Lighttpd
站点不多，
豆瓣<
/p>
用的比较舒服。
by
Fenng
)
视频
视频的缩略图
< br>(Thumbnails)
给服务器带来了很大的挑战。
每个视频平均有
4
个缩略图，
而
每个
Web
页面上更是有多个，每秒钟因为这个带来的磁盘
IO
请求太大。
YouTube <
/p>
技
术人员启用了单独的服务器群组来承担这个压力，
并且针对
Cache
和
OS
做
了部分优化。
另一方面，缩略图请求的压力导致
Lighttpd
性能下降。通过
Hack Lighttpd
增加更多
的
worker
线程很大程度解决了问题。而最新的解决方案是起用了
Google
的
BigTable
，
这下子从性能、容错、缓存上都有更好表现。看人家这收购的，好钢用在了刀
刃
上。
出于冗余的考虑，每个视频文件放在一组迷你
Cluster
上，所谓
迷你
Clu
ster
就是一
组具有相同内容的服务器。最火的视频放在
CDN
上，这样自己的服务器只需要承
担一些
漏网
的
随即访问即可。
YouTube
使用简单、廉价、通用的硬件，这一点和
Google
风格
倒是一致。至于维
护手段，也都是常见的工具，如
rsync, SSH
等，只不过人家更手熟罢
了。
数据库
YouTube
用
MySQL
存储元数据
--
用户信息、视频信息什么的。数据库服务器
曾经一度
遇到
SWAP
颠簸的问题，解决办法是删掉了
SWAP
分区
!
管用。
最初的
DB
只有
10
块硬盘，
RAID 10
，
后来追加了一组
RAID 1
。
够省的。
这一波
Web
2.0
公司很少有用
Oracle
的
(
我知道的只有
Bebo
,
参见这里
< br>).
在扩展性方面，路线也是
和其他站点类似，
复制，
分散
IO<
/p>
。
最终的解决之道是
分区
这个不是数据库层面的表分区，
而是业务层面的分区
(
在用户名字或者
ID
上做文章
,
应用程序控制查找机制
)
YouTube
也用
Memcached
.
2
很想了解一下国内
Web 2.0
网站的数据信息
,<
/p>
有谁可以提供一点
?
--EOF--
WikiPedia
技术架构学习分享
维基百科
(
)
位列世界十大网站
，目前排名第八位。这是开放的力量。
来点直接的数据：
?
?
?
峰值每秒钟
3
万个
HTTP
请求
每秒钟
3G
bit
流量
,
近乎
375MB
350
台
PC
服务器
(
数据来源
)
架构示意图如下：
Copy @Mark Bergsma
GeoDNS
在我写的这些网站架构的
Blog
中，
GeoDNS
第一次出现，这东西是啥
?
patch for BIND to add geographical
filters support to the existent views in
BIND
把用户带到最近的服务器。
GeoDNS
在
WikiPedia
架构中担当重任当然是由
WikiPedia
的内容性质决定的
--
面向各个国家，各个地域。
负载均衡：
LVS
3
WikiPedia
用
LVS
做负载均衡
,
是章文嵩博士发起的项
目
,
也算中国人为数不多的在开源
领域
的骄傲啦。
LVS
维护的一个老问题就是监控了，维基百科的技术人员用的是
pybal
.
图片服务器
:Lighttpd
Lighttpd
现在成了准标准图片服务器配置了。不多说。
Wiki
软件
:
MediaWiki
对
MediaWiki
的应用层优化细化得快到极致了。用开销
相对比较小的方法定位代码热点，
参见
实时性能报告
，
瓶颈在哪里，
看这样的
图树展示
一目了然。
另外一个十分值得重视的经
验是，
尽可能抛弃复杂的算法、
代价昂贵的查询，
以及可能带来过度开销的
MediaWiki
特
性。
Cache! Cache! Cache!
维基百科网站成功的第一关键要素就是
Cache
了。
CDN(
其实也算是
Cache)
做内容分
发到不同的大洲、
Squid
作为反向代理
.
数据库
Cache
用
Memcached
，
30
台，每台
2G
。对所有可能的数据尽可能的
Cache
，但他们也提醒了
Cache
的开销并非永远都是<
/p>
最小的，尽可能使用，但不能过度使用。
数据库
: MySQL
MediaWiki
用的
DB
是
MySQL. MySQL
在
Web 2.0
技术上的常见的一些扩展方案他
们也在使用。
复制、
读写分离
......
应用在
DB
上的负载均衡通过
来
做到的，
可以给我们一个很好的参考。
运营这样的站点，
WikiPedia
每年的开支是
200
万美元，技术人员只有
6
个，惊人的高
效。
参考文档：
Wikimedia
architecture
（
PDF)
Todd Hoff
的文章
--EOF--
Tailrank
网站架构
每天数以千万计的
Blog
内容中，实时的热点是什么
?
Tailrank
这个
Web 2.0
Startup
致力于回答这个问题。
4
专门爆料网站架构的
Todd
Hoff
对
Kevin Burton
进行了采访。于是我们能了解一下
Tailrank
架构
的一些信息。每小时索引
2400
万的
Blog
与
Feed
，内容处理能力为
160-200Mbps
，
IO
写入大约在
10-15MBps
。每个月要
处理
52T
之多的原始数据。
Tailrank
所用的爬虫现在已经成为一个独立产品：
spinn3r
。
服务器硬件
目前大约
15
台服务器，
CPU
是
64
位的
Opteron
。每台主机上挂两个
SATA
盘，做
RAID 0
。据我所知，国内很多
Web 2.0
公司也用的是类似的方式，
SATA
盘容量达，低
廉价格，堪称不二之选。操作系统用的是
Debian Linux
。
Web
服务器用
Apache
2.0
，
Squid
做反向代理服务器。
数据库
Tailrank
用
MySQL
数据库，
联邦数据库形式。
存储引擎用
InnoDB
，
数据量
500GB
。
Kevin
Burton
也指出了
MySQL
5
在修了一些
多核模式下互斥锁的问题
(
This
Bug
?)
。
到数据库的
JDBC
驱动连接池用
lbpool
做负载均衡。
MySQL Slave
或者
Master
< br>的复
制用
MySQLSlaveSync
来轻
松完成。
不过即使这样，
还要花费
20
％
的时间来折腾
DB
。
其他开放的软件
任何一套系统都离不开合适的
Profiling
工具，
Tailrank
也不利外，针对
Java
程序的
Benchmark
用
Benchmark4j
。
Log
工具用
Log5j
< br>(
不是
Log4j)
。
Tailrank
所用的大
部分工具都是开放的。
Tailrank
的一个比较大的竞争对手是
Tech
meme
，虽然二者暂时看面向内容的侧重点有
所不同。其实，
最大的对手还是自己，当需要挖掘的信息量越来越大，
如果精准
并及时的呈
现给用户内容的成本会越来越高。从现在来看，
Ta
ilrank
离预期目标还差的很远。期待罗
马早日建成。<
/p>
--EOF--
LinkedIn
架构笔记
5
现在是
SNS
的春天，最近又有消息
传言新
闻集团准备收购
LinkedIn
。
有趣的是，
LinkedIn
也是
Paypal
黑帮
成员创建的。在最近一个季度，有两个
Web 2.0
应用我用
的比较频繁
。一个是
Twitter
，另一个就是
LinkedIn
。
LinkedIn
的
CTO Jean-Luc Vaillant
在
QCon
大会上做了
”
Linked-In: Lessons
learned and growth and
scalability
“
的报告。不能错过，写一则
Blog
记录之。
LinkedIn
雇员有
180
个，在
Web 2.0
公司中算是比较多的，不过人家自从
2006
年
就盈利了，
这在
Web 2.0
站点中可算少的。
用户超过
1600
万，
现在每月新增
100
万，
50
％
会员来自海外
(
中国用户不少，也包括
我
).
开篇明义，
< br>直接说这个议题不讲
监控、
负载
均衡
”
等话题，
而是实实在在对这样特
定类型站
点遇到的技术问题做了分享。
LinkedIn
的服务器多是
x86
上的
Solaris
，关键
DB
用
的是
Oracle 10g
。人与人之间的关系图生成的时候，关系
数据库有些不合时宜，而把数据
放到内存里进行计算就是必经之路。具体一点说，
LinkedIn
的基本模式是这样的：前台应
用服务器面向用户，中间是
DB
，而
DB
的后边还有计算服务器来计算用户间的关系图的。
问题出来了，如何保证数据在各个
RAM
块
(
也就是不同的计算服务器
)
中是同步的呢
?
需
要一个比较理想的数据总线
(
DataBus)
机制。
第一个方式是用
Timestamp
.
对记录设置一个字段，标记最新更新时间。这个解决方法
还
是不错的
---
除了有个难以容忍的缺陷。
什么问题？就是
Timestamp
是
SQL
调
用发起
的时间，而不是
Commit
的确切时间。步调就不一致喽。
6
第二个办法，用
Oracle
的
ORA_ROWSCN
(
还好是
Oracle 10g).
这个伪列包含
Commit
时候的
SCN(System
Change Number)
，是自增的，
DB
自己实现的，对性
能没有影响。
Ora_ROWS
CN
默认是数据库块级别的粒度，当然也可做到行级别的粒度。
唯一的缺点是不能索引
(
伪列
).
解决办法倒也不复杂：
增加一个
SCN
列，
默认值
< br>
无限大
。
然后用选择比某个
SCN
大的值就可以界定需要的数据扔到计算服务器的内存里。
ORA_ROWSCN
是
Oracle 10g
新增的一个特性，不得不承认，我过去
忽略了这一点。
我比较好奇的是，国内的
Wealink
、联络家等站点是如何解决这个关系图的计算的呢
< br>?
--EOF--
一点题外话：
我的
LinkedIn Profile
(Mail :
dbanotes@). Keep in Touch!
。
另
外建议正在找工作的同学不妨使用一下这类站点
(
国内的有
联络家
和
若邻
)<
/p>
。
一般人我不告
诉他
~~
Yahoo
！社区架构
7
旧金山举行的
QCon
会议带给我们很多新鲜的信
息。虽然没机会参加，但是看看各个网站
晒架构
也是个比较过瘾的事情。请参观并收藏这个页面：
Ar
chitectures you've always
wondered
about
。
eBay
的架构
和去年相比基本是换汤不换药，倒是
Yahoo!
的
Ian
Flint
(
这位老兄是
Bix
的运营总监
. Bix
已被雅虎收购
)
这个
PPT
Yahoo! Communities Architecture:
Unlikely Bedfellows
挺有意思，披露了一些鲜为人知的信息。
Yahoo!
社区包括我们比较熟悉的
、
Flickr
、
Yah
oo!
群组、
Yahoo! Mail
、
Bix
等。相当于
Yahoo
！把这些属性相近的应用放到一起运营。这个思路倒是和盛大对游戏
的
运营有些相近。
架构特点
有两点值得注意：
1
）层次化
2
）模块化。这也是大规模作业下的比较经济的途径。
软件架构
首先是操作系统已经从
FreeBSD
逐渐迁移到
RHEL
。
这怕是雅虎不得已作出来的决定吧
。
FreeBSD
的开发力量的确不如
Linux
，
这也是不争的事实。
数据库上
MySQL
与
Oracle
都有。
Yahoo!
在
DW/BI
用的是
Oracle
，构建了一个
超大数据库
。诸如
yapache
、
yts(
反向代理服务器
)
、
yfor(
提供快速失败接管
)
、
ymon
（监控），还有还有
ysquid
、
ypan(cpan
的
Yahoo!
克隆
)
这些组件都是通过
yinst
来统计部署。
关于
< br>Yapache
，
请
参考我以前
写的
Yapache-Yahoo! Apache
的秘密
这是
Bix
与
DB
有关的部署架构
:
8
数据放在
Netapp NAS <
/p>
上
(
所以有的时候应用之慢也可以理解了
)
，
通过快照复制到其他数
据中心。
Yahoo! Mail
架构：
这里面居然部署了
Oracle
RAC
，用来存储
Mail
服务相关的
Meta
数据。非常有趣。
运营维护
监控工具主要用的是
Nagios<
/p>
，用以监控集群。使用标准插件，另外也有自行定制的插件。
Na
gios
这东西太棒了。主动、被动检查的消息转发是通过
Ymon
来做到。网管上针对
SNMP
的解决方案是用
Yahoo
！自己
Y
字头的
Ywatch
。这些
Y
字头的东西基本上外
9
面都是找不到的。
Yahoo
！
的技术其实并不那么开放。
Google
在运营这方面也好不到什么
地方去。趋势图用
< br>
Drraw
展现。
Drraw
是基于
RRDtool
的
Web
展现工具。
应用服务器的监控是被动的。整个监控系统模块化部署。
Nagios
的警告信息转发到
Ywatch
中心控制台。
Note:
上面所有截图版权都属于
Ian
(Image COPYRIGHT@IAN)
。如果去看那个
PDF
文件，你或许比我收获更多。我只是让你知道我的想法而已。
--EOF--
Craigslist
的数据库架构
(
插播一则新闻：竞拍这本
《
Don’t Make Me
Think
》
，我出价
RMB 85
，留言的不算
--
不会有恶意竞拍的吧
?
要
Ping
过去才可以，失败一次，再来
)
10