书接上文。视频请访问 InfoQ。

InfoQ中文站: 在 Web 2.0的时代，海量数据对于越来越多的开发者来说，已经不再是一个遥不可及的话题了，可能随便哪一个访问量很大的Web2.0网站都有可能拥有令人咂舌的数据量，那么对于这种网站，除了对数据库存储进行优化，除了缓存，然后还有那些策略？

Fenng: 我觉得可能主要是在存储方面会有一些大的挑战。比如存储的可靠性，像以前就有过 BSP服务商对客户的数据居然没有备份，导致了很多用户损失了一段时间之内的数据，这样总体来说对网站的声誉有很大影响、对用户的体验也很糟糕。

随着互联网的飞速发展，数据总体来说是趋于膨胀性的，在这个过程中，如何把数据有效的存储，并且有效的获取，便是个比较复杂的问题。我们前面说了太多 Web 2.0相关的话题，【换个角度】比如说我所在的公司支付宝，也面临着这样的大数据量、海量数据的挑战。当前我们的一个策略，也是沿袭 SOA 的战略化思想，就是数据库相关的数据服务进行一定的 SOA 化处理。另外一个比较重要的策略就是数据生命周期的管理，我们对这样的，在数据生命周期已经完成后，会对相关的数据做一些归档化的处理，再进行二级存储或者分级存储。那么话说回来，对一些 Web 2.0 网站，我觉得也可以运用这样的思想机制: 对用户已经不大可能访问或者访问频率比较低的（数据），采用分级存储，或者额外做一些访问策略的制订，是很有必要的。

InfoQ中文站: 我们也听说过另外一种分片数据库机制，那么请你谈谈分片这种策略是怎么样一种策略？

Fenng: 分片总的来说，它不是一种比较新的技术， MySQL 在 5 .x 版本之后，有了分区功能。那么在这之前，MySQL 是没有分区功能的。当时如果需要处理一些比较大的数据量，比方说要对根据时间对数据进行历史化处理，就会比较麻烦。人们可能是因地制宜，就产生 Sharding 这样技术策略。

严格来说，数据分片其实在我们以前也有一些相关的实践，在其他(类型)的数据库上，我们也会有一些历史策略，只是当时这个名词没有完全定义下来。据我所知，这个词是从大型在线游戏中发展出来的。大部分用户会集中在某个区域。这一部分集中在某个区域的用户，会把他们放在特定的服务器上。不同区域之间的用户之间的关联度可能不大，这个场景和我们现在的数据库分片策略其实是非常非常相似的，我们当前如果对数据库做一些分片，也会采用这样的基本思想，比如说根据不同的用户 ID 范围，或者说不同的地区(来分片)。

如果建的是商务网站，可能根据产品的类型来做，我们会把不同产品类型的数据扔到不同的 DB上，这些 DB 之间的关联度是很小的。然后我们在 DB 之间，可能会有一个封装层，在这个封装层之上，对应用程序用户来说，就像是透明的，那么就达到了我们数据库上高度扩展化的目标。

InfoQ中文站: 那分片这种策略有什么利弊吗？

Fenng: 首先，分片的好处还是很容易看到的。起码我们的 DB 能达到不依赖于某个单点，而这样能做到平滑的扩展，就像大家常说的 Scale Out (横向扩展)机制。它的弊端也是比较明显，对于事务高速处理这样的网站，它有它的自己的不足之处，事实上好多朋友也应该知道，一个事务如果跨数据库，这样对设计者，对编码人员来说，还是比较棘手的。那么如果一个事务如果跨两个甚至多个 DB，Sharding 复杂度就会很高。Sharding 在业界的应用场景基本上也就是这种读应用比较重的情况，而且对事务的安全性要求不高，这样的场景会非常适合。

【上个月写了篇 Sharding 的东西给《程序员》，还不知道什么时候发表出来】

InfoQ中文站: 目前在许多网站的架构设计中有绝大多数的项目在持久化方面就是采用数据关系映射（ORM）的方式。大家对于这种高负载的大规模网站应用来说，你觉得存在哪些应用呢？

Fenng: 首先一点，我想拿我们支付宝来说，ORM 大家觉得用得非常好。在一个相对比较大的开发环境，对开发团队来说，它的弊端可能就不大容易看出来。因为我们用的是 ORM，就很容易把中间 DB 这层完全隔离出来。然后把这一层的 SQL 处理交给专门的 DB 人员----我们这边还有专门的开发DBA，由他们来专门对这层进行集中的监控管理，乃至一些规划类的工作。这样开发工程师还有架构师这边，他们可以集中精力在其他方面做更多的投入，一个比较大的团队中我觉得像 ORM 这些还是很容易能看到好处的。

【ORM 还有个比较好的地方在于安全性，能有效减少 SQL 注入的隐患】

在另一方面，我们看一下它的弊端，因为像一些 Web 中小网站，可能相对人手也比较少，大家 用的(开发)工具(或框架)呢，可能像 PHP、 ROR 这些东西，也就是在开发上，上手又比较容易的。那么这个时候，事实上一个潜在的问题是，当代码规模到一定程度，如果没有去做一些 ORM，那么可能会给网站带来一些潜在的比如说代码管理上的问题，这一点只是我的个人看法，实际上大家在具体的应用场景可能会有各自头疼的问题，我在这方面不是专家，也仅供大家参考。

InfoQ中文站: 那你所做的支付宝，其实是企业级别的应用，在企业级别应用所采用的这种架构策略和一般 Web 2.0 网站所采用的这种架构策略会有什么异同？

Fenng: 事实上，很明显的一点，支付宝其实业务是非常复杂的【也有一部分人误解支付宝业务很简单】，这和我们很多的Web2.0公司不大一样，Web2.0它可能从一个点切入进去。在这一点上，我觉得做得比较透。支付宝呢，它可能有点像我们以前做的一些通用软件，他要考虑不同的行业、不同的用户、还有像买卖之间，与这么多银行之间的关系等等，这个复杂度还是很大的。

这实际上就从一定程度上决定了我们和 Web 2.0 公司截然不同的应用解决方案，像当前我们在支付宝，在一年之前，甚至两年之前就已经考虑，把我们的整个网站 SOA 化、组件化。在这个过程中，也考虑了一些像 Web 2.0 中的技术元素，但总体的思路呢，还是说向SOA 化，向面向服务这方面大步的跨进，然后就从 SOA 这一点，事实上很多 Web 2.0 公司，他们未必能完全的实现，完全的做到这样的面向服务化，我觉得这可能是两者截然不同的一个表面特点。

另外，像支付宝也在尝试做一些，对外部客户、服务提供一些接口，甚至完全开放的一个平台，这一点又和我们当前这些像 FaceBook ，或者是说，像美国的 MySpace 这样的社交区、SNS 网络了有一些共通之处。

InfoQ中文站: 那目前在 Web 2.0 网站这个领域里面，网站的架构主要有哪些趋势，下边还将有怎么样一个走向呢？

Fenng: 其实作为一个技术人员，每当要谈到趋势，肯定要给大家笑。从中长期来看，国内的一些 Web 2.0 新服务逐渐涌现出来了，随着发展，我相信会有更多的商业化元素加进来。像以前是好多 Web 2.0 公司是完全使用开源的技术，伴随规模扩大化，一些以前提供开源技术的组织或个人他们会尝试进行一些商业化的运作。商业化并不是个坏事情，一方面给我们提供更好的服务。另一方面，他们得到了足够的商业支持，反过来之后他们又会对整体的开源开发环境、发展环境起到很好的促进。我相信在未来的两到三年之内，会有一部分的商业公司涌到 Web 2.0 的发展生态圈里面。

然后从技术方面来讲，像前面几个月 MySQL 被 Sun 收购，起码是在 Web 2.0 这样的软件链条中的一个重要环节(MySQL),有些人可能会感觉出了一些问题。但现在像在数据库这一层呢，也不排除像 PostgresSQL 这些其它的数据库，趁这个机会被商业公司所拥抱，他们也会做出一些更大规模的应用场景出来。在数据库这方面可能会限制大家，几家开源数据库形成一个僵局，Sun 在......这个有些扯远了，还是绕回来。像现在很多的 Web 2.0 公司，他们对 Web 服务器这方面也会采用一些比较新的，像 Nginx， 我觉得在起码在接下来的一段时间内会吸引绝大多数公司长期、大规模的去使用它、去拥抱它，甚至为它开发一些更激动人心的新特性。

【这段时间比较热炒的开放平台、云计算也或许能给我们带来一些思路：很多有技术积累的的公司都有自己打造一套底层的架构的意图，比如针对存储层面向应用的虚拟化等。】

InfoQ中文站: 那最后作为一个由 DBA (Administrator) 成长为DB Architect，同样都是A，但这个A已经有一个变化，那么你对后来者有哪些建议呢？

Fenng: 建议谈不上，跟大家谈谈自己在这个过程中的一些转变。首先从DBA(的角度说)，因为 DBA 做一些实际相关的维护工作，从这个过程转到架构师这边，是相对从这比较"实"的岗位转换到现在看起来相对好像稍稍"虚"了一些，但是在这个"虚"的过程中，又相当于我们且退一步，然后就能看得更远一些，能看到整个软件架构的网站发展，甚至是公司战略上的一些事情，这对个人成长是有好处的，我希望大家如果有这个意愿也可以稍微尝试一下，因为 DBA 只是我们整个软件开发行业中的一个环节，那么在这个环节前面和后面，其实都有很多可以做的事情。

其实每个人都不是不可替代的，那我们是否可以尝试一下是否能够去替代别人呢？谢谢大家。

--EOF--

在 InfoQ 对我的采访发布后，我看到已经有网站在转载文字稿。其实口头的东西转换到文字，自己的话难免有些辞不达意的地方，征求 InfoQ 泰稳的意见后，我在这里就部分问答作一下修正，以免误导。

以下是正文:

InfoQ中文站: 作为一名资深的 DBA，大辉却在自己的 BLOG 上边写了不少关于网站架构这方面的一些文章，能不能谈谈 DBA 跟网站架构这方面的关系呢?

Fenng: 好多朋友和我开玩笑，说我做一个DBA，却总去写一些架构相关的东西，"是不是这个厨子不看菜谱，看兵法了？" 其实这二者之间我觉得是有些关系的。像数据库的维护，甚至设计、架构相关的工作，做到一定程度上还是要向前再走几步：也就是说要把我们架构相关的一些事情融合进来。当然作为一个 DBA 没必要一定要像我们的相关架构师这样，去做一些编码之类的实际工作，不过一些和 DB 结合的比较紧密的东西是一定要关注一下的，这也是我在 BLOG 上写了不少与架构相关文章的一个主要原因。

InfoQ中文站: 一般来说要提升网站的性能，瓶颈主要都有哪些，如果要解决这些瓶颈，又都存在哪些最佳实践呢?

Fenng: 在以前，可能瓶颈多数会在数据库上，也即最后瓶颈会落在 IO 上面。但是现在随着一些 Web2.0 发展而涌现出相关的技术解决方案，当前一个网站真正能否应付大流量、高并发，主要的问题还在于 Cache 能够充分、灵活、正确使用上，这点十分重要。【补充，因为这个整个话题基本是面向 Web 2.0 方面的，所以这里说 Cache 会是主要问题，如你所知，电子商务站点的话，事务处理能力无疑是比较棘手的事情】

InfoQ中文站: 一个要经受住大规模、高并发、访问量考验的成功 Web2.0 网站在设计的架构中要注意哪些东西呢?

Fenng: 这个在前期的规划中肯定是需要做一些预防性的措施，比如说选择适合的技术架构。这是第一步应该必须要考虑的事情。另外还有在产品设计上也会有很多需要注意的地方，现在我们的很多 Web 2.0 网站，包括国内的这些新兴的一些 Web 2.0 网站，多多少少存在一些过度设计的现象。这些设计不经意之间可能会对后台带来灾难性的影响，这就会对开发人员、架构师，甚至维护人员都带来很大的压力。

另一方面呢，参考当前业界上一些已经相对比较成熟的技术 DIY 搭建架构还是很关键的。我们做一个网站就好比造汽车一样，不一定非要造得像奔驰这样顶级豪华的(那成本会非常高)，我们只需造一辆能跑起来，跑得很好的汽车，这可能就已经达到成功的一半了。

InfoQ中文站: 那刚才在网站性能和调优这方面，你刚才也提到了，缓存的作用是非常重要的，那么它到底处于怎么样一个重要的地位呢？如何对缓存进行优化从而提升性能?

Fenng: 就我以前的相关经验，基于 Oracle 环境的一些实践，一方面是在应用程序高并发的设计上有一些必须注意的事项，另外一个就是能否充分利用 Oracle 自己的内存，最后实质上看其是能否充分利用自己的 Cache 机制。对于 Web 2.0 网站，可能很少有使用 Oracle 数据库(多是 MySQL)，但在MySQL上，一方面 MySQL 有自己的 Cache 机制，应该说还做得不错，再一个，绝大多数网站都会考虑使用像 Memcached 这样的外部组件进来，然后在这个地方，其实我们最后考量的是命中率，衡量命中率的高低，这是大家必须要注意的扩展性、性能指标。

命中丢失的 I/O 实际上最后压到我们的数据库上，到数据库的 I/O 命中再丢失有可能会压到最下面的磁盘上，这样磁盘【或存储】一定要能支撑住我们当前的最低需求。举个最简单的例子，我们的应用 Memcached，可能前面的 I/O 命中率是 80%，那么有剩下的 20% 会压到后面的 DB 上，这个 DB 的命中率有可能达到95%，剩下的5%，乘以前面那个 20%，总体 I/O 量 x 20% x 5%，这个 I/O 量会打到最后端的硬盘【或存储】上。而硬盘【乃至存储】的整体响应能力又是有限的...我们或许是做 RAID，也甚至可能出现单块硬盘支撑应用这样的情况。从这个基础往前推，就能计算出我们当前的系统能承载 Cache 的瓶颈，进一步知道整体 I/O 的处理能力。在设计的时候，一定要考虑到这样的情况，否则当压力突然增加到我们不能承受的时候，临时做一些扩展的手段，可能就会比较麻烦。

InfoQ中文站: 你刚才说到Cache命中率，那对于一个比较成功的这种网站，它Cache命中率一般会在多少呢?

拿 Oracle 来说，它本身的命中率做到 90% 甚至是 99.99 这样的情况，在MySQL的环境下可能做不到这样， Memcached 据我所知，可能70%～80%已经不错了【不同的应用表现差异很大，比如豆瓣的朋友告诉我他们命中率是 97% ! 】。当然命中率只是一个表面的现象，我们还要看实际真正的应用程序到底是怎样，可能不同的 Web 应用类型所能承载的访问频率也不大一样，所以并没有固定的比例，这里只能是凭一些经验。总体来说肯定是命中率越高，会越好一些。

第一部分先到这里。明天有时间修正剩下的部分。

前段时间 阿里巴巴网络侠客行大会上，我提到 InfoQ 对我做了个视频采访，现在这个采访已经可以访问了。

• 视频页面：与冯大辉谈数据库架构 (另：新闻页面)

这是个人第一个成功发布的视频访谈。去年 Oracle Open World 的时候, IT168 非要作采访，结果牺牲了两个会议时间，折腾完后再也没看到关于那个视频的消息。

说实话，采访之前自己还是比较担心效果的。这次 InfoQ 的采访效果比我的预期要好多了，因为现场发挥的地方比较多，有口不择言的时候，还望读者朋友海涵。

赞一下 Infoq 的几位朋友(泰稳、Jason、X5)! 和他们合作很愉快。我身边的很多同事都认为 Infoq(中文站) 是国内最好的技术信息站点。接下来，还有对我另外一位同事的采访(比我更为重量级)即将发布，我在采访现场听了都很过瘾。敬请期待，绝对不忽悠 :)

--EOF--

尽管最近又拿到了一笔风险投资，但 Twitter 似乎遇到了中年问题，前几天居然因为一台 DB Crash(原因是居然是连接数过多!） 而导致禁止了很多关键功能。接连几天，服务都是及其不稳定。或许是 DB 崩溃问题带来的雪球效应吧。因为这一系列问题的困扰，用户怨声载道，Twitter 倒是做了"改进": 开辟了一个子站点用于即时报告各项服务的状态问题。值得称道的是，Twitter 开发 Blog 上回答用户的技术询问倒是很端正的态度。

现在技术问题成了 Twitter 进一步发展的极其严重的制约了，在所有的 Web 2.0 站点里这倒是比较少见的。尽管 Twitter 过去号称把性能提升了 100 多倍，看来还不够哇。 前一段时间，有小道消息说 Twitter 准备放弃 RoR ，倒是 Twitter 忙不迭的辟谣。

面对很恼火的用户，Twitter 也承认架构上的一些问题，"Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system" ，而最初的架构也是面向内容管理系统而不是消息系统的，这需要一个转变过程。一直让我比较奇怪的是 Twitter 似乎没有专门的 DBA ，而是开发工程师兼任，如果 MySQL 不是瓶颈倒没问题的(有很多 Web 2.0 大站就不用专门 DBA 的)，可如果 DB 是瓶颈，那就比较麻烦了。DB 如此，其它环节也是如此。

有意思的是，随着互联网应用的飞速发展，Performance Engineer / Scaling Engineer 这样的新职位需求都出来了。这是个有挑战的活儿，值得尝试一下。

实在无聊，这只是一篇随笔罢了。

--EOF--

延伸阅读：Twitter 在自救

用什么来衡量一天没有白过? 可能看到一篇好文章能算做一个条件。infoQ 上的这篇 Scalability Best Practices: Lessons from eBay 会让每个架构师都比较激动的。

过几天估计 infoQ 中文站就翻译这篇文章了，所以只记录一点自己的想法好了。在其中的 7 个实战经验中，每一条都值得写篇学习笔记，我比较关注面向 DB 的几条。

水平切分

对于 eBay 这样个头的大 Web 应用，如果数据不能分片，就无从谈及扩展。这个话题我之前描述过一点，文章中提及数据库层的切片要比应用层复杂许多，我想其中最大的一个难点就是不同用户之间的关联数据问题吧，否则就完全可以根据用户范围或者群体划分到不同的 DB 上。现实的应用总是如此复杂，让每个架构师都早生华发啊。

避免分布式事务

其中提到的前 Inktomi 工程师 Eric Brewer 提出的 CAP 定理： Consistency (C), Availability (A), Partition-tolerance (P) ，最多能同时选择两个。三个不能同时实现。对于 eBay ，选择的是 A 和 P，牺牲了一致性，而通过系统的其它手段(比如事件系统)来追回事务的完整程度。BTW: 这次倒是没有提及 BASE :)

虚拟化所有层次

这样做的目的是为了达到编程上的方便以及运营操作的灵活性。通过 eBay 的 O/R 层实现了对数据库的虚拟化。这样应用程序开发者无需关注数据存在哪里的。

Cache

其中提到了 Cache 的应用场景：针对缓慢改变的数据、只读为主的数据、元数据、配置信息和静态数据等。 把握这个原则是很关键的。我个人就看到有病急乱投医的设计者把数据一股脑的扔进 Cache，潜在的麻烦很难消除。

强烈推荐大家直接点过去看一下该文。

补充：关于 BASE。
Basically Availble
Soft-state
Eventual Consistency

--EOF--

关心 Web 2.0 的朋友对于 LinkedIn 应该都不陌生。我这个 Blog 上以前也介绍过 LinkedIn 的架构信息。最近, LinkedIn 公司的两位工程师在 JavaOne 上做了两个分享。揭示了更多 LinkedIn 架构方面的技术信息。

1) LinkedIn - A Professional Network built with Java Technologies and Agile Practices

这是我看到的 Web 2.0 公司中第一个完全拥抱 SOA 的。这个文档中大致描述了 LinkedIn 开发过程上的一些经验。

| View

News Service Architecture 对于国内鲜果这样的 RSS 工具网站或许能有点参考价值。另外一个值得注意的地方是架构的变迁，随着业务的增长，后端 DB 的变化非常明显。

2) LinkedIn Communication Architecture

这一篇中描述了几次迭代经验，其思路值得借鉴。

| View

其中提到了对 CLOB 字段的更新认识。我个人的建议是：不到万不得已，还是别在 Web 应用中用 CLOB 了。

--EOF--

好多 Windows 平台的 DBA 一定比较烦操作系统升级时 "重启动才能生效" 这个问题，可能就是因为这个原因，可能没多少人愿意管理 Windows 平台的数据库。其实 Linux 有的时候也有类似的毛病，对 Kernel 打 Patch 基本也要重启动操作系统，除非你不去理它。而最近 Slashdot 一则关于 Linux 的新闻值得关注， Ksplice: Rebootless Linux kernel security updates，对于非常关注系统可用性的 DBA 来说，这是个很关键的技术改进。

提高可用性技术，前期细致周密的规划是重要一环。比如大文件系统的 fsck 问题，默认情况下达到一定 mount 次数或者超过一定时间，系统会自动启动 fsck 检验操作。而一个运行一段时间的 Linux Server 如果崩溃 reboot 后，文件系统校验时间漫长的叫人绝望。如果最初对这个问题进行预处理，即可避免不必要的停机时间。

另外维护中能尽量积累那些"可用性高"的技术或技巧也是必不可少的。比如 Kernel 重新读取分区表的问题，Fdisk 命令是搞不定的，而这里提到的 partprobe 命令 刚好派上用场。

以前我也记录过类似 Linux 如何不重启而识别新增的 LUN 的话题，积少成多，也就有用了。

--EOF--

Updated:

• Linux 的 Out-of-Memory Killer

继续我的学习笔记之旅。Flickr 的 DBA Dathan Pattishall 在前几天的 MySQL 大会上分享了 Scaling Heavy Concurrent Writes In Real Time (Record every Referral for Flickr Realtime) ，其中介绍了 Flickr Stats 的设计经验。国内好多 Web 站点其实也在设计类似的功能，只是不知道细节罢了。

数据结构原型

字段               数据类型         
Path_query         Varchar(255)        PK         
Domain             Varchar(50)                         
Owner              Bigint                              
When               Date                                
Object-ID          Bigint                              
Object-Type        Tinyint                             
Counts and stuff   Various ints        May be some keys

主键是字符串，开销太大。其他的索引如果做主键，也比较大。当表大小超过内存的时候，插入速度很慢，I/O 能力也上不来。

优化数据结构

数据预处理，通过 CONV(SUBSTR(MD5(Url),0,16),16,10) 把 Path_query 修改为 64 位的 ID (8字节), 主键为 ID+Owner+object+object-type，这个统计信息很容易抽象到一个数据对象，这个索引的设计也在于此。

另外补充一点，利用 PHP 的 ip2long() 和 long2ip() 函数对 IP 地址作预处理，耗费的存储空间只为原来地 25%，这是个很有趣的技巧。

数据 Sharding

对于海量的数据，以一个礼拜为间隔，水平分割。按照不同的数据力度每周一个表，每年一个全局表，再加上一个汇总表。数据量越大，InnoDB 存储引擎针对字符串的索引浪费的空间就越大。单个查询的 I/O 也自然大了起来。

所有应用对 DB 的响应要求 是 300 毫秒。但高并发写入的时候响应时间就糟糕起来。Flickr 的 Java 牛人实现了 Referral 队列，每 4000 条做批量处理。这样 IO 拥塞的就解决掉了。

总体的服务器规模过去 介绍过，对专业版用户的数据是永久保留的，而普通用户则只保留几周，为节省空间，采用 MyISAM 引擎，当用户转为专业版时，迁移数据。

补充一下，抓取 URL 是用的 curl 。最后，这篇 PPT 在线观看。

--EOF--

补充一张图：

这是该功能的 UI 设计。

• 1) 请求触发统计。默认不激活统计。从而节省大量不必要的开销;
• 2) 统计，没必要过度设计;
• 3) 元素可点击
• 4) 设计洁癖