本文主要是介绍图解Flickr的服务器架构，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
前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怎么实现视频的(里头对几种视频格式的总结也很深刻)。
这篇关于图解Flickr的服务器架构的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
