超群.com的博客

Flickr架构(二)

本博客所有原创文章采用知识共享署名-非商业性使用-相同方式共享，转载请保留链接http://chaoqun.17348.com/2008/08/flickr_architecture_part_ii/

Flickr的架构不能说是完美的，没有完美的架构，ebay对于扩展有以下建议：

• 不要预先去为性能扩展，出现问题之后找到问题再寻扩展；
• 不要想寻找到一个一劳永逸的方案，因为你不知道下一个瓶颈在哪里；
• 访问量大了，出了问题，修改架构，稳定运行，访问量再大了，又出问题了，再修改，这个是解决问题的唯一方案。

Flickr是Lamp架构比较成功的案例之一，抛出Flickr的架构是因为看到国内很多的架构设计盲目、迷信以及短视，不过相对于架构来说，程序的结构更让人担忧，后面的我会写一些关于程序结构的文章，希望能和大家一起讨论成长，好了，我们继续Flickr的架构。

• “Statelessness”设计，@fininan提示是“无状态”设计，比我开始译的达意许多，不过还是不太明白具体细节，原文”Statelessness means they can bounce people around servers and it’s easier to make their APIs.”，希望懂得朋友补充。
• 通过master－save的设计能解决一部分问题，但很快你就会发现不行了，常见的master－slave只能解决读的问题，但存在单点失败故障，而且当负载比较重的时候会存在复制延迟的问题，很多公司都会碰到。
• 搜索功能由专门的服务器群来支持，通过复制需要搜索的内容到搜索服务器去搜索，和App servers分开。
• 集群
  1、分表：按照一定主键拆分数据表，比如按照用户划分；
  2、一个用户的所有信息在同一组服务器上
  3、数据能够在不同的服务器组上迁移（Statelessness）
  4、一组中心服务器负责查询，比如定位某个用户在哪个服务器组
  5、不要以用户ID作为分组的依据（Non-Statelessness）
• 服务器组中每台服务保持50％的负载，当某台服务器down机或者维护时，另外一台服务器100％负载
• 访问高峰时，每台服务器的负载可能高于50％，现在Flickr通过增加服务器来让服务器负载在50％以下
• 每个页面大概有27～35个mysql query（够高的），点击数统计、API调用数据库都是实时的（太恐怖了，估计只有Dathan Pattishall会这么变态的使用mysql）
• 每组服务器处理40万+的用户数据，很多数据存储了双份，比如A用户对B用户的博客进行了评论，那么评论的数据在A的数据表里面和B的数据表里面都存储了一份，Flickr通过事务来保证同步。（这样做的目的是保证同一个用户的数据都存放在同一组服务器上，省去复制的成本。）
• Flickr的硬件设置：Intel EMT64处理器/红帽RHEL4/16GB内存/6块15000转的硬盘做RAID-10/12TB用户数据（仅仅是数据库而不是图片）/2U服务器，每个服务大概有120GB数据
• 备份：每天不同时刻跑cron，每天晚上做数据库快照，专门的服务组来备份（和线上业务分开），交叉备份（比如每天、每周、每月）
• 每张图片都有自己的档案，档案包括大小、尺寸、像素等等，储存在数据中
• 每组服务器最多400个连接，45个线程缓存
• Tag标签，Flickr发现常见的数据库结构不能很好的处理巨大的标签库，他们采用的是类似倒排索引以及大量的缓存来处理，并且Tag标签不是实时的，他们会在线下进行统计
• Flickr目标是所有的事务都做成实时的，没有延迟（个人觉得倒是没有这个必要）

Todd Hoff总结的经验：

• 不要把你的应用简单的看成一个Web应用，可能会有REST APIs, SOAP APIs, RSS feeds, Atom feeds等等的应用
• 无“状态”设计，不要把你的用户死死的绑定在某个服务器上
• 产品设计时需要做扩容的计划以及预算
• 慢慢来，不要一开始就买一堆服务器
• 实地考察，不要臆想，获得实际数据之后再做决定
• 内建日志系统，记录服务器和应用日志
• Cache，缓存是必不可少的
• 抽象层，由于你的架构随时可能变，架构的变化必定要带来底层的变化，这就需要你在底层的基础上根据业务封装一层中间层，这样底层的改动不至于影响业务（这个太重要了，不要因为扩展把原来的程序推倒重来）
• 迭代开发，随时改进
• 忘记那些调优的小技巧吧，比如很多人对与PHP里面的require和require_once的性能差别，这些性能的差异和架构上的短板比起来根本不足为道
• 在线上测试你的效果
• 忘记用工具测试出来的结果，这些结果只能给你一个大概的印象而已
• 找出你的系统短板，一台服务器的最大处理能力是多少？现在离最大负载还有多远？mysql的瓶颈在哪里？是不是磁盘IO？memcache的瓶颈在哪里？CPU还是网络传输？
• 注意你的用户使用规律，比如Flickr发现每年的第一个工作日比平时多20％～40％的上传量，周日的访问量比平时要多40％～50％
• 要注意指数型的增长
• 你的计划是为你访问的峰值设计的

补充：阅读完原文的评论，有一个评论翻译出来给大家分享：

Flickr如何存储图片的呢？

标准的Flickr图片Url是这样的http://farm1.static.flickr.com/104/301293250_dc284905d0_m.jpg，其中farm1是Flickr的服务器群，static.flickr.com是Flickr静态图片服务器，104是服务器ID，301293250是图片ID，dc284905d0是Flickr的加密串，防止盗链，m表示图片的尺寸。m表示中等尺寸

后记：

终于“翻译”（姑且用这个词）完了，看到原文的一个评论是”Hmm… i can not beleive flickr written on php…”，借用好像也是Flickr的人说的一句话：扩展的不是语言，而是架构。国内很多大的企业都在用PHP（比如我所在的sina），PHP总给人是草根语言的感觉，是因为没有人肯分享自己的架构，以及程序员写程序的时候不注意自己的结构（设计模式），好的架构只能让你的程序跑的更快，好的结构让你的程序更易于维护，更容易让别人看的懂，更容易团队合作。

Tags: Arch, flickr