replication by orczhou, on Flickr

在使用MySQL的应用中，如果你的MySQL Server压力逐渐增大，在应用层优化已经到了一定瓶颈时，那么你应该首先考虑 MySQL Replication。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。

如何同步

1. 主库将所有的更新操作，写入二进制日志。

2. 从库运行”IO线程”（Slave IO Thread）读取主库的二进制日志。

3. 从库运行”SQL线程”（Slave SQL Thread）执行IO线程（Slave IO Thread）读取的日志中的SQL,从而保持和主库的一致。

如何分配请求

1. 目前，这部分需要在应用层实现。

2. 执行更新SQL(UPDATE，INSERT，DELETE)时，请求主库。

3. 执行查询SQL(SELECT)时，请求从库。

所以，当你的应用(Application)SELECT请求所占的比率越大，那么Relication就会越有效。

Explain ID详解

含义：select查询的序列号，是一组数字，表示的是查询中执行select子句或者是操作表的顺序。

id的情况有三种，分别是：

• id相同表示加载表的顺序是从上到下。
• id不同id值越大，优先级越高，越先被执行。
• id有相同，也有不同，同时存在。id相同的可以认为是一组，从上往下顺序执行；在所有的组中，id的值越大，优先级越高，越先执行。

再看一个查询计划的例子：

执行顺序依次为 4 -> 3 -> 2 > 1 > NULL

第一行：id列为1，表示第一个select，select_type列的primary表示该查询为外层查询，table列被标记为，表示查询结果来自一个衍生表，其中3代表该查询衍生自第三个select查询，即id为3的select。[select d1.name……]

第二行：id为3，表示该查询的执行次序为2（4→3），是整个查询中第三个select的一部分。因查询包含在from中，所以为derived。[select id,name from t1 where other_column=”]

第三行：select列表中的子查询，select_type为subquery，为整个查询中的第二个select。[select id from t3]

第四行：select_type为union，说明第四个select是union里的第二个select，最先执行。[select name,id from t2]

第五行：代表从union的临时表中读取行的阶段，table列的表示用第一个和第四个select的结果进行union操作。[两个结果union操作]

Extra:包含不适合在其他列中显示但十分重要的额外信息。

Only index，这意味着信息只用索引树中的信息检索出的，这比扫描整个表要快。

Using where 是使用上了where限制，表示MySQL服务器在存储引擎收到记录后进行“后过滤”（Post-filter），如果查询未能使用索引，Using where的作用只是提醒我们MySQL将用where子句来过滤结果集。

impossible where 表示用不着where，一般就是没查出来啥。

Using filesort（MySQL中无法利用索引完成的排序操作称为“文件排序”）当我们试图对一个没有索引的字段进行排序时，就是filesoft。它跟文件没有任何关系，实际上是内部的一个快速排序。

Using temporary（表示MySQL需要使用临时表来存储结果集，常见于排序和分组查询），使用filesort和temporary的话会很吃力，WHERE和ORDER BY的索引经常无法兼顾，如果按照WHERE来确定索引，那么在ORDER BY时，就必然会引起Using filesort，这就要看是先过滤再排序划算，还是先排序再过滤划算。

https://blog.csdn.net/xifeijian/article/details/19773795

章文嵩博士（LVS开源项目创始人）进入淘宝好几个月了，今天是他第一次讲解LVS的实现原理。作为DBA的一员，终于近距离膜拜了大牛。 讲解的内容就不具体介绍了，在LVS 官方网站上面可以找到。PPT的内容和网站上基本上一样，只是讲解人是章博士本人。我在这整理一下自己的理解，不对请大家指正。 ^_^

组成LVS最重要的部分有三个：请求分发服务器、处理服务器、共享存储。

典型的Web集群并不需要共享存储，只有请求分发服务器和处理服务器，如下图所示： [][2] 如果完成请求需要基于数据，那么共享存储就是LVS必须的组件了。LVS邮件服务器集群如下所示： [][3] 目前能应用于LVS的MySQL集群只能是NDB Cluster，因为MySQL众多的存储引擎中，只有NDB Cluster实现了共享存储的功能。 在NDB Cluster中，SQL Node相当于处理服务器，Data Node相当于共享存储。LVS可以让应用程序的开发更加简单，开发人员并不需要知道执行SQL的数据库服务器到底是哪一个，但是可以获得自己想要的数 据。而NDB Cluster提供的数据拆分和扩容功能，保证了数据库的可扩展性。

美中不足的是，NDB Cluster的性能实在太差。即使LVS负载均衡做得很好很强大，NDB Cluster也会成为瓶颈。 根据我的观察发现，LVS的架构非常适用于CPU-bound的应用场景。虽然共享存储的引入使得LVS能够支持有状态的连接，但是LVS并不适用于 IO-bound的应用。因为不管负载如何均衡，最终瓶颈在于共享存储之上。而共享存储如何拓展，LVS并不关心。也许只有NDB Cluster提升了IO性能之后，LVS才能真正在MySQL方面应用起来。

非常感谢章博士的分享，NDB Cluster终于让我觉得不那么鸡肋了。

mysqldump是非常重要的MySQL备份工具。然而在长年累月的使用过程中，TAOBAO多次出现了因mysqldump意外终止而导致备份 失败的情况。 以下是我们经常遇到的问题：

1、Lost connection to MySQL server at ‘reading initial communication packet’： 这个主要是因为DNS不稳定导致的。如果做了网络隔离，MySQL处于一个相对安全的网络环境，那么开启skip-name-resolve选项将会最大 程度避免这个问题。

2、Lost connection to MySQL server at ‘reading authorization packet’： 从MySQL获取一个可用的连接是多次握手的结果。在多次握手的过程中，网络波动会导致握手失败。增加connect_timeout可以解决这个问题； 然而增加connect_timeout并不能防止网络故障的发生，反而会引起MySQL线程占用。最好的解决办法是让mysqldump重新发起连接请 求。

3、Lost connection to MySQL server during query： 这个问题具备随机性，而淘宝MySQL的应用场景决定了我们无法多次备份数据以便重现问题。 然而我们注意到这个问题一般会在两种情况下会发生。一种是mysqldump *\* | gzip ****；另外一种是mysqldump **** > /nfs-file 注意，不管是gzip还是nfs都有一种特点，那就是它们影响了mysqldump的速度。从这个角度思考，是不是mysqldump从MySQL接受数 据包的速度不够快导致Lost connection to MySQL server during query错误呢？

为了定位到问题，我搭建了一个测试环境： [email protected]：3306 CREATE TABLE `test` ( `id` bigint(20) NOT NULL auto_increment, `b` varchar(2000) default NULL, `c` varchar(2000) default NULL, `d` varchar(2000) default NULL, `e` varchar(2000) default NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

“And God said, Let there be network: and there was timeout” 在使用MySQL的过程中，你是否遇到了众多让人百思不得其解的Timeout？ 那么这些Timeout之后，到底是代码问题，还是不为人知的匠心独具？ 本期Out-man，讲述咱们MySQL DBA自己的Timeout。

先看一下比较常见的Timeout参数和相关解释： connect_timeout The number of seconds that the mysqld server waits for a connect packet before responding with Bad handshake. interactive_timeout The number of seconds the server waits for activity on an interactive connection before closing it. wait_timeout The number of seconds the server waits for activity on a noninteractive connection before closing it. net_read_timeout The number of seconds to wait for more data from a connection before aborting the read. net_write_timeout The number of seconds to wait for a block to be written to a connection before aborting the write.

在经历了2009年的分布式启步之后，经过改造的数据库系统性能得到极大的提升，但这个变化仍然不构成今天这篇文章的主题，我想要说的是另外一方面的变 化，这个变化在某种程度上影响着当前DBA的角色变化问题。

在分布式数据库时代，开发DBA的开发支持工作相比于以前，会有更多的系统思考问题的机会，会结合应用来设计量身定做的分布式数据库系统，如果一个DBA 对业务有着深刻的理解，深刻理解数据库原理，既具有整体性的架构思维，又有一些关键细节把握能力的时候，设计一套分布式系统是水到渠成的事。对于开发支持 的一些工作，比如SQL审核，表结构变更，数据订正，历史迁移，如果没有工具的支持，那做起来还是比较吃力的。这些方面，我们还有许多的道路要走，怎么样 改变目前的现状。

在分布式数据库时代，系统DBA的运维要求难度在某方面有所降低，整个应用因为在容错性方面做了比较多的努力，比如down掉一个数据库时，对于整个应用 系统的健康运行影响较小,运维的压力相对减少。相比于集中式的数据库环境下的运维，在另外一个层面运维难度又有所增加，第一，运维的机器数量呈几何指数的 增长，由于大量采用低端机器，集群中某个机器出问题的概率大增，可能每天都会处理好几次down机的事故;第二，对监控系统的要求增加，对10台数据库的 监控与对1000台数据库的监控方法肯定会有许多差异的,我们的监控系统也应该具有分布式的能力,避免单点；第三，系统精细化运维能力需要提升，采用大量 低端pc server,在机房的设计上要尽可能的下功夫，可以参考一下google的机房建设的论文，pc server的硬件在不同应用上的定制化以尽量节能，CPU个数是否存在严重过多的情况,pc server上装的linux os是否有优化过，不同版本的os是否存在稳定性问题，os上跑的mysql是否已经足够的优化。

另外一个方面的变化，是来自于我们的分布式数据层的开发人员。他们开发的数据层是前端应用与底层数据库集群的中间纽带,是整个分布式数据库系统最重要的组 成部份。而开发分布式数据层的开发人员自然会成为核心的核心，他们对于许多底层技术的理解相当的深入。与他们讨论问题时，倍感知识的匮乏。大部份DBA由 于缺乏长期的开发经验的积累，双方沟通时，有时会比较吃力。

从长远的方向来讲，分布式数据库系统将会越来越依重于分布式中间件产品，整个应用系统的健康也会更依赖于开发人员的能力。在某种程度上，分布式数据库时代 的DBA的重要性，会低于集中式数据库时代的DBA重要性。但对于公司而言，整个公司的技术实力有了质的飞跃,大大节约了成本,也掌握了未来的主动权。

如何扩大DBA的外延与内涵，来适应这种变化，是我们共同努力的方向.

微软的框架设计规范{#h.u8}是 设计的准则，它期望所有的微软类库和独立开发者都能够遵循这一准则。随着每个.NET框架版本的发布，以及在行业内的测试，它们的版本也得到了精化。通过 Cwalina与Abram所著的《框 架设计规范》第二版{#t.q.}的发布，我们可以看到微软在今后几年的发展方向。

或许最令人惊讶的事实是日渐增长的对于测试驱动开发和依赖注入的重视。在可重用框架的场景下，通过测试驱动开发设计出的框架是真实可用的，而不是简 单地推理。他们希望这样可以反过来杜绝某种趋势，那就是过度复杂地设计一些根本不会用到的功能。

谈到这一问题，就不得不指出的是微软当前正在推动的一个活动，即针对所有库的第1个版本进行最低限度设计。这不同于在第一次就要试图将所有事情做 对，微软推荐在最开始只需要满足需求中绝对需要的特性。Abrams和Cwalina建议在最初并不需要考虑扩展性，只有到需求变得非常清晰的时候，才在 后一个版本中考虑。从某个方面来讲，这是微软旧有传统的回归，它只会在第三个版本中提供真正完成的应用程序。

在其它领域，微软则完全没有改变。他们仍然强调所谓的“基坑成功（Pit of Success）”，并将其作为设计圭臬，特别是在谈及开发者的生产力时，尤其如此。例如，对于Exception类的构造函数应该定义为 protected，而不是public，这就可以强迫开发者采取正确的方式，抛出一个适当的异常。相反地，我们现在必须借助于FxCop准则对此进行检 查。

他们不断鼓吹的另一个原则是“相同的力量”，对这一目标的追求可以使得新类库的工作方式，对于其他.NET类库的用户而言是直观的。它被应用在代码 的各个方面，包括命名规范、术语约定以及设计模式。

微软强调的新增内容是依赖注入。虽然他们总是被用在各个类库中，但从未如此正式地将其看作为一种设计模式。相反，它仅仅在API需要时作为一种补 充。这种情况到了.NET 3.0有所改变，依赖注入与控制反转都是一种特定的要求。

一旦涉及到CLR顶端的技术，框架设计规范就是不可知的。例如，微软并没有用它来推动依赖注入类库，即托管的可扩展性框架{#nk:0}的 运用。相反，其重点放在设计目标、编写松散耦合、可测试的代码上。

在PDC中，特别强调了某些特定的建议，包括：

类的构造函数应该是延迟的。从本质上讲，他们所要做的不仅仅是要捕获参数，因为通常不会用到新的被实例化的类。

属性应该：

• 不要抛出异常（getter）
• 不要被用作转换（getter）
• 不要产生副作用（setter）
• 足够快速，而不用考虑对象的状态
• 永远不要返回一个数组，或者一个克隆的列表（getter）

扩展方法应该用于为接口“添加”重载，也可以用于管理类库之间的依赖。例如，如果程序集B依赖于程序集A，则A中的类不会暴露B中的功能。然而，A 中的类可以通过B中的扩展方法进行标记，提供依赖的效果，但实际这种依赖并不存在。

对于类的层级，总体不应超过2到3个层级。过深的层级会导致很难保证每个实现，因为实现必须遵循整个契约。谈到这一问题，其中至关重要的一点，就是 为了保证工作正确，任何重写的成员都应该具有一个显式的契约细节，以包含子类需要做的内容。

接口应该小，最好只包含一个方法。每增加一个额外的方法，就可能使得接口难以正确设计，而在将来甚至会需要更多的方法。如果不适用于抽象基类，可以 将接口串联在一起，以构建其功能。

查看英文原文：New Directions in Framework Design Guidelines 本文出自：

统架构师角色关键的一方面就是衡量相互冲突的需求、决定解决方案，常常要牺牲一个方面来换取另一个方面。随着系统变得越来越大、越来越复杂，越来越多关于 如何构建应用的传统智慧正在受到挑战。比如说，去年3月在伦敦召开的QCon会议上，Dan Pritchard谈论了eBay的架构。他的介绍随后得到了很多的报道，其中一个主要的结论就是eBay不使用事务，用数据一致性上的损失来换取系统整 体伸缩性和性能上相当大的改进。

InfoQ接着Dan Pritchard在QCon会议上的谈话与他继续讨论，以获得更多信息：

为什么eBay不使用事务，或者为什么可以决定不采取应用级事务？

我们并非一概不使用事务。我们只是不使用跨物理资源的事务，因为它会造成多个组件之间出现依赖。组件可以是应用服务器和数据库。（例如在客户端控制 的事务中，）一个客户端的失败会长久地阻塞数据库资源、超出我们的忍受程度。我们也不使用分布式事务，因为让应用依赖于多个数据库会降低客户端实际的可用 性。相反，我们选择缺少事务的设计，并加入失效模式，失效模式可以使客户端甚至在发生数据库可用性问题的时候也能继续进行。

应用级事务总是有些问题。只要让开发人员管理资源的生命周期，就少不了因管理出错而引起的Bug。事务管理和内存管理比起来没有多大的不同，而且我 们看到由于生命周期问题，语言的总体趋势是不再让开发人员负责内存管理。假设Bean后面的每个数据库操作都是同等重要的，那么声明性事务（就像EJB中 的那些）就是一个简化事务管理的强有力的方法。

是否采用事务真正取决于你的伸缩性和可用性目标。如果你的应用需要达到每秒数百笔事务，你会发现分布式事务达不到这一目标。如果你想使可用性超过 99.9%，那么你根本不能想当然地假设所有的数据库提交都能在Web页面的上下文中完成。遗憾的是，对于何时应当放弃应用级事务并没有简单的规则。相 反，做为一名架构师，你必须决定什么时候应当为了满足系统的一个制约因素的要求而放松对另一个制约因素的要求。

你是怎样为像“出价竞拍”这样的操作实现原子性的？

出价竞拍本身就是一个很有意思的问题，原子性并不是重点，更多的是关系到在拍卖关键的最后几秒钟里不要阻塞任何出价人。如果改成在显示时刻而不是在 出价时刻计算最高出价人和最高出价，就会变得非常简单。所有出价都被插入到一个单独的子表，插入操作不太会引起资源争用的情况。每次显示产品的时候，再重 新取回所有的出价，并且在这个时候应用业务逻辑来决定最高的出价人。

你的问题背后隐藏的真正问题是我们如何实现一致性？要在大型系统中实现一致性，你必须放弃ACID，转而使用BASE：

基本可用（Basically Available） 软状态（Soft state） 最终一致（Eventually consistent）

如果你能够在每个客户端请求快结束的时候放松对数据一致的要求，就有可能消除分布式事务，并使用其它机制来达成一致的状态。举例来说，在上面的出价 案例中，我们也更新视图数据表，视图数据表是按照出价人来组织数据的，目的是加速“我的eBay”页面的显示。这里用两个异步事件来完成。一个是依靠内存 中的队列，因为我们希望尽量缩短从出价到在显示在“我的eBay”页面上之间的响应时间。但是，内存中的队列不可靠，所以在发生出价操作的时候，我们同时 用一个服务器端事务来捕获出价事件。即使内存中队列的操作失败了，这个出价事件也能根据还原机制被处理。出价人视图数据表因此而解耦，但不总是与出价表的 状态保持一致。不过这是我们可以接受的让步，它让出价表和出价视图表之间不必服从ACID要求。

对其它大型系统的架构，你有什么建议吗？

最简单的建议就是，给一个为小规模应用而设计的架构增加资源并不能让它变成大规模的架构。你必须打破常规模式，比如ACID和分布式事务。乐于寻找 机会放松一些约束，即使传统上认为是不能放松的。

还有两条简单的原则：把每样东西都设计成分离的；考虑BASE、而不是ACID。

亚马逊CTO Werner Vogels也在 QCon{#up0m}上{#up0m}发了言{#up0m}， 他通过引用Eric Brewer的CAP定理提供了一些权衡取舍更深层的背景。这个定理曾在2000 年PODC会议上{#fntr}（.pdf文件）进行过介绍，介绍中也包括ACID vs. BASE的内容。它陈述了对于数据共享系统的三项属性——数据一致性、系统可用性、对网络分区的耐受性——在同一时间只能达成其中的两项。换句话说，一个 不能容忍网络分区的系统可以利用像事务这样普通的技术来实现一致性和可用性。然而，像亚马逊和eBay这样的大型分布式系统，网络分区是既定的。它的后果 就是，大型分布式系统的架构必须决定时放松对一致性的要求，还是放松对可用性的要求。两种选择都会给开发人员造成一些负担，他们需要了解他们处理的架构的 特点。比如说，如果你选择放松一致性要求，那么开发人员就要决定怎样处理这种情形——对系统的写入不会立即反映到对应的读出中。就像Windows Live项目经理Dare Obasanjo在他的博 客{#zbq_}中写的一样。

我们在Windows Live平台的某些方面也采用了类似的做法。我也听到了开发人员抱怨一件事情，就是原先能通过事务轻松获得的错误恢复，现在要留给应用开发人员来处理。最 大的苦恼往往是关于回滚复杂的批处理操作。

许多大型网站似乎都殊途同归，得到了同样的结论。观察到这一点是很有意思的。虽然只有几个节点的小型系统尚不需要关注这些形形色色的权衡取舍，但是 eBay和亚马逊正在处理的各种问题可能已经开始在企业系统中出现了，因为这些企业系统的用户规模也正变得越来越大。

查看英文原文：Trading Consistency for Scalability in Distributed Architectures{#mape} 本文出自：

在前一期 山寨交流会 上： 桂 新 说他会将良好的构架和一套完整的监控系统作为两个非常重要的基础来抓，良好的架构一步到位这点很难做到（对于发展速度并不确定的小公司来说，架 构过大也是一个成本上的风险），但对于后者：一套完整监控系统我是非常认同的。对于目前普遍缺乏测试的Web应用开发过程来说，监控几乎就是测试很重要的 一部分；而系统监控本身，也可以帮助及时发现很多问题并量化优化的效果。而系统的扩展和调优的大部分技巧都可以从《构建可扩展的Web站点》(作者是 Flickr的开发者)一书中看到。为了减少不必要的调优（盲目的调优是危害很大的），建议从这2章开始看起： 第8章《瓶颈》发现和第10章《统计数据，检测和报警》；有了这些瓶颈检查结果和统计监测/报警系统后，再有针对性的看其他章节做系统调优。

以下是我在 博客大巴 开 发中的一些实践小结：

1 数据库相关

1.1 系统应用层面出问题我一般都习惯性的先去看数据库群的连接数统计：大部分应用最后的瓶颈都在于单表数据量过大后，数据存取慢导致的并发连接数过多的问题，

1.2 解决这个问题目前的主要策略就是分片( share nothing)，单个数据库连接数超过100，就想办法拆分并用多个daemon提供服务，数据的拆分也降低了单表的数据量；

1.3 对于需要全局访问的数据，通过另外冗余存储一份专门用于全局对比的操作用（会增加数据一致性开发量）；

1.4 slowquery一般是遇到问题才去看的，其实 binlog转换成文本格式后，也可以用 mysqldumpslow 统 计的，slowquery就是执行时间超过一定阈值（缺省是1秒）的binlog，更全面查询统计，则需要打开数据库的query log，binlog其实就是没有只读操作的querylog；

2 日志相关

2.1 对于应用来说：容忍过多的非致命错误容易让错误日志变得非常难读，从而对发现很多致命错误造成麻烦；在各种系统开发间隙，统计各种错误日志也是我非常乐于 去做的一件事儿，从warning faital级的PHP错误信息到404错误日志；报警后的急救车固然重要，日常的体检及时发现潜在风险较高的漏洞或缺陷并修正都会在系统真正发生报警的 时候为成功抢修节约大量时间；

2.2 经常出问题的环节要有错误日志，并且格式设计的比较 便于sort和grep 也 是很重要的一方面；

3 需求削减：

3.1 并非所有用户都需要被满足： 发现spammer 和 盗链者，并设法降低资源 流失的速度；

3.2 通过日志统计发现用户使用较少但对系统负载很高的功能；

此外：一个管理方面问题： 开发过程本身是日志是最少的，怎么解决？

而最近开发人员总很流行的2本书： 《高性能 网站建设指南》 和 《构建可扩展的Web站点》 都 是 博文视点 从O’Reilly引进出版的， O’Reilly 经常请业内专家（指的是有大规模成功实际应用案例的而不 仅仅是科研成果）写书并随系统发展一版再版，博文视点近期也在积极和IT业内很多设计师在联系写书出版的事宜：会看到更多适合目前国内环境特点的开发类书 籍出现；

本文出自： http://www.chedong.com/blog/archives/001422.html

在前不久结束的 QCon 2008 上，MySpace 的首席架构师 Dan Farino 做了题为 Behind the Scenes at MySpace.com (PDF 下载)的技术演讲。

架构概况

超过 4,500 台 Web 服务器，配置为 Windows 2003/IIS 6.0/ASP.NET ；超过 1200 台 Cache 服务器，64 位的 Windows 2003，超过 500 台的数据库服务器，配置为 64 位的 Windows 2003，数据库为 SQL Server 2005 。

之前曾有一篇 揭 秘 MySpace 架构的文章，也有中文版本《 亿万用户网站 MySpace的成功秘密》！

运维数据收集

其实这个演讲我感觉主要讲的是这个数据收集模块 🙂 MySpace 的方案倒是让我们看到了在超大规模的 Windows 环境下如何进行数据收集的。

每个客户端通过一个 TCP 连接到收集上服务器。收集的信息包括：Windows 性能计数器 Performance Counters、 WMI 对象(定制后的 WMI 对象)、事件日志、 硬件数据等等。收集器服务(Agent) 用 C#实现的，完全的异步 I/O，用了微软的 Concurrency and Coordination Runtime 库。每台主机上一个 Agent。其实国内也有超大规模的 Windows 环境 — 比如盛大，数据采集和监控的机制倒是类似的。

从老高的近期工作总结中看到：

目前的技术状况是基于自行设计的 PHP 框架，跑在 PHP 5.2 + MySQL 5.1 下，PHP 使用 Fastcgi 模式，WebServer 选择了 Nginx。搜索功能基于 Lucene 开发。缓存代理使用 Varnish。

对老高进行了一次非正式采访，聊了不少内容，整理了一下和大家分享。(谁是高春辉? 这个不要介绍了吧，请 Google! )

1. 历史情况

Fenng: 原来大约是用什么? 框架用的什么？ 高春辉: 你说老系统？Apache 1.3 , DB 是 MySQL 4.0。新框架是团队自己写的，定制了一些东西吧，主要强调的是性能和方便、简单。另外把针对 YSlow 的优化也做进去了。 Fenng: 单说现在用的框架，大约投入了多少个人/天 ? 高春辉: 从全年开始考虑写，一直不断的写 — 具体时间不好说。反正是不少了 🙂 Fenng: 看了你 Blog 中的描述，有个小疑惑：没使用面向 DB 的 Cache 层? 高春辉: 我文中说的 Data accessor 就算是了。目前是拿 PHP 做的，Client+Server 集成在一起。后面第二期准备拿 Java 来写 Server 端。

2. 遭遇 PHP Bug

Fenng: 你提到的 502 错误不会是 PHP Fastcgi 内存爆了的原因吧？ 高春辉: 不是，是 PHP 和 APC Bug 的问题。换新版就好了，你可以看 PHP 5.2.7 的 Buglist。里面列了一个在 Fastcgi 下父进程不能执行 shutdown module 方法的问题。主要是这个原因。APC 也有问题，它的Lock在大并发下非常容易挂掉。换上还没发布的测试版就好了。现在挺稳定的。一台机器跑了700万次请求了。 Fenng: 你遇到的是这个问题吧? Bug 45423 高春辉: Yes Here is the APC bug link : http://pecl.php.net/bugs/bug.php?id=5280 还附带这个问题。当时发现原因之后，非常郁闷，呵呵。 Fenng: 现在用 5.2.8 了? 高春辉: 嗯。5.2.7/5.2.8 反正没啥区别，就修正了一个bug。 3) DB 压力

基于ID的分片机制实现存储的分布化会遇到一个问题：固定存储空间随着时间增加再次达到系统的空间/负载的瓶颈。观察了一下Flickr的图片存储 地址：好像是在定期启用新的集群，各个时期的域名分布如下：

http://farm1.static.flickr.com 2006年中以前；

http://farm2.static.flickr.com 2006年底；

http://farm3.static.flickr.com 2007年底；

http://farm4.static.flickr.com 2008年底；

《构建可扩展的Web站点》 上 没有提到这个策略，猜测Flickr应该是不断在启用新的服务器集群，当地一个集群用到90%的时候，开始启用下一个集群。一个用户的所有图片地址则存储 在数据库中：记录会包含当时的存储所在的集群：

user_foo – farm1.static……/20060124_003.jpg

\ farm1.static……/20060324_005.jpg

\ farm1.static……/20060824_021.jpg

\ farm2.static……/20070124_006.jpg

\ farm3.static……/20080124_002.jpg

\ farm4.static……/20081124_001.jpg

图片服务的特点就是：不修改，少量新增/极 少删除，存储量大，需要尽量避免迁移和复制；旧的集群锁定后：对于原来的文件基本上就只删不增了；虽然目前有很多开源的分布式文件系统，但是目前比较便宜 的解决方法还是本地硬盘服务器不断一组一组的增加，相互备份的一组服务器作为基础存储，然后前端使用缓存服务器； 通 过LVS或者CDN进行负载/分布的均衡。

另外如果希望前端存储使用的域名一直保持不变，通过目录规则进行rewrite的方式也是可以的，比如：将要发布的内容，后端按时间建立一个域名进 行存储；

200711.foo.example.com

200712.foo.example.com

200801.foo.example.com

…

200811.foo.example.com

而 前端则通过前端目录规则，将请求rewrite访问后台不同的存储服务器上：

foo.example.com/200711/ » 200711.foo.example.com

foo.example.com/200712/ » 200712.foo.example.com

…

foo.example.com/200811/ » 200811.foo.example.com

简单的说：

像存储/发布这样要求稳定对外的服务，服务器扩容必须避免停机将旧文件搬来搬去；而是通过不断的构建新集群的方法，大集群/大空 间最好是扩展，而不是对原存储介质进行增容。

作者 版权声明： 可以任意转载，转载时请务必以超链接形式标明文章 原始出处 和作者信息及 本版权声明。

当Microsoft在PDC2008上携 Azure平台 驾 云而来时，天气预测注定将发生改变。将当前市场上分别来自Amazon、Google和Microsoft的三大主流产品作一比较会是一件非常有意思的事 儿。第一眼看上去的印象是它们彼此之间似乎实际上并不存在真正的相互竞争。

Ziff兄弟投资的副总裁Michael J. Miller 对云计算的三大角逐者进行了比较，这是他关于Amazon EC2的发现：

备受关注的云平台无疑就是Amazon Web服务了，它是多种工具 的集合，大部分都位于相当底层。其中又以Amazon弹性计算云(EC2)最为出众，这一Web服务能你将应用分配给任意多的“计算单元”。简单的说，一 个标准的单一实例包括了一个“虚拟核心”，1.7GB的内存，以及160GB的存储实例（只针对该对话的存储），价格为每小时10美分。在这个服务之上， 你可能会考虑使用该公司提供的“简单存储服务”(S3)，对于前50TB的数据，其价格是每GB每月15美分，之后价格递减，同时要收取一定的交易费用。 同时你也可能考虑使用该公司的“Simple DB”数据库，或者是用于存储消息的队列服务，包括一些附加的收费。

Amazon平台的基本优势很简单：在你需要的时候，仅仅使用你所需要的存储量。

关于Google的App Engine，Michael如是说：

Google的App Engine是新来 者。它仍处在免费的beta阶段，并且其工具集到目前为止仍有一定局限性。具我的理解，如果说Amazon给了你一台可以在其上安装许多软件的虚拟机的 话，Google更应该说是给了你一个基于Python语言，Django框架，Google的BigTalbe数据库/存储系统和Google文件系统 (GFS)的确定环境。目前，开发者可以免费获得500MB的存储，以及最多每月500万页面访问的计算能力，并且该公司对更活跃的站点宣布了收费策略。 举例来说，该公司表示开发者每 CPU核心/小时可能会需要支付10到12美分。

因为其与Google自己的操作环境联系非常紧密，所以对于了解这些框架的开发者而言，起步相对会容易一些。但一些开发者却选择了避开它，因为相比 Amazon的解决方案它显得过于局限了。

当谈到Microsoft的Azure时，Michael证实：

与Amazon Web服务相似，Azure实际上是由一个公共平台上的多种不同服务来组成的。…….NET服务是目前最受关注的部分，因为开发者初始时将用它来为平台作 开发。实际上，从我所参加的会议看来，将一个为.NET框架编写并用Visual Studio开发的应用将会很容易的迁移到“云”上。

Azure的一大不同之处是在于，尽管Microsoft打算提供其自主的Azure托管服务，但该平台同样也是为运行于本地工作站和企业服务器而 设计的。这使得测试应用变得方便，也同样得以支持企业应用既能运行于公司的内部网也能运行于外部环境。

Michael将其比较概括为：

考虑这三个角逐者，你会发现它们每个都发挥着自己的强项。Amazon是市场的先行者，并利用因特网标准与开源平台打造了一个十分灵活的平台。 Google利用了其对于大型数据库的研究成果并借助其内部的开发方法创建了一个强大但略显局限的环境。而Microsoft凭借其在开发者方面的传统强 势与其宽泛的工具集提供了可能是最庞大的一系列服务。随着时间发展，我猜测我们会看到它们会开始互相靠拢－从Amazon引入Windows服务实例就是 一个预示。

道琼斯新闻电报的Jessica Hodgson就Microsoft参与这场游戏所产生的 新财务等式 撰文一篇。她引用Directions研究公司的分析员Matt Rosoff的言论：

我以为Microsoft想要做的是冻结这个市场。他们想让那些打算尝试按需产品的人们停下来，并等着看他们的产品将会如何。

根据Jessica的说法，对于云计算市场的价值有多种不同的意见：

虽然大家都同意云计算正在增长，关于它是否会取代本地授权软件，或是与其结伴同行的意见却各有千秋。Deutsche银行的分析师Tom Ernst表示，软件包模式的市场已达到饱和。不出五年，Ernst估计云计算服务将占据价值600亿美元的应用软件市场的半壁江山。与此相 反，Oracle公司的首席执行官(ORCL)Larry Ellison却嘲笑云计算是“胡言乱语”，并声称没什么公司可从中获益。

Microsoft对于业务模型的承诺将会助长期待，推动那些不愿拥抱云计算的大公司采纳它。位于温哥华的Web开发公司Strangeloop Networks的共同创始人Richard Campbell表示，他的许多客户都在询问云计算，虽然出于对安全和可靠性的考虑很少真正转向它。

Jessica接着分析Microsoft的行动：

Microsoft审慎的前进着，一边小心的保护着其既有的软件包模式特权，一边打量着云计算市场将如何发展。它采纳了一种混合的方式，因为它声称 多数消费者将会继续需要本地授权软件的产品，就是大部分分析师所支持的立场……。

如果Microsoft进展太慢，它将面临让诸如Google以及Amazon等革新者占据市场分额的风险。这些公司不存在Microsoft所面 对的利益两难境地，因为他们没有什么实体的软件特权需要去维护。

“如果它(云计算)成为了主流业务的流行方式，很难看到他们如何去避免去蚕食自己桌面服务的销售，”Nickolas Carr表示，他曾任哈佛商业评论的编辑并出版了一本关于云计算的书。“这将是一场scale的游戏。”

查看英文原文：Comparing Amazon’s EC2, Google’s App Engine and Microsoft’s Azure 本文来自：

前言：

关于Digg的架构，之前 Fenng 已 经写过一篇 Digg 网站架构 的文章，Fenng在文章开头说“越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。”，其实是 Fenng过谦了，我就是从 DBA notes 一点一滴开始学习的。

原文在 Scaling Digg and Other Web Applications， Todd Hoff 总能给我们带来一些有意思的文章。这里既不直译也不全译，保持原文骨干加上肤浅的理解。

Digg用户在3000W左右，网站每秒请求数达到13000个，规模算是很大了，Lamp（Linux+Apache+MySQL+PHP）结 构，Web2.0网站中钟情PHP的不少，国外的Facebook、Digg、Flickr…，国内的新浪博客、开心网、51.com等等，扩展的不是编程语言而是网站架构，因为编程语言从来都不会是网站瓶颈，每种语言都有自己适合做和不适合做的事情。喜欢比较语言快慢的可以看看 http://shootout.alioth.debian.org/， 看看而已不要用速度去衡量编程语言的优劣。

Digg的扩展战略：

• 扩展是有特殊性的，当已有的方案不能满足需求时，你需要根据自己的特殊需求来建立方案。要熟悉自己的业务需求，找出系统的短板，解决问 题，避免过度优化。
• 编程语言不需要扩展，因为语言从来都不是瓶颈，把PHP提速300％不会是什么大问题。
• 去中心化，分布式处理高并发请求。
• 水平扩展，用更多更便宜的机器代替更高效更昂贵的机器。
• 数据库驱动的网站需要作水平分区和垂直分区扩展，水平分区就是把数据放到不同的机器上，比如按照时间划分：2009年的数据一组服务 器，2009年的数据一组服务器，或者按照用户ID划分：每200W用户一组服务器；垂直分区把一个表分成多个表，每个表只包含一部分字段，可以按照业务分或者常用的“动静分离”，比如对文章计数的字段大可以和文章内容字段分开。
• 建立数据应用层，程序不要直接操作数据库分区，这样可以保持好的扩展性。这一点非常重要，如果没有数据应用层API，一旦对数据库分区做了修改，你的程序就需要大改了。程序的稳定性和持续性就不能保证。比较常见的MVC开发模式，数据层和逻辑层分开，一旦数据库底层改变了，只需要对数据层做简单的修改，不影响既有业务。
• 一致性、高可用性、分区容忍性（Partition Tolerance）三者只能取其二，具体的阅读 http://camelcase.blogspot.com/2007/08/cap-theorem.html， 一致性：每个人看到的都一样，哪怕当时就有更新；高可用性：部分故障不影响使用；分区容忍性：数据分区还能保持系统所有属性。
• 数据分区要求反常规化，这是在Digg是大问题，同样的数据要复制到多个对象上去，而且还好保持同步。
• 采用异步的队列架构，把任务放到队列中交由多台机器处理，而不是一次同步处理，关于异步任务处理可以阅读 Flickr – Do the Essential Work Up-front and Queue the Rest和The Canonical Cloud Architecture
• icons和图片采用 MogileFS 存储，MogileFS是一个分布式的文件系 统，由memcached作者开发，国内的 好看簿 也有使用MogileFS。
• 采用 APC 作为PHP加 速器，Facebook用的也是这个，PHP5.30以后将自带APC加速器，同样的产品还有 eAccelerator 和 Xcache，国内可能用eAccelerator的比较 多，windows的版本我一般用 这 个网站 编译的。
• 缓存策略：永久性缓存和失效期缓存；基本不更新的内容采用文件缓存；动态缓存采用memcached；极少修改的数据采用APC缓 ，APC不是分布式缓存，直接缓存的机器内存中，所以速度更快，适合缓存那些配置文件，比如MySQL的配置信息；缓存采用链责任模式，首先看PHP全局变量，如果没有就查APC，再没有就查memcached，最后没有就查数据库，这个觉得不太必要，你的缓存存在哪来你自己还不清楚阿。
• Digg的推荐引擎是一个自定义的图形数据库，数据库最终保证一致性，先写如一个分区，然后再逐步写到其他的分区。在更新的过程中，可能取出来的数据不一致，是因为有不同的数据库分区处理，最终将会是一致。

MemcacheDB：性能革命性的一步

想象一下Kevin Rose，Digg的创建者，当前有4000个追随者，如果Kevin Rose一天digg一次，将会有4000个写操作，最热门的digg有最多的追随者，这会导致巨大的性能瓶颈：

• 你不能同时更新4000个追随者的帐号信息，幸运的是我们可以通过前面提到的异步队列方式解决。
• Digg面临的海量写操作，如果平均每个人有100个追随者，一天就有3亿条写操作，平均到每秒有3000个写操作，每天有5GB的数据存储，在50～60台服务器之间有5TB的数据交换。

如果是MySQL的话估计早就挂了，Digg在笔记本上的测试是memcachedb每秒可以处理15000个写操作，memcachedb的 测试结果 表明每秒可以支持23000个写操作或者64000个读操作，足以应付Digg洪水般的请求。

memcachedb 是一个分布式 的kye-value型数据持久化解决方案，提供兼容memcached协议接口，由Sina工程师 Steve Chu 开发。

本篇描述一下 Digg 的网站架构.

国庆期间又收集了一些关于网站架构的信息。一直没有进行系统的整理。越来越发现其实都是自我重复的劳动，后续的信息都是嚼别人剩下的甘蔗。--by Fenng

Digg 工程师采用 LAMP (Linux, Apache, MySQL and PHP) 模式。这个 Alexa 排名在 100 左右的、自我估价 1.5 亿美金的站点目前有超过 100 台的 PC 服务器(足够少了)，可以粗略分成三个部分：数据库服务器，Web 服务器，搜索服务器。

数据库方面，和其他成功的 Web 2.0 站点一样，也是 MySQL，不过 Digg 稍微”激进”一点，用 MySQL 5，而且号称从 MySQL 4 升级到 5 性能没有什么影响。 OLTP 应用用 InnoDB 引擎, OLAP 用 MyISAM。后端数据库的读比例达到 98%，写只有 2%，实际的读写比例应该高于这个数字，这应该是 Digg 在前端用 Memcached 以及 APC PHP accelerator / MCache 做缓存后的效果。在 IO 上似乎压力并不大。

数据库分割用 Sharding (分片)的机制。从透露出来的信息看，Digg 数据量并不大，仅仅刚超 30g . 看起来是只存储了一些元数据。至于这个 Sharding 或者 Shard, 其出发点有些类似于数据库的分区，差别可能就是不再一个库上吧，其实都是结合业务和应用来对一些数据对象进行分割。

搜索服务器用的是 Lucene。

进一步阅读：

• Digg Architecture
• How Digg.com uses the LAMP stack to scale upward
• Digg PHP’s Scalability and Performance

–EOF–