Flickr的服务器架构

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

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

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

Flickr的DBADathan Vance Pattishall 的这个幻灯Federation at Flickr: DoingBillions 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怎么实现视频的(里头对几种视频格式的总结也很深刻)。