"在前一期 山寨交流会 上： 桂 新 说他会将良好的构架和一套完整的监控系统作为两个非常重要的基础来抓，良好的架构一步到位这点很难做到（对于发展速度并不确定的小公司来说，架 构过大也是一个成本上的风险），但对于后者：一套完整监控系统我是非常认同的。对于目前普遍缺乏测试的Web应用开发过程来说，监控几乎就是测试很重要的 一部分；而系统监控本身，也可以帮助及时发现很多问题并量化优化的效果。而系统的扩展和调优的大部分技巧都可以从《构建可扩展的Web站点》(作者是 Flickr的开发者)一书中看到。为了减少不必要的调优（盲目的调优是危害很大的），建议从这2章开始看起： 第8章《瓶颈》发现和第10章《统计数据，检测和报警》；有了这些瓶颈检查结果和统计监测/报警系统后，再有针对性的看其他章节做系统调优。\n以下是我在 博客大巴 开 发中的一些实践小结：\n1 数据库相关\n1.1 系统应用层面出问题我一般都习惯性的先去看数据库群的连接数统计：大部分应用最后的瓶颈都在于单表数据量过大后，数据存取慢导致的并发连接数过多的问题，\n1.2 解决这个问题目前的主要策略就是分片( share nothing)，单个数 …"

"在前不久结束的 QCon 2008 上，MySpace 的首席架构师 Dan Farino 做了题为 Behind the Scenes at MySpace.com (PDF 下载)的技术演讲。\n架构概况 超过 4,500 台 Web 服务器，配置为 Windows 2003/IIS 6.0/ASP.NET ；超过 1200 台 Cache 服务器，64 位的 Windows 2003，超过 500 台的数据库服务器，配置为 64 位的 Windows 2003，数据库为 SQL Server 2005 。\n之前曾有一篇 揭 秘 MySpace 架构的文章，也有中文版本《 亿万用户网站 MySpace的成功秘密》！\n运维数据收集 其实这个演讲我感觉主要讲的是这个数据收集模块 🙂 MySpace 的方案倒是让我们看到了在超大规模的 Windows 环境下如何进行数据收集的。\n每个客户端通过一个 TCP 连接到收集上服务器。收集的信息包括：Windows 性能计数器 Performance Counters、 WMI 对象(定制后的 WMI 对象)、事件日志、 硬件数据等等。收集器服 …"

"从老高的近期工作总结中看到：\n目前的技术状况是基于自行设计的 PHP 框架，跑在 PHP 5.2 + MySQL 5.1 下，PHP 使用 Fastcgi 模式，WebServer 选择了 Nginx。搜索功能基于 Lucene 开发。缓存代理使用 Varnish。\n对老高进行了一次非正式采访，聊了不少内容，整理了一下和大家分享。(谁是高春辉? 这个不要介绍了吧，请 Google! )\n历史情况 Fenng: 原来大约是用什么? 框架用的什么？ 高春辉: 你说老系统？Apache 1.3 , DB 是 MySQL 4.0。新框架是团队自己写的，定制了一些东西吧，主要强调的是性能和方便、简单。另外把针对 YSlow 的优化也做进去了。 Fenng: 单说现在用的框架，大约投入了多少个人/天 ? 高春辉: 从全年开始考虑写，一直不断的写 — 具体时间不好说。反正是不少了 🙂 Fenng: 看了你 Blog 中的描述，有个小疑惑：没使用面向 DB 的 Cache 层? 高春辉: 我文中说的 Data accessor 就算是了。目前是拿 PHP 做的，Client+Server 集成在一起。 …"

"基于ID的分片机制实现存储的分布化会遇到一个问题：固定存储空间随着时间增加再次达到系统的空间/负载的瓶颈。观察了一下Flickr的图片存储 地址：好像是在定期启用新的集群，各个时期的域名分布如下：\nhttp://farm1.static.flickr.com 2006年中以前；\nhttp://farm2.static.flickr.com 2006年底；\nhttp://farm3.static.flickr.com 2007年底；\nhttp://farm4.static.flickr.com 2008年底；\n《构建可扩展的Web站点》 上 没有提到这个策略，猜测Flickr应该是不断在启用新的服务器集群，当地一个集群用到90%的时候，开始启用下一个集群。一个用户的所有图片地址则存储 在数据库中：记录会包含当时的存储所在的集群：\nuser_foo – farm1.static……/20060124_003.jpg\n\\ farm1.static……/20060324_005.jpg\n\\ farm1.static……/20060824_021.jpg\n\\ …"

"当Microsoft在PDC2008上携 Azure平台 驾 云而来时，天气预测注定将发生改变。将当前市场上分别来自Amazon、Google和Microsoft的三大主流产品作一比较会是一件非常有意思的事 儿。第一眼看上去的印象是它们彼此之间似乎实际上并不存在真正的相互竞争。\nZiff兄弟投资的副总裁Michael J. Miller 对云计算的三大角逐者进行了比较，这是他关于Amazon EC2的发现：\n备受关注的云平台无疑就是Amazon Web服务了，它是多种工具 的集合，大部分都位于相当底层。其中又以Amazon弹性计算云(EC2)最为出众，这一Web服务能你将应用分配给任意多的“计算单元”。简单的说，一 个标准的单一实例包括了一个“虚拟核心”，1.7GB的内存，以及160GB的存储实例（只针对该对话的存储），价格为每小时10美分。在这个服务之上， 你可能会考虑使用该公司提供的“简单存储服务”(S3)，对于前50TB的数据，其价格是每GB每月15美分，之后价格递减，同时要收取一定的交易费用。 同时你也可能考虑使用该公司的“Simple DB”数据库，或者是用于存储消息的队列服 …"

"前言：\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 …"

"很多人都觉得 eBay 在 QCon (北京) 上的技术讲座不错，但对我来说，其实 冲击力没那么大了。eBay 一两年前就是这个 PPT 。不过还是比 Amazon 的 Jeff Barr 强了很多，以后要是开个什么会，你把 Jeff Barr 请来还讲那个销售文档，估计自己都不好意思。\n不过，eBay 这次的PPT 总算还是有点更新的。\n1）数据分片(Partition Everything)\n说是分区(Partition)，这里不能简单等同于 Oracle 的分区，理解成分片(Sharding)就好啦。可以参考一下我以前写的科普小文： 开源数据库 Sharding 技术 (Share Nothing)。这里要强调一下的是，分片是在数据量的确有规模的时候才适合进行，如果单节点足以应付，那么还是不要冒 进。\n从分片的模式上，eBay 主要根据功能切分(Functional Segmentation)和水平分割(负载均衡考虑)，作为推论，所有会话都是无状态性的。\n2）异步处理(Asynchrony Everywhere)\n其实对于任何网站来说，过度追求”同步”化设计还是比较糟糕的做法。以 …"

"这次 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 读写分离上有比较丰富的经验。 …"

"传统的文件同步方案有rsync(单向) 和 unison(双向)等，它们需要扫描所有文件后进行比对，差量传输。如果文件数量达到了百万甚至千万量级，扫描所有文件将非常耗时。而且正在发生变化的 往往是其中很少的一部分，这是非常低效的方式。\n之前看了Amazon 的Dynamo的设计文档，它们每个节点的数据是通过Hash Tree来实现同步，既有通过日志来同步的软实时特点(msyql, bdb等)，也可以保证最终数据的一致性(rsync, unison等)。Hash Tree的大体思路是将所有数据存储成树状结构，每个节点的Hash是其所有子节点的Hash的Hash，叶子节点的Hash是其内容的Hash。这样一 旦某个节点发生变化，其Hash的变化会迅速传播到根节点。需要同步的系统只需要不断查询跟节点的hash，一旦有变化，顺着树状结构就能够在logN级 别的时间找到发生变化的内容，马上同步。\n文件系统天然的是树状结构，尽管不是平衡的数。如果文件的修改时间是可靠的，可以表征文件的变化，那就可以用它作为文件的Hash值。另一方面，文 件的修改通常是按顺序执行的，后修改的文件比早修改的文件具有更大 …"