支付宝数据库架构师冯大辉：谈数据库架构
概要
在上个月阿里巴巴举办的网侠大会上，InfoQ中文站有幸与著名的DBA冯大辉在一起，谈了谈网站/数据库架构、数据库性能调优、数据关系映射以及DBA个人职业发展等方面的话题。

个人简介
冯大辉，就职于阿里巴巴集团旗下支付宝（中国）网络科技有限公司（Alipay.com），担任数据库架构师，负责支付宝数据库架构规划、解决方案等相关工作。2007 年国内首批 Oracle ACE. 网上 ID 为“Fenng”，业余时间关注 Web 2.0 网站架构技术。
个人Blog：http://www.dbanotes.net

InfoQ中文站的读者们，大家好，今天我们有幸请到冯大辉先生参加我们的这个采访，大辉你好，请跟大家介绍一下你是谁，在做些什么？

大家好，我叫冯大辉，是支付宝网络中国科技有限公司的DBA。现在主要是负责支付宝相关的数据库架构的工作，在工作之余，我也比较关注Web2.0的一些发展情况，会在BLOG上写一些架构相关的文章，和大家分享，BLOG的地址是DBAnotes.net

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

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

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

在以前，可能很大的一个瓶颈，我觉得还是在数据库上，最后会落在实际的IO上面。但是现在随着一些Web2.0技术的出现，当前我觉得一个网站真正能否应付大流量、高并发，主要的问题还在于Cache的相关使用上，这点十分重要。

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

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



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

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

就我以前的相关经验，在Oracle的一些实践上，一方面是在高并发的设计上会有一些注意的事项。另外一个就是能否充分利用Oracle自己的内存，最后实质上看其是能否充分利用自己的Cache机制。在Web2.0网站，可能很少有使用Oracle这样的场景。但在MySQL上，一方面MySQL自己的Cache机制应该说还做得不错，再一个就是，绝大多数网站都会考虑使用，像Memcached 这样的外部组件进来，然后在这个地方，其实我们最后考量的是命中率，衡量命中率的高低，这是大家必须要注意的地方。

命中丢失实际上最后压到我们的数据库上，数据库的命中再丢失有可能会压到最下面的磁盘上。磁盘一定要能支撑住我们当前的最低需求，举个最简单的例子，我们的应为：memcached，可能前面的命中率是80%，那么有20%会压到后面的DB上，这个DB的命中率有可能达到95%，剩下的5%，加上前面那个20%，最后我们把所有的乘起来，这个比例会打到最后端的硬盘上，我们硬盘的整体响应能力又是有限的…我们可以去做RAID，甚至可以出现单块硬盘这样的情况。那么硬盘承载能力是有限的，我们把它反上去乘，一点点的乘，乘到前面去，就能计算出我们当前的系统能承载Cache的瓶颈。在设计的时候，一定要考虑到这样的情况，否则当压力确实突然增加到我们不能承受的时候，临时做一些扩展的手段，可能就会比较麻烦。

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

拿Oracle来说，我觉得它本身的命中率做到90%多，甚至是99.99这样的情况，在MySQL的环境下可能做不到这样， Memcached一般，据我所知，可能70%、80%已经不错了，但是命中率只是一个表面的现象，我们还要看实际真正的外部应用到底是怎样，有的可能不同的Web应用类型，他所能承载的访问频率也不大一样，所以并没有固定的比例，只能是凭一些经验，但总体来说肯定是命中率越高，会越好一些。

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

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

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

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

分片总的来说，它不是一种比较新的技术，我们现在像MySQL在 5 点几之后，有了分区功能。其实在这之前，MySQL是没有分区能力的。当时如果需要处理一些比较大的数据量。比方说要对数据随着时间进行历史化处理，那么就会比较麻烦，人们可能是因地制宜，就产生Sharding这样技术策略。严格来说，数据分片呢，其实在我们以前也有一些相关的实践，在其他的数据库上，我们也会有一些历史策略，只是当时这个名词没有完全定义下来。据我所知，这个词是从大型专线游戏中发展出来的，大部分用户会集中在某个区域。那么这一部分集中在某个区域的用户，会把他们放在特定的服务器上。不同区域之间的用户之间的关联度可能不大，这个场景和我们现在的数据库分片策略其实是非常非常相似的，我们当前如果对数据库做一些分片，也会采用这样的基本思想，比如说根据不同的用户ID范围，或者说不同的地区，如果建的是商务网站，可能根据产品的类型，我们会把不同的数据扔到不同的DB上，这些不同DB之间的关联度是很小的。然后我们在不同DB之间，可能相对来说会有一个分装层，在这个封装层之外，对这个应用程序用户来说，就像是透明的，那么就达到了我们数据库上高度扩展化的目标。谢谢。

那分片这种策略有什么利弊吗？

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

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

首先一点呢，我想拿我