"\u003cp\u003e学习了一下 Flickr 的运维工程师 John Allspaw 的这个\u003ca href=\"http://www.slideshare.net/jallspaw/operational-efficiency-hacks-web20-expo2009\"\u003eOperational Efficiency Hacks\u003c/a\u003e 讲座内容。做一点笔记。\u003c/p\u003e\n\u003cp\u003e现在 Flickr 的数据相比\u003ca href=\"http://www.dbanotes.net/web/flickr_lamp_capacity_planning.html\"\u003e2007 年\u003c/a\u003e的时候真是有了显著的增长：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e24 TB 的 MySQL 数据\u003c/li\u003e\n\u003cli\u003e每秒钟 MySQL 有 3.2 万次写操作\u003c/li\u003e\n\u003cli\u003e每秒钟 MySQL 有 12万次读操作\u003c/li\u003e\n\u003cli\u003e图片容量 6 PB\u003c/li\u003e\n\u003cli\u003e每天要用掉 10TB 存储\u003c/li\u003e\n\u003cli\u003e超过 15000 个服务监控点\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e在 2004 年的时候 ，Flickr 使用 \u003ca href=\"http://www.imagemagick.org/\"\u003eImageMagick\u003c/a\u003e (version 6.1.9)之后转移到 \u003ca href=\"http://www.graphicsmagick.org/\"\u003eGraphicsMagick\u003c/a\u003e， 我还\u003ca href=\"http://www.dbanotes.net/arch/yupoo_arch.html\"\u003e以为\u003c/a\u003e是因为版权问题，现 在知道这样做是因为速度，换用 GraphicsMagick 处理速度提升了 15%，而 ImageMagick 功能尽管强大，但都是 Flickr 用不到的功能。如无必要，勿增实体啊。GraphicsMagick 在并行方面(\u003ca href=\"http://openmp.org/wp/\"\u003eOpenMP\u003c/a\u003e)的支持也很不错(\u003ca href=\"http://www.kitchensoap.com/2008/09/02/why-we-use-graphicsmagick/\"\u003e参 考\u003c/a\u003e)。\u003c/p\u003e\n\u003cp\u003e除了技术手段的优化，Flickr 充分利用硬件本身的更新换代带来的好处，曾经用 18 台新机器替换掉原来的 67 台 Web 服务器， …\u003c/p\u003e"

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

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

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

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

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

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

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