"学习了一下 Flickr 的运维工程师 John Allspaw 的这个Operational Efficiency Hacks 讲座内容。做一点笔记。\n现在 Flickr 的数据相比2007 年的时候真是有了显著的增长：\n24 TB 的 MySQL 数据 每秒钟 MySQL 有 3.2 万次写操作 每秒钟 MySQL 有 12万次读操作 图片容量 6 PB 每天要用掉 10TB 存储 超过 15000 个服务监控点 在 2004 年的时候 ，Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick， 我还以为是因为版权问题，现 在知道这样做是因为速度，换用 GraphicsMagick 处理速度提升了 15%，而 ImageMagick 功能尽管强大，但都是 Flickr 用不到的功能。如无必要，勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参 考)。\n除了技术手段的优化，Flickr 充分利用硬件本身的更新换代带来的好处，曾经用 18 台新机器替换掉原来的 67 台 Web 服务器， …"

"章文嵩博士（LVS开源项目创始人）进入淘宝好几个月了，今天是他第一次讲解LVS的实现原理。作为DBA的一员，终于近距离膜拜了大牛。 讲解的内容就不具体介绍了，在LVS 官方网站上面可以找到。PPT的内容和网站上基本上一样，只是讲解人是章博士本人。我在这整理一下自己的理解，不对请大家指正。 ^_^\n组成LVS最重要的部分有三个：请求分发服务器、处理服务器、共享存储。\n典型的Web集群并不需要共享存储，只有请求分发服务器和处理服务器，如下图所示： [][2] 如果完成请求需要基于数据，那么共享存储就是LVS必须的组件了。LVS邮件服务器集群如下所示： [][3] 目前能应用于LVS的MySQL集群只能是NDB Cluster，因为MySQL众多的存储引擎中，只有NDB Cluster实现了共享存储的功能。 在NDB Cluster中，SQL Node相当于处理服务器，Data Node相当于共享存储。LVS可以让应用程序的开发更加简单，开发人员并不需要知道执行SQL的数据库服务器到底是哪一个，但是可以获得自己想要的数 据。而NDB Cluster提供的数据拆分和扩容功能，保证了数据库的可扩 …"

"前言：\n关于Digg的架构，之前 Fenng 已 经写过一篇 Digg 网站架构 的文章，Fenng在文章开头说“越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。”，其实是 Fenng过谦了，我就是从 DBA notes 一点一滴开始学习的。\n原文在 Scaling Digg and Other Web Applications， Todd Hoff 总能给我们带来一些有意思的文章。这里既不直译也不全译，保持原文骨干加上肤浅的理解。\nDigg用户在3000W左右，网站每秒请求数达到13000个，规模算是很大了，Lamp（Linux+Apache+MySQL+PHP）结 构，Web2.0网站中钟情PHP的不少，国外的Facebook、Digg、Flickr…，国内的新浪博客、开心网、51.com等等，扩展的不是编程语言而是网站架构，因为编程语言从来都不会是网站瓶颈，每种语言都有自己适合做和不适合做的事情。喜欢比较语言快慢的可以看看 http://shootout.alioth.debian.org/， 看看而已不要用速度去衡量编程语言的优劣。\nDigg的扩展战略：\n扩展 …"

"本篇描述一下 Digg 的网站架构.\n国庆期间又收集了一些关于网站架构的信息。一直没有进行系统的整理。越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。--by Fenng Digg 工程师采用 LAMP (Linux, Apache, MySQL and PHP) 模式。这个 Alexa 排名在 100 左右的、自我估价 1.5 亿美金的站点目前有超过 100 台的 PC 服务器(足够少了)，可以粗略分成三个部分：数据库服务器，Web 服务器，搜索服务器。\n数据库方面，和其他成功的 Web 2.0 站点一样，也是 MySQL，不过 Digg 稍微”激进”一点，用 MySQL 5，而且号称从 MySQL 4 升级到 5 性能没有什么影响。 OLTP 应用用 InnoDB 引擎, OLAP 用 MyISAM。后端数据库的读比例达到 98%，写只有 2%，实际的读写比例应该高于这个数字，这应该是 Digg 在前端用 Memcached 以及 APC PHP accelerator / MCache 做缓存后的效果。在 IO 上似乎压力并不大。\n数据库分割用 Sharding …"

"这次 QCon (北京)会议网站架构案例分析这个 Track ，虽然话题不多，但课程设计时候考虑覆盖的面还是比较广的。作为视频网站代表，优酷带来了一场包含不少实战经验的技术分享。邱丹(优酷网开发副总裁，核心架 构师)可能公司的事情比较忙，一直到第二天中午才赶到会场。还半开玩笑说，’怎么这么多人，还以为是小型的会议呢’…\n缓存\n缓存黄金原则：让数据更靠近 CPU。\nCPU--\u0026gt;CPU 一级缓存--\u0026gt;二级缓存--\u0026gt;内存--\u0026gt;硬盘--\u0026gt;LAN--\u0026gt;WAN 讲到了 Youku 自己的内部项目，针对大文件缓存的。目前开源软件中，Squid 的 write() 用户进程空间有消耗，Lighttpd 1.5 的 AIO(异步I/O) 读取文件到用户内存导致效率也比较低下。Youku 不用内存做缓存(避免内存拷贝，避免内存锁)。值得注意的是，缓存技术容易被滥用，也有副作用，比如接到老大哥通知要把某个视频撤下来，如果在缓存里是比 较麻烦的。\n数据库\n优酷对数据库 Sharding 做了不少尝试，而且实现效果应该不错。DB 读写分离上有比较丰富的经验。 …"

"到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，”过早优化是万恶之源”)，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。\n如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。\n拥抱熟知的技术 动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。\n架构层次清晰化 起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是 …"

"Hadoop分布式文件系统：架构 和设计要点\n一、前提和设计目标\n1、硬件错误是常态，而非异常情况，HDFS可能是有成百上千的server组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS的核心架构目标。\n2、跑在HDFS上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。\n3、HDFS以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T字节，一个单一HDFS实例应该能支撑数以千万计的文件。\n4、HDFS应用对文件要求的是write-one-read-many访问模型。一个文 件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问 题，使高吞吐量的数据访问成为可能。典型的如MapReduce框架，或者一个web crawler应用都很适合这个模型。\n5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS提供给应用这样的接口。\n6、在 …"

"网站文件的存储还是要讲究的，如果在网站成立初期，数据量不大就没有注意，随着时间的增长，网站的图片文件等数据肯定会越来越多，如何解决这些文件 存储也成了新的难题。如果把这些文件都完全采用大硬盘存储来解决，并不是一个好主意，因为数据量越大风险就越高，虽然文件能存得下，但是故障率相应会较 高，另外重建耗费时间也比较长。所以最好的办法是尽可能考虑分布式存储，把文件想办法利用网络分散到多个机器上。\n从我所了解的存储结构来看，分布式存储大致可以分为几种：\n1、类googlefs的分布式文件系统\n因为目前googlefs没有开源，所以网上出现的分布式文件系统都是利用google的方案自行实现的。这个方案的优点是可用性比较高，基本上基 于硬盘的应用都可以处理，可用范围就比较广泛。我看了gfs、gfs2、ocfs2、FastDFS、MogileFS的一些相关介绍，大致有一些认识。\n首先是文档比较少而出现的问题倒不少;然后是目前这些还没有一个能称得上是稳定版本，如果有的话，估计也就是其中一些收费的版本。因为磁盘存储乃是 致关重要，所以目前建议还是不要轻易把这些东西部署到重要的地方。假如非常想使用的话，最好 …"