SmugMug 的架构介绍

本文介绍的  SmugMug   是一家提供付费图片托管服务的站点，在 2002 年由 Chris MacAskill 与 Don MacAskill 父子二人创建，最初提供面向游戏的视频服务，随后转型为现在的模式。网站流量现在是全球 1800 多，盈利能力自称良好。

在 MySQL Conf 2009 上，SmugMug 的  Don MacAskill   做了一次关于SmugMug 网站架构 的分享。

SmugMug 整个网站采用 LAMP 架构(其实也有 OpenSolaris)，300 多台 4 核（或更多）的服务器（大多是 AMD 的 CPU） ，分散在四个机房，两个运营的人员。SmugMug 充分运用了云计算服务，是 Amazon 的一个大客户，图片和视频总计达到了 PB 级，托管在  Amazon S3   上，图片和视频的处理也在 Amazon EC2 上。使用了  Akamai   的服务做前端的  CDN   加速，主要是 JavaScript/CSS   等文件的加速，此外，DNS 加速也带来了很好的收益。

结构化数据放在 MySQL 中，存储引擎多数用的 InnoDB，数据超过 2TB 的空间，数据库服务器为 4 核或更高配置，内存多达 64GB。缓存方面，用了 Memcached 做加速，有 1TB 的数据在这里面，平均命中率达到 96%。Memcached 里面尽量存放 MySQL 行数据，减小对  DB   的冲击。数据库设计思路是尽量做垂直分区，没有 Sharding。不过在反范式(denormalized)方面做得比较彻底，不用表连接(JOIN)方法者复杂的查询。多数查询依赖主键，更新或者删除数据也是单行，依赖主键。InnoDB 引擎打了  Percona   的 Patch，并发能力也有了很大增强。

对  DB   的数据完整性与写能力的要求高，而对于读的扩展性还是相对比较好解决。Linux 上的文件系统是 SmugMug 不太满意的地方，备份也成问题。ZFS   倒是能满足相关的需求，可惜不支持 Linux(妈的，早该支持 Linux了)。所以他们迁移到了 OpenSolaris   上。另外，对于复制中可能出现的风险，尝试了第三方提供的一些 Patch (参考  Google 发布的 MySQL Patch )。

采用 OpenSolaris 后，MySQL 放在 Sun Sushi Toro(Storage 7410 ，这个东西也支持  SSD   ) 上，走 NFSv3 协议。写到这里，发现 SmugMug 的解决方案非常不具有通用行，看起来 Sun 是给了他们不小的硬件优惠，否则一般情况下不会有人这么搞的，用  NFS   协议走数据库，除非是测试环境或者是复制(我怀疑只是 Slave 端通过  NFS   走)，产品上真的有人跑么?

网站架构的进化，其实也是选定一个方向(比如用开源工具解决)，然后一直试错的过程。

--EOF --

 

原文：http://www.dbanotes.net/arch/smugmug_arch.html