June 27, 2010
图解”How MySQL Replication Works”
"\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2010/06/3455232156_dc09e11b22_o.jpg\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/3455232156_dc09e11b22_o.jpg\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://www.flickr.com/photos/26825745@N06/3455232156/\" title=\"replication by orczhou, on Flickr\"\u003ereplication by orczhou, on Flickr\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e在使用MySQL的应用中,如果你的MySQL Server压力逐渐增大,在应用层优化已经到了一定瓶颈时,那么你应该首先考虑 \u003ca href=\"http://dev.mysql.com/doc/refman/5.0/en/replication.html\"\u003eMySQL Replication\u003c/a\u003e。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e如何同步\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e主库将所有的更新操作,写入二进制日志。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e从库运行”IO线程”(Slave IO Thread)读取主库的二进制日志。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e从库运行”SQL线程”(Slave SQL Thread)执行IO线程(Slave IO Thread)读取的日志中的SQL,从而保持和主库的一致。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e\u003cstrong\u003e如何分配请求\u003c/strong\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e目前,这部分需要在应用层实现。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e执行更新SQL(UPDATE,INSERT,DELETE)时,请求主库。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e执行查询SQL(SELECT)时,请求从库。\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e所以,当你的应用(Application)SELECT请求所占的比率越大,那么Relication就会越有效。\u003c/p\u003e"
June 27, 2010
关于MySQL explain 中的ID(推荐)
"\u003cp\u003e\u003cstrong\u003eExplain ID详解\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e含义:select查询的序列号,是一组数字,表示的是查询中执行select子句或者是操作表的顺序。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eid的情况有三种,分别是:\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eid相同表示加载表的顺序是从上到下。\u003c/li\u003e\n\u003cli\u003eid不同id值越大,优先级越高,越先被执行。\u003c/li\u003e\n\u003cli\u003eid有相同,也有不同,同时存在。id相同的可以认为是一组,从上往下顺序执行;在所有的组中,id的值越大,优先级越高,越先执行。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e再看一个查询计划的例子:\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://blog.haohtml.com/wp-content/uploads/2010/06/mysql_explain.png\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/mysql_explain.png\" alt=\"\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e执行顺序依次为 4 -\u0026gt; 3 -\u0026gt; 2 \u0026gt; 1 \u0026gt; NULL\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e第一行:id列为1,表示第一个select,select_type列的primary表示该查询为外层查询,table列被标记为,表示查询结果来自一个衍生表,其中3代表该查询衍生自第三个select查询,即id为3的select。[select d1.name……]\u003c/p\u003e\n\u003cp\u003e第二行:id为3,表示该查询的执行次序为2(4→3),是整个查询中第三个select的一部分。因查询包含在from中,所以为derived。[select id,name from t1 where other_column=”]\u003c/p\u003e\n\u003cp\u003e第三 …\u003c/p\u003e"
June 26, 2010
LVS & MySQL NDB Cluster
"\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"
June 26, 2010
mysqldump意外终止的原因以及解决方法
"\u003cp\u003emysqldump是非常重要的MySQL备份工具。然而在长年累月的使用过程中,TAOBAO多次出现了因mysqldump意外终止而导致备份 失败的情况。\n以下是我们经常遇到的问题:\u003c/p\u003e\n\u003cp\u003e1、Lost connection to MySQL server at ‘reading initial communication packet’:\n这个主要是因为DNS不稳定导致的。如果做了网络隔离,MySQL处于一个相对安全的网络环境,那么开启skip-name-resolve选项将会最大 程度避免这个问题。\u003c/p\u003e\n\u003cp\u003e2、Lost connection to MySQL server at ‘reading authorization packet’:\n从MySQL获取一个可用的连接是多次握手的结果。在多次握手的过程中,网络波动会导致握手失败。增加connect_timeout可以解决这个问题; 然而增加connect_timeout并不能防止网络故障的发生,反而会引起MySQL线程占用。最好的解决办法是让mysqldump重新发起连接请 求。\u003c/p\u003e\n\u003cp\u003e3、Lost connection to MySQL …\u003c/p\u003e"
June 26, 2010
MySQL Timeout解析
"\u003cp\u003e\u003cstrong\u003e“And God said, Let there be network: and there was timeout”\u003c/strong\u003e\n在使用MySQL的过程中,你是否遇到了众多让人百思不得其解的Timeout?\n那么这些Timeout之后,到底是代码问题,还是不为人知的匠心独具?\n本期Out-man,讲述咱们MySQL DBA自己的Timeout。\u003c/p\u003e\n\u003cp\u003e先看一下比较常见的Timeout参数和相关解释:\n\u003cstrong\u003econnect_timeout\u003c/strong\u003e\nThe number of seconds that the mysqld server waits for a connect packet before responding with Bad handshake.\n\u003cstrong\u003einteractive_timeout\u003c/strong\u003e\nThe number of seconds the server waits for activity on an interactive connection before closing it.\n\u003cstrong\u003ewait_timeout\u003c/strong\u003e\nThe number of seconds the server waits for …\u003c/p\u003e"
June 26, 2010
分布式之后的变化
"\u003cp\u003e在经历了2009年的分布式启步之后,经过改造的数据库系统性能得到极大的提升,但这个变化仍然不构成今天这篇文章的主题,我想要说的是另外一方面的变 化,这个变化在某种程度上影响着当前DBA的角色变化问题。\u003c/p\u003e\n\u003cp\u003e在分布式数据库时代,开发DBA的开发支持工作相比于以前,会有更多的系统思考问题的机会,会结合应用来设计量身定做的分布式数据库系统,如果一个DBA 对业务有着深刻的理解,深刻理解数据库原理,既具有整体性的架构思维,又有一些关键细节把握能力的时候,设计一套分布式系统是水到渠成的事。对于开发支持 的一些工作,比如SQL审核,表结构变更,数据订正,历史迁移,如果没有工具的支持,那做起来还是比较吃力的。这些方面,我们还有许多的道路要走,怎么样 改变目前的现状。\u003c/p\u003e\n\u003cp\u003e在分布式数据库时代,系统DBA的运维要求难度在某方面有所降低,整个应用因为在容错性方面做了比较多的努力,比如down掉一个数据库时,对于整个应用 系统的健康运行影响较小,运维的压力相对减少。相比于集中式的数据库环境下的运维,在另外一个层面运维难度又有所增加,第一,运维的机器数量呈几何指数的 增长,由于大量采用低端机器,集群中某个机器出问题的 …\u003c/p\u003e"
June 26, 2010
框架设计规范的新方向
"\u003cp\u003e微软的\u003ca href=\"http://msdn.microsoft.com/en-us/library/ms229042.aspx\" title=\"框架设计规范\"\u003e框架设计规范\u003c/a\u003e{#h.u8}是 设计的准则,它期望所有的微软类库和独立开发者都能够遵循这一准则。随着每个.NET框架版本的发布,以及在行业内的测试,它们的版本也得到了精化。通过 Cwalina与Abram所著的\u003ca href=\"http://blogs.msdn.com/brada/archive/2008/10/14/framework-design-guidelines-2nd-edition-order-yours-now.aspx\" title=\"《框架设计规范》第二版\"\u003e《框 架设计规范》第二版\u003c/a\u003e{#t.q.}的发布,我们可以看到微软在今后几年的发展方向。\u003c/p\u003e\n\u003cp\u003e或许最令人惊讶的事实是日渐增长的对于测试驱动开发和依赖注入的重视。在可重用框架的场景下,通过测试驱动开发设计出的框架是真实可用的,而不是简 单地推理。他们希望这样可以反过来杜绝某种趋势,那就是过度复杂地设计一些根本不会用到的功能。\u003c/p\u003e\n\u003cp\u003e谈到这一问题,就不得不指出的是微软当前正在推动的一个活动,即针对所有库的第1个版本进行最低限度设计。这不同于在第一次就要试图将所有事情做 对,微软推荐在最开始只需要满足需求中绝对需要的特性。Abrams和Cwalina建议在最初并不需要考虑扩展性,只有到需求变得非常清晰的时候,才在 后一个版本中考虑。从某个方面来讲,这是微软旧有传统的回归,它只会在第三个版本中提供真正完成的应用程序。\u003c/p\u003e\n\u003cp\u003e在其它领域,微软则完全没有改变。他们仍然强调所谓的“基坑成功(Pit of …\u003c/p\u003e"
June 26, 2010
牺牲一致性来换取分布式架构的可伸缩性
"\u003cp\u003e统架构师角色关键的一方面就是衡量相互冲突的需求、决定解决方案,常常要牺牲一个方面来换取另一个方面。随着系统变得越来越大、越来越复杂,越来越多关于 如何构建应用的传统智慧正在受到挑战。比如说,去年3月在伦敦召开的QCon会议上,Dan Pritchard谈论了eBay的架构。他的介绍随后得到了很多的报道,其中一个主要的结论就是eBay不使用事务,用数据一致性上的损失来换取系统整 体伸缩性和性能上相当大的改进。\u003c/p\u003e\n\u003cp\u003eInfoQ接着Dan Pritchard在QCon会议上的谈话与他继续讨论,以获得更多信息:\u003c/p\u003e\n\u003cp\u003e为什么eBay不使用事务,或者为什么可以决定不采取应用级事务?\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e我们并非一概不使用事务。我们只是不使用跨物理资源的事务,因为它会造成多个组件之间出现依赖。组件可以是应用服务器和数据库。(例如在客户端控制 的事务中,)一个客户端的失败会长久地阻塞数据库资源、超出我们的忍受程度。我们也不使用分布式事务,因为让应用依赖于多个数据库会降低客户端实际的可用 性。相反,我们选择缺少事务的设计,并加入失效模式,失效模式可以使客户端甚至在发生数据库可用性问题的时候也能继续进行。\u003c/p\u003e\n\u003cp\u003e应用级事务总是有些问题。 …\u003c/p\u003e\u003c/blockquote\u003e"
June 26, 2010
推荐《构建可扩展的Web站点》- 基于监控的系统调优
"\u003cp\u003e在前一期 \u003ca href=\"http://www.chedong.com/blog/archives/001447.html\"\u003e山寨交流会\u003c/a\u003e 上: \u003ca href=\"http://home.51.com/diary.view.php?user=gusingchen\u0026amp;id=10038668\"\u003e桂 新\u003c/a\u003e 说他会将良好的构架和一套完整的监控系统作为两个非常重要的基础来抓,良好的架构一步到位这点很难做到(对于发展速度并不确定的小公司来说,架 构过大也是一个成本上的风险),但对于后者:一套完整监控系统我是非常认同的。对于目前普遍缺乏测试的Web应用开发过程来说,监控几乎就是测试很重要的 一部分;而系统监控本身,也可以帮助及时发现很多问题并量化优化的效果。而系统的扩展和调优的大部分技巧都可以从《构建可扩展的Web站点》(作者是 Flickr的开发者)一书中看到。为了减少不必要的调优(盲目的调优是危害很大的),建议从这2章开始看起: 第8章《瓶颈》发现和第10章《统计数据,检测和报警》;有了这些瓶颈检查结果和统计监测/报警系统后,再有针对性的看其他章节做系统调优。\u003c/p\u003e\n\u003cp\u003e以下是我在 \u003ca href=\"http://chedong.blogbus.com/logs/29595744.html\"\u003e博客大巴\u003c/a\u003e 开 发中的一些实践小结:\u003c/p\u003e\n\u003cp\u003e1 数据库相关\u003c/p\u003e\n\u003cp\u003e1.1 系统应用层面出问题我一般都习惯性的先去看数据库群的连接数统计:大部分应用最后的瓶颈都在于单表数据量过大后,数据存取慢导致的并发连接数过多的问题,\u003c/p\u003e\n\u003cp\u003e1.2 解决这个问题目前的主要策略就是分片( \u003ca href=\"http://www.dbanotes.net/database/database_sharding.html\"\u003eshare nothing\u003c/a\u003e),单个数 …\u003c/p\u003e"
June 26, 2010
MySpace 系统架构
"\u003cp\u003e在前不久结束的 \u003ca href=\"http://qconsf.com/\"\u003eQCon 2008\u003c/a\u003e 上,MySpace 的首席架构师 \u003ca href=\"http://jaoo.dk/london-2008/speaker/Dan+Farino\"\u003eDan Farino\u003c/a\u003e 做了题为 \u003ca href=\"http://qconsf.com/sf2008/file?path=/qcon-sanfran-2008/slides//DanFarino_Myspace.pdf\"\u003eBehind the Scenes at MySpace.com\u003c/a\u003e (PDF 下载)的技术演讲。\u003c/p\u003e\n\u003ch4 id=\"架构概况\"\u003e架构概况\u003c/h4\u003e\n\u003cp\u003e超过 4,500 台 Web 服务器,配置为 Windows 2003/IIS 6.0/ASP.NET ;超过 1200 台 Cache 服务器,64 位的 Windows 2003,超过 500 台的数据库服务器,配置为 64 位的 Windows 2003,数据库为 SQL Server 2005 。\u003c/p\u003e\n\u003cp\u003e之前曾有一篇 \u003ca href=\"http://www.baselinemag.com/c/a/Projects-Networks-and-Storage/Inside-MySpacecom/\"\u003e揭 秘 MySpace 架构\u003c/a\u003e的文章,也有中文版本《 \u003ca href=\"http://www.kuqin.com/system-analysis/20071230/3238.html\"\u003e亿万用户网站 MySpace的成功秘密\u003c/a\u003e》!\u003c/p\u003e\n\u003ch4 id=\"运维数据收集\"\u003e运维数据收集\u003c/h4\u003e\n\u003cp\u003e其实这个演讲我感觉主要讲的是这个数据收集模块 🙂 MySpace 的方案倒是让我们看到了在超大规模的 Windows 环境下如何进行数据收集的。\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://blog.haohtml.com/wp-content/uploads/2010/06/1626170.png\"\u003e\u003cimg src=\"https://blogstatic.haohtml.com//uploads/2023/09/1626170.png\" alt=\"myspace系统架构\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e每个客户端通过一个 TCP 连接到收集上服务器。收集的信息包括:Windows 性能计数器 Performance Counters、 WMI 对象(定制后的 WMI 对象)、事件日志、 硬件数据等等。收集器服 …\u003c/p\u003e"
June 26, 2010
手机之家网站架构–对话高春辉
"\u003cp\u003e从老高的近期工作总结中看到:\u003c/p\u003e\n\u003cp\u003e目前的技术状况是基于自行设计的 PHP 框架,跑在 PHP 5.2 + MySQL 5.1 下,PHP 使用 Fastcgi 模式,WebServer 选择了 Nginx。搜索功能基于 Lucene 开发。缓存代理使用 Varnish。\u003c/p\u003e\n\u003cp\u003e对老高进行了一次非正式采访,聊了不少内容,整理了一下和大家分享。(谁是高春辉? 这个不要介绍了吧,请 Google! )\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e历史情况\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eFenng: 原来大约是用什么? 框架用的什么?\n高春辉: 你说老系统?Apache 1.3 , DB 是 MySQL 4.0。新框架是团队自己写的,定制了一些东西吧,主要强调的是性能和方便、简单。另外把针对 YSlow 的优化也做进去了。\nFenng: 单说现在用的框架,大约投入了多少个人/天 ?\n高春辉: 从全年开始考虑写,一直不断的写 — 具体时间不好说。反正是不少了 🙂\nFenng: 看了你 Blog 中的描述,有个小疑惑:没使用面向 DB 的 Cache 层?\n高春辉: 我文中说的 Data accessor 就算是了。目前是拿 PHP 做的,Client+Server 集成在一 …\u003c/p\u003e"
June 26, 2010
图片存储:按时间增加新域名进行扩容的办法
"\u003cp\u003e基于ID的分片机制实现存储的分布化会遇到一个问题:固定存储空间随着时间增加再次达到系统的空间/负载的瓶颈。观察了一下Flickr的图片存储 地址:好像是在定期启用新的集群,各个时期的域名分布如下:\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003ca href=\"http://farm1.static.flickr.com\"\u003ehttp://farm1.static.flickr.com\u003c/a\u003e 2006年中以前;\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://farm2.static.flickr.com\"\u003ehttp://farm2.static.flickr.com\u003c/a\u003e 2006年底;\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://farm3.static.flickr.com\"\u003ehttp://farm3.static.flickr.com\u003c/a\u003e 2007年底;\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"http://farm4.static.flickr.com\"\u003ehttp://farm4.static.flickr.com\u003c/a\u003e 2008年底;\u003c/p\u003e\u003c/blockquote\u003e\n\u003cp\u003e\u003ca href=\"http://www.kuqin.com/shuping/20081003/20540.html\"\u003e《构建可扩展的Web站点》\u003c/a\u003e 上 没有提到这个策略,猜测Flickr应该是不断在启用新的服务器集群,当地一个集群用到90%的时候,开始启用下一个集群。一个用户的所有图片地址则存储 在数据库中:记录会包含当时的存储所在的集群:\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003euser_foo – farm1.static……/20060124_003.jpg\u003c/p\u003e\n\u003cp\u003e\\ farm1.static……/20060324_005.jpg\u003c/p\u003e\n\u003cp\u003e\\ farm1.static……/20060824_021.jpg\u003c/p\u003e\n\u003cp\u003e\\ …\u003c/p\u003e\u003c/blockquote\u003e"
June 26, 2010
Amazon EC2,Google App Engine,Microsoft Azure大比拼
"\u003cp\u003e当Microsoft在PDC2008上携 \u003ca href=\"http://www.kuqin.com/system-analysis/20081030/25061.html\"\u003eAzure平台\u003c/a\u003e 驾 云而来时,天气预测注定将发生改变。将当前市场上分别来自Amazon、Google和Microsoft的三大主流产品作一比较会是一件非常有意思的事 儿。第一眼看上去的印象是它们彼此之间似乎实际上并不存在真正的相互竞争。\u003c/p\u003e\n\u003cp\u003eZiff兄弟投资的副总裁Michael J. Miller \u003ca href=\"http://blogs.pcmag.com/miller/2008/11/cloud_thinking_amazon_microsof.php\"\u003e对云计算的三大角逐者进行了比较\u003c/a\u003e,这是他关于Amazon EC2的发现:\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e备受关注的云平台无疑就是\u003ca href=\"http://aws.amazon.com/\"\u003eAmazon Web服务\u003c/a\u003e了,它是多种工具 的集合,大部分都位于相当底层。其中又以Amazon弹性计算云(EC2)最为出众,这一Web服务能你将应用分配给任意多的“计算单元”。简单的说,一 个标准的单一实例包括了一个“虚拟核心”,1.7GB的内存,以及160GB的存储实例(只针对该对话的存储),价格为每小时10美分。在这个服务之上, 你可能会考虑使用该公司提供的“简单存储服务”(S3),对于前50TB的数据,其价格是每GB每月15美分,之后价格递减,同时要收取一定的交易费用。 同时你也可能考虑使用该公司的“Simple DB”数据库,或者是用于存储消息的队列 …\u003c/p\u003e\u003c/blockquote\u003e"
June 26, 2010
扩展Digg和其他的网络应用
"\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"
June 26, 2010
Digg 网站架构
"\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"