InfoQ 数据库架构采访文字修正稿

在 InfoQ 对我的采访发布后（参见《与支付宝DBA冯大辉谈数据库架构》），我看到已经有网站在转载文字稿。其实口头的东西转换到文字，自己的话难免有些辞不达意的地方，征求 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中文站: 在 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 只是我们整个软件开发行业中的一个环节，那么在这个环节前面和后面，其实都有很多可以做的事情。

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

相关阅读：《与支付宝DBA冯大辉谈数据库架构》