"“And God said, Let there be network: and there was timeout” 在使用MySQL的过程中，你是否遇到了众多让人百思不得其解的Timeout？ 那么这些Timeout之后，到底是代码问题，还是不为人知的匠心独具？ 本期Out-man，讲述咱们MySQL DBA自己的Timeout。\n先看一下比较常见的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 …"

"在经历了2009年的分布式启步之后，经过改造的数据库系统性能得到极大的提升，但这个变化仍然不构成今天这篇文章的主题，我想要说的是另外一方面的变 化，这个变化在某种程度上影响着当前DBA的角色变化问题。\n在分布式数据库时代，开发DBA的开发支持工作相比于以前，会有更多的系统思考问题的机会，会结合应用来设计量身定做的分布式数据库系统，如果一个DBA 对业务有着深刻的理解，深刻理解数据库原理，既具有整体性的架构思维，又有一些关键细节把握能力的时候，设计一套分布式系统是水到渠成的事。对于开发支持 的一些工作，比如SQL审核，表结构变更，数据订正，历史迁移，如果没有工具的支持，那做起来还是比较吃力的。这些方面，我们还有许多的道路要走，怎么样 改变目前的现状。\n在分布式数据库时代，系统DBA的运维要求难度在某方面有所降低，整个应用因为在容错性方面做了比较多的努力，比如down掉一个数据库时，对于整个应用 系统的健康运行影响较小,运维的压力相对减少。相比于集中式的数据库环境下的运维，在另外一个层面运维难度又有所增加，第一，运维的机器数量呈几何指数的 增长，由于大量采用低端机器，集群中某个机器出问题的 …"

"微软的框架设计规范{#h.u8}是 设计的准则，它期望所有的微软类库和独立开发者都能够遵循这一准则。随着每个.NET框架版本的发布，以及在行业内的测试，它们的版本也得到了精化。通过 Cwalina与Abram所著的《框 架设计规范》第二版{#t.q.}的发布，我们可以看到微软在今后几年的发展方向。\n或许最令人惊讶的事实是日渐增长的对于测试驱动开发和依赖注入的重视。在可重用框架的场景下，通过测试驱动开发设计出的框架是真实可用的，而不是简 单地推理。他们希望这样可以反过来杜绝某种趋势，那就是过度复杂地设计一些根本不会用到的功能。\n谈到这一问题，就不得不指出的是微软当前正在推动的一个活动，即针对所有库的第1个版本进行最低限度设计。这不同于在第一次就要试图将所有事情做 对，微软推荐在最开始只需要满足需求中绝对需要的特性。Abrams和Cwalina建议在最初并不需要考虑扩展性，只有到需求变得非常清晰的时候，才在 后一个版本中考虑。从某个方面来讲，这是微软旧有传统的回归，它只会在第三个版本中提供真正完成的应用程序。\n在其它领域，微软则完全没有改变。他们仍然强调所谓的“基坑成功（Pit of …"

"统架构师角色关键的一方面就是衡量相互冲突的需求、决定解决方案，常常要牺牲一个方面来换取另一个方面。随着系统变得越来越大、越来越复杂，越来越多关于 如何构建应用的传统智慧正在受到挑战。比如说，去年3月在伦敦召开的QCon会议上，Dan Pritchard谈论了eBay的架构。他的介绍随后得到了很多的报道，其中一个主要的结论就是eBay不使用事务，用数据一致性上的损失来换取系统整 体伸缩性和性能上相当大的改进。\nInfoQ接着Dan Pritchard在QCon会议上的谈话与他继续讨论，以获得更多信息：\n为什么eBay不使用事务，或者为什么可以决定不采取应用级事务？\n我们并非一概不使用事务。我们只是不使用跨物理资源的事务，因为它会造成多个组件之间出现依赖。组件可以是应用服务器和数据库。（例如在客户端控制 的事务中，）一个客户端的失败会长久地阻塞数据库资源、超出我们的忍受程度。我们也不使用分布式事务，因为让应用依赖于多个数据库会降低客户端实际的可用 性。相反，我们选择缺少事务的设计，并加入失效模式，失效模式可以使客户端甚至在发生数据库可用性问题的时候也能继续进行。\n应用级事务总是有些问题。只 …"

"在前一期 山寨交流会 上： 桂 新 说他会将良好的构架和一套完整的监控系统作为两个非常重要的基础来抓，良好的架构一步到位这点很难做到（对于发展速度并不确定的小公司来说，架 构过大也是一个成本上的风险），但对于后者：一套完整监控系统我是非常认同的。对于目前普遍缺乏测试的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扩展 …"