系统结构
    关于Flickr站点体系结构的一组图像化的展示，如图一所示，更多关于Flickr站点体系结构的描述，你可以在这个页面查到。进行简单的描述就是：
—一对ServerIron
—Squid Caches
—Net应用程序
—PHP应用程序服务器
—存储管理器
—Master-master碎片
—双树形中心数据库
—Memcached Cluster
—大型搜索引擎

    双重树形系统结构是一项对MySQL常规配置，通过增加masters，而不是环形体系结构来增加伸缩性。比起需要两倍硬件的master-master安装来说，这种方式你只需要较少的硬件，因此节约了提高网站伸缩性的费用。

 系统结构中的中心数据库包括想用户表这样的数据，这个表包括主要的用户信息，主键，和指向用户相关的数据。
对于静态内容使用的专门服务器
研究如何支持Unicode
不要使用共用的结构系统
所有的东西（除了照片）都要存在数据库中
创建一个搜索农场（search farm），复制部分需要进行搜索的数据库
使用横尺度，保证更多所必需的的机器
分析每封邮件，处理用户通过邮件发送的图片。
早期曾经遭受Master-Slave延迟。太多负载会有出现单点故障
保证网站一直开通，不断修复数据等等，不要让网站关闭
进行好的容量规划。获取更多的信息查看文章前面部分的参考文献。
使用统一的方法以便为了以后进行伸缩扩展
碎片：我的一些数据存储在我拥有的磁盘碎片上，但是进行对你的一些评论，存储在你的碎片空间上。如当你对其它人的博客进行评论的时候，这种情况就会发生。
Global Ring:像DNS，你需要知道页面往哪里链接，谁来控制方向。每一个页面的浏览，都要计算当前你的数据在哪里。

PHP 逻辑来连接那些碎片空间，保持数据的一致性（带注释的10行代码）

碎片
—主要数据库的一个小部分
—活动的Master-Master Ring Replication：MySQL 4.1中的小缺点，而在Master-Master—确是光环。ID自动增加能保持有效。

对于新的用户，碎片的分配是一个随机数。

    迁移是时不时要发生的，因此你可以删除一些用户。当有很多的照片的时候，你需要均衡。192,000张照片，700,000标签的迁移需要大约3-4分钟。迁移时人工完成的。

移出Cache中的照片拥有帐户，给他们分配一个碎片空间地址。从cache中移出我的信息，将它们加到我的碎片地址中去。

    如果当前主机宕机，访问列表中的下一个主句，如果所有的主机宕机，显示一个错误页面。他们不会使用持久性连接。每一个页面加载，都要测试连接。

    每个用户的读写都放在一个碎片中。不存在什么复制延迟的事情。

    平均请求每个页面，用到 27-35 SQL语句。API访问数据库都是实时的。完成实时处理需求

    每秒超过3600个请求，在容量极限范围之内。在高峰期爆发时，会达到两个36000每秒的请求数。

每个碎片能持有400K以上的数据

    许多数据存储了两次。举个例子，一个评论关系到评论者和被评论者。评论存储在什么地方？是不是在两个地方都存储了?事务处理机制用来阻止同步数据：打开事务1，写入一些命令，打开事务2，写入一些命令，提交第一个事物后，如果第一个提交，再提交第二个事务。但是这还有存在失败的可能性，可能提交了两次。

硬件：
- EMT64 w/RHEL4, 16GB RAM
- 6-disk 15K RPM RAID-10.
- 2U 逻辑单元。每个碎片空间存储~120GB数据

备份过程：
    每天晚上对整个数据库集群进行快照
    当在进行复制备份文件时，在复制文件存储中一次写入或者删除几个大的备份文件会损害性能。对图片存储文件进行这种操作时非常坏的主意。

    虽然将你所有的数据进行备份很多天使非常耗费资源的，但是这么做是值得的。保持错列的备份时很有用的，特别是当你在几天后发现出现问题的时候。你可以做1，2，10，30天的备份。

    图片是存储在文件夹中。当你上传的时候，会处理图片，供给你不同的尺寸选择。元数据和指向文件夹的路径会保存在数据库中。
    每个shard max_connections = 40的连接数，或者每个server & shard加起来等于800的连接数。线程高速缓冲器设置为45，因为你不会有超过45个用户同时在活动。

标签
    对于传统的关系型数据库管理系统设计，标签是不太适合的。方向规格化或者重型高速缓冲器是唯一的方法来生成标签，一毫秒能产生上百万的标签。

未来的方向：
    使用实时BCP，能够运行的更快，因此所有的数据中心一直都能够接受写入信息。所有的资源都是使用中的，没有一个将会在空闲。