正在加载...

Flickr的架构师  Cal Henderson,在 Flickr: Web Services 这个PPT中,有对其架构比较全面的阐述。

Flickr运维团队的John Allspaw,有两个讲LAMP的幻灯,Hardware Layouts for LAMP Installations 和  capacity planning for LAMP,但应该是Flickr架构演进和运维的一些经验总结,其中也透露一些服务器架构。

John Allspaw也很强调测量(measurement)的重要性;他也很笔试benchmark,这个和我们的经验比较吻合,无论是对开源软件比如Cassandra的benchmark,或是自己开发的进程的性能测试,都与上线后运营的负载差异太大,以致对容量规划几乎没帮助。基本上需要在灰度发布后根据实际应用负载才能做比较靠谱的规划。

Flickr的DBA Dathan Vance Pattishall 的这个幻灯 Federation at Flickr: Doing Billions of Queries Per Day

是说他们怎么做shard的。当然,里面说的一些小tips也比较受用的,比如 Swapiness set to 0,我们自己就曾有服务器进程被swapiness搞堵。其中提到的ticket server,则在Flickr的官方博客上的 Ticket Servers: Distributed Unique Primary Keys on the Cheap做了详细讲解。

Flickr的前员工Mikhail Panchenko在Strange Loop 2010会议上做了标题为Flickr架构的演进(The Evolution of the Flickr Architecture)的演讲, InfoQ上有视频录像可以看,这里可以下载幻灯。

没错,是前员工,已经离开Flickr了,却在讲Flickr的架构。

看了视频,其实并没有讲太多技术架构的具体实现和设计。大多数时候在批评Flickr里头写的PHP代码,以及他对各种流行技术的看法。

包括对Foursqure前些时候的MogoDB宕机事件,他也认为不是MogoDB问题。

“This isn’t a MongoDB problem.

It’s an “It’s NoSQL, so I don’t have

to think about it” problem. ”

Flickr坚持用MySQL,他是这样说的:

“As far as I can tell, the

amount of effort spent

making various datasets fit

NoSQL databases is

equivalent to the time it

takes to get good at MySQL”

他说的3个have to很实在:

• You have to know what it is you need and

what your limits are

• You have to monitor for those limits

• You have to have a plan for what you’re

gonna do to continue avoiding those limits

他们也用了Redis,在他的那个offline tasks system,对Redis评价很高。

Cal Henderson的另一个幻灯expo08nyc_moving_pictures.pps,则是讲Flickr怎么实现视频的(里头对几种视频格式的总结也很深刻)。

作者:yanghehong

: http://www.ha97.com/4191.html

本文相关评论 - 才一条评论
2012-09-04 15:53:03
Google Chrome 21.0.1180.83 Google Chrome 21.0.1180.83 Windows 7 x64 Edition Windows 7 x64 Edition

很不错的flickr服务器架构,学习了