解析JDK 7的动态类型语言支持
随着JDK 7的发布，字节码指令集终于迎来了第一位新成员——invokedynamic指令。这条新增加的指令是JDK 7实现“动态类型语言（Dynamically Typed Language）”支持而进行的改进之一，也是为JDK 8可以顺利实现Lambda表达式做技术准备。在这篇文章中，我们将去了解JDK 7这项新特性的出现前因后果和它的意义。
技术访谈
该内容已经被标记书签！
标记书签错误，请重试！
与冯大辉谈数据库架构
受访人 冯大辉 采访人 李明（nasi）、Jason Lai（赖翥翔） 发布于 2008年6月9日 长度 00:22:53
概要
在上个月阿里巴巴举办的网侠大会上，InfoQ中文站有幸与著名的DBA冯大辉在一起，谈了谈网站/数据库架构、数据库性能调优、数据关系映射以及DBA个人职业发展等方面的话题。
个人简介
冯大辉，就职于阿里巴巴集团旗下支付宝（中国）网络科技有限公司（Alipay.com），担任数据库架构师，负责支付宝数据库架构规划、解决方案等相关工作。2007 年国内首批 Oracle ACE. 网上 ID 为“Fenng”，业余时间关注 Web 2.0 网站架构技术。个人Blog：http://www.dbanotes.net
在上个月阿里巴巴举办的网侠大会上，InfoQ中文站有幸与著名的DBA冯大辉在一起，谈了谈网站/数据库架构、数据库性能调优、数据关系映射以及DBA个人职业发展等方面的话题。
个人简介
冯大辉，就职于阿里巴巴集团旗下支付宝（中国）网络科技有限公司（Alipay.com），担任数据库架构师，负责支付宝数据库架构规划、解决方案等相关工作。2007 年国内首批 Oracle ACE. 网上 ID 为“Fenng”，业余时间关注 Web 2.0 网站架构技术。个人Blog：http://www.dbanotes.net
大家好，我叫冯大辉，是支付宝网络中国科技有限公司的DBA。现在主要是负责支付宝相关的数据库架构的工作，在工作之余，我也比较关注Web2.0的一些发展情况，会在BLOG上写一些架构相关的文章，和大家分享，BLOG的地址是DBAnotes.net
好多朋友和我开玩笑，说我做一个DBA，却总去写一些架构相关的东西，“是不是这个厨子不看菜谱，看兵法了？”其实二者之间我觉得是有些关系的。因为像数据库的维护，甚至于设计、架构相关的工作，做到一定程度上觉得自己还是要向前再走几步，也就是说一定要把我们架构相关的一些事情融合进来，但是作为一个DBA没必要一定要像我们的相关架构师这样，去做一些编码之类的实际工作。但是一些和DB结合的比较紧密的东西是一定要关注一下的，这也是我在BLOG上写了不少与架构相关文章的一个主要原因。
在以前，可能很大的一个瓶颈，我觉得还是在数据库上，最后会落在实际的IO上面。但是现在随着一些Web2.0技术的出现，当前我觉得一个网站真正能否应付大流量、高并发，主要的问题还在于Cache的相关使用上，这点十分重要。
这个我想在前期的规划中肯定是需要做一些预防性的措施，比如说选择适合的技术架构啊，这个绝对是在第一步应该必须要考虑的事情。另外还有一些像包括在产品设计上也会有很多需要注意的地方，现在我们的很多Web2.0网站，包括国内的这些新兴的一些Web2.0网站，在产品设计上，我认为多多少少存在一些过度设计的现象。但这些设计不经意之间可能会对后台带来灾难性的影响，那么这对开发人员、架构师，甚至维护人员都带来很大的压力。
另一方面呢，我想参考当前业界上一些已经相对比较成熟的技术，还是很关键的。我们做一个网站就好比造汽车一样，不一定非要造得像奔驰这样顶级豪华的，我们只需造一辆能跑起来，跑得很好的汽车，这可能就已经达到成功的一半了。
另一方面呢，我想参考当前业界上一些已经相对比较成熟的技术，还是很关键的。我们做一个网站就好比造汽车一样，不一定非要造得像奔驰这样顶级豪华的，我们只需造一辆能跑起来，跑得很好的汽车，这可能就已经达到成功的一半了。
就我以前的相关经验，在Oracle的一些实践上，一方面是在高并发的设计上会有一些注意的事项。另外一个就是能否充分利用Oracle自己的内存，最后实质上看其是能否充分利用自己的Cache机制。在Web2.0网站，可能很少有使用Oracle这样的场景。但在MySQL上，一方面MySQL自己的Cache机制应该说还做得不错，再一个就是，绝大多数网站都会考虑使用，像Memcached 这样的外部组件进来，然后在这个地方，其实我们最后考量的是命中率，衡量命中率的高低，这是大家必须要注意的地方。
命中丢失实际上最后压到我们的数据库上，数据库的命中再丢失有可能会压到最下面的磁盘上。磁盘一定要能支撑住我们当前的最低需求，举个最简单的例子，我们的应为：memcached，可能前面的命中率是80%，那么有20%会压到后面的DB上，这个DB的命中率有可能达到95%，剩下的5%，加上前面那个20%，最后我们把所有的乘起来，这个比例会打到最后端的硬盘上，我们硬盘的整体响应能力又是有限的…我们可以去做RAID，甚至可以出现单块硬盘这样的情况。那么硬盘承载能力是有限的，我们把它反上去乘，一点点的乘，乘到前面去，就能计算出我们当前的系统能承载Cache的瓶颈。在设计的时候，一定要考虑到这样的情况，否则当压力确实突然增加到我们不能承受的时候，临时做一些扩展的手段，可能就会比较麻烦。
命中丢失实际上最后压到我们的数据库上，数据库的命中再丢失有可能会压到最下面的磁盘上。磁盘一定要能支撑住我们当前的最低需求，举个最简单的例子，我们的应为：memcached，可能前面的命中率是80%，那么有20%会压到后面的DB上，这个DB的命中率有可能达到95%，剩下的5%，加上前面那个20%，最后我们把所有的乘起来，这个比例会打到最后端的硬盘上，我们硬盘的整体响应能力又是有限的…我们可以去做RAID，甚至可以出现单块硬盘这样的情况。那么硬盘承载能力是有限的，我们把它反上去乘，一点点的乘，乘到前面去，就能计算出我们当前的系统能承载Cache的瓶颈。在设计的时候，一定要考虑到这样的情况，否则当压力确实突然增加到我们不能承受的时候，临时做一些扩展的手段，可能就会比较麻烦。
拿Oracle来说，我觉得它本身的命中率做到90%多，甚至是99.99这样的情况，在MySQL的环境下可能做不到这样， Memcached一般，据我所知，可能70%、80%已经不错了，但是命中率只是一个表面的现象，我们还要看实际真正的外部应用到底是怎样，有的可能不同的Web应用类型，他所能承载的访问频率也不大一样，所以并没有固定的比例，只能是凭一些经验，但总体来说肯定是命中率越高，会越好一些。
在Web2.0的时代，海量数据对于越来越多的开发者来说，已经不再是一个遥不可及的话题了，可能随便哪一个访问量很大的Web2.0网站都有可能拥有令人咂舌的数据量，那么对于这种网站，除了对数据库存储进行优化，除了缓存，然后还有那些策略？
我觉得可能主要是在存储方面会有一些大的挑战，比如存储的可靠性。像以前我们就曾经遇到过这样的BSP服务商，对客户的数据居然没有备份，导致了很多用户损失了一段时间之内的数据，这样总体来说对网站的声誉、对用户的资源都是很糟糕的。
随着我们现在互联网的飞速发展，数据总体来说是趋于膨胀性的，在这个过程中，我们如何把数据有效的存储，并且有效的获取，便是个比较复杂的问题，像一方面我们前面说了太多Web2.0相关的话题。还有一个是像，比如说我所在的公司支付宝，当然我们也面临着这样的大数据量、海量数据的挑战，当前我们的一个策略，也是沿袭公司这SOA战略化思想，就是数据库相关的，对后台的相关数据进行一定的SOA化处理，然后另外一个比较重要的策略就是数据生命周期的管理，我们对这样的，在数据生命已经达到这样的周期之后，就相关的数据做一些归档化的处理，进行二级存储或者分级存储。那么话说回来，对一些Web2.0网站，我觉得也可以运用这样的思想机制，对用户已经不大可能访问或者访问频率比较小的（数据），采用分级存储，或者说额外做一些访问策略的制订，应该也是有必要的。
随着我们现在互联网的飞速发展，数据总体来说是趋于膨胀性的，在这个过程中，我们如何把数据有效的存储，并且有效的获取，便是个比较复杂的问题，像一方面我们前面说了太多Web2.0相关的话题。还有一个是像，比如说我所在的公司支付宝，当然我们也面临着这样的大数据量、海量数据的挑战，当前我们的一个策略，也是沿袭公司这SOA战略化思想，就是数据库相关的，对后台的相关数据进行一定的SOA化处理，然后另外一个比较重要的策略就是数据生命周期的管理，我们对这样的，在数据生命已经达到这样的周期之后，就相关的数据做一些归档化的处理，进行二级存储或者分级存储。那么话说回来，对一些Web2.0网站，我觉得也可以运用这样的思想机制，对用户已经不大可能访问或者访问频率比较小的（数据），采用分级存储，或者说额外做一些访问策略的制订，应该也是有必要的。
分片总的来说，它不是一种比较新的技术，我们现在像MySQL在 5 点几之后，有了分区功能。其实在这之前，MySQL是没有分区能力的。当时如果需要处理一些比较大的数据量。比方说要对数据随着时间进行历史化处理，那么就会比较麻烦，人们可能是因地制宜，就产生Sharding这样技术策略。严格来说，数据分片呢，其实在我们以前也有一些相关的实践，在其他的数据库上，我们也会有一些历史策略，只是当时这个名词没有完全定义下来。据我所知，这个词是从大型专线游戏中发展出来的，大部分用户会集中在某个区域。那么这一部分集中在某个区域的用户，会把他们放在特定的服务器上。不同区域之间的用户之间的关联度可能不大，这个场景和我们现在的数据库分片策略其实是非常非常相似的，我们当前如果对数据库做一些分片，也会采用这样的基本思想，比如说根据不同的用户ID范围，或者说不同的地区，如果建的是商务网站，可能根据产品的类型，我们会把不同的数据扔到不同的DB上，这些不同DB之间的关联度是很小的。然后我们在不同DB之间，可能相对来说会有一个分装层，在这个封装层之外，对这个应用程序用户来说，就像是透明的，那么就达到了我们数据库上高度扩展化的目标。谢谢。
分片首先他的好处还是很容易看到的，起码我们的DB能达到不依赖于某个单点，而这样能做到平滑的扩展，就像大家常说的Scale Out横向扩展机制。它的弊端也是比较明显，对于事务高速处理这样的网站，它有它的自己的缺点，事实上我们好多朋友也应该知道，一个事务如果跨数据库，这样对设计者，对编码人员来说，还是比较棘手。那么如果一个事务如果跨两个甚至多个DB，Sharding复杂度就会很高。Sharding在业界的应用场景基本上也就是这种读应用比较重的情况，而且对事务的安全性要求不高，这样的场景会非常适合。
首先一点呢，我想拿我们支付宝来说，ORM是大家觉得用得非常好的，但在一个相对比较大的开发环境，对开发团队来说，它的弊端可能就不大容易看出来。因为我们用得是ORM，就很容易把中间DB这层完全隔离出来。然后把这一层的处理交给专门的DB职员——我们这边还有专门的开发DBA，由他们来专门对这层进行集中的监控管理，甚至做一些规划类的工作。这样呢，开发工程师还有架构师这边，实际上他们可以集中精力在其他方面做更多的投入，一个比较大的团队我觉得像ORM这些还是很容易能看到好处的。
在另一方面，我们看一下它的弊端，因为像一些Web，回头我们说一些，Web中小网站，他可能相对人手也比较少，大家 用得工具呢，可能像PHP、 ROR这些东西，也是在开发上，上手又比较容易的。那么这个时候，事实上一个潜在的问题是，当代码规模到一定程度，如果没有去做一些OR映射，那么可能会给网站带来一些潜在的比如说代码管理上的问题，这一点只是我的个人看法，实际上大家在具体的应用场景可能会有各自头疼的问题，我在这方面不是专家，也仅供大家参考。
在另一方面，我们看一下它的弊端，因为像一些Web，回头我们说一些，Web中小网站，他可能相对人手也比较少，大家 用得工具呢，可能像PHP、 ROR这些东西，也是在开发上，上手又比较容易的。那么这个时候，事实上一个潜在的问题是，当代码规模到一定程度，如果没有去做一些OR映射，那么可能会给网站带来一些潜在的比如说代码管理上的问题，这一点只是我的个人看法，实际上大家在具体的应用场景可能会有各自头疼的问题，我在这方面不是专家，也仅供大家参考。
事实上一个从很明显的一个特点说，支付宝其实业务是非常复杂的，这和我们很多的Web2.0公司不大一样，Web2.0它可能从一个点切入进去。在这一点上，我觉得做得比较透。支付宝呢，它可能有点像我们以前做的一些通用软件，他要考虑不同的行业、不同的用户、还有像买卖之间，与这么多银行之间的关系等等，这个复杂度还是很大的。
这实际上就从一定程度上决定了我们和Web2.0公司截然不同的应用解决方案，像当前我们在支付宝，在一年之前，甚至两年之前就已经考虑，把我们的整个网站SOA化、组件化。在这个过程中，也考虑了一些像Web2.0中的技术元素，但总体的思路呢，还是说向SOA化，向面向服务这方面大步的跨进，然后就从SOA这一点，事实上很多Web2.0公司，他们未必能完全的实现，完全的做到这样的面向服务化，我觉得这可能是两者截然不同的一个表面特点。
另外，像支付宝也在尝试做一些，对外部客户、服务提供一些接口，甚至完全开放的一个平台，这一点又和我们当前这些像FaceBook，或者是说，像美国的MySpace这样的社交区、SNS网络了有一些共通之处。
这实际上就从一定程度上决定了我们和Web2.0公司截然不同的应用解决方案，像当前我们在支付宝，在一年之前，甚至两年之前就已经考虑，把我们的整个网站SOA化、组件化。在这个过程中，也考虑了一些像Web2.0中的技术元素，但总体的思路呢，还是说向SOA化，向面向服务这方面大步的跨进，然后就从SOA这一点，事实上很多Web2.0公司，他们未必能完全的实现，完全的做到这样的面向服务化，我觉得这可能是两者截然不同的一个表面特点。
另外，像支付宝也在尝试做一些，对外部客户、服务提供一些接口，甚至完全开放的一个平台，这一点又和我们当前这些像FaceBook，或者是说，像美国的MySpace这样的社交区、SNS网络了有一些共通之处。
其实作为一个技术人员，每当要谈到趋势，肯定要给大家笑。从中长期来看，国内的一些Web2.0服务逐渐又涌现出来了，那么随着这样的业务发展，我相信会有更多的商业化元素加进来。像以前是好多Web2.0公司是完全使用开源的技术，那么随着规模的兴起，一些以前提供开源技术的组织或个人他们会尝试进行一些商业化的运作，商业化并不是个坏事情，一方面给我们提供更好的服务。另一方面，他们得到了足够的商业支持，反过来之后他们又会对整体的开源开发环境、发展环境起到很好的促进，我相信在未来的两到三年之内，会有一部分的商业公司涌到Web2.0的发展生态圈里面。然后从技术方面来讲，像前面几个月MySQL被Sun收购了。那么起码是在Web.2.0这样的软件链条中的一个重要环节，有些人可能会感觉，出了一些问题。但现在像在数据库这一层呢，也不排除像PostgresSQL这些其他的数据库，他们趁这个机会被商业公司所拥抱，他们也会做出一些更大规模的应用场景出来。在数据库这方面可能会限制大家，几家开源数据库形成一个僵局，Sun在……这个有些扯远了，还是绕回来。像现在很多的Web2.0公司，他们对Web服务器这方面也会采用一些比较新的，像Nginx我觉得在，起码在接下来的一段时间内会吸引绝大多数公司长期的去使用它、去拥抱它，甚至为它开发一些更激动人心的新特性。
建议谈不上，跟大家谈谈自己在这个过程中的一些转变。首先从DBA，因为DBA做一些实际相关的维护工作，从这个过程转到架构师这边，是相对从这比较“实”的岗位到，转到现在看起来相对好像稍稍“虚”了一些，但是在这个虚的过程中，又相当于我们且退一步，然后就能看得更远一些，能看到整个软件架构的网站发展，甚至是公司战略上的一些事情，这对个人成长是有好处的，我希望大家如果有这个意愿也可以稍微尝试一下，因为DBA只是我们整个软件开发行业中的一个环节，那么在这个环节前面和后面，其实都有很多可以做的事情，其实每个人都不是不可替代的，那我们是否可以尝试一下是否能够去替代别人呢？谢谢大家。
说的真好
发表人
Zhao Jeffrey
发表于
Re: 说的真好
发表人
withyou gakaki
发表于
Re: 说的真好
发表人
霍 泰稳
发表于
Re: 说的真好
发表人
冯 希顺
发表于
Re: 说的真好
发表人
David Fenng
发表于
Re: 说的真好
发表人
霍 泰稳
发表于
Re: 说的真好
发表人
David Fenng
发表于
Re: 说的真好
发表人
霍 泰稳
发表于
Re: 说的真好
发表人
Zhao Jeffrey
发表于
Re: 说的真好
发表人
Han Jie
发表于
flash
发表人
Lau Jarod
发表于
Re: flash
发表人
Guo Xiaogang
发表于
确实说得好
发表人
Huang Huang
发表于
务虚
发表人
gz husthxd
发表于
-
以后有这方面的问题可以直接发这个链接了，呵呵。
-
真是宝贵的资料啊 老赵也在啊 最近微软也出内存数据库了呵
-
对flash版本的检查做的太差了吧。用flash 10上说要求9
-
咋感觉老是在唱衰MySql那？
-
倒也不是唱衰 MySQL ，只是提醒一下而已 :)
想比 Oracle，我个人其实更喜欢 MySQL -
老赵不仅在，而且还是InfoQ中文站.NET社区的编辑呢：）
-
据说淘宝网在逐渐将自己的数据库从Oracle迁移到MySQL，不知道现在进展如何，大辉能否透露一些这方面的情况？如果真迁移完成了，那可真是给阿里巴巴节省了不少运营费用。
-
据说淘宝网在逐渐将自己的数据库从Oracle迁移到MySQL，不知道现在进展如何，大辉能否透露一些这方面的情况？如果真迁移完成了，那可真是给阿里巴巴节省了不少运营费用。
第六期的《程序员》有淘宝使用开源软件的介绍。我还没仔细看，似乎提到了 DB 的使用情况 -
《解密淘宝网的开源架构》这篇文章我看了，里面提到了一些：
在淘宝网的应用中，采用了两种关系型数据库管理系统。一个是Oracle的Oracle 10g，另外一个是Sun的MySQL。Oracle有很强大的功能和安全性，可以处理相对海量的数据。而MySQL非常适合用多台PC Server组成多点的存储节点阵列，每单位的数据存储成本也非常的低廉。
可以看出，在关键的数据处理上淘宝网还是选择了专有软件，哪怕成本高一些。另外一个限制网站大量采用MySQL的原因我想还是MySQL方面的人才，相比于Oracle，精通MySQL的DBA依然是稀缺资源。 -
我认为“限制大量采用MySQL”和“精通MySQL人员缺失”也是互成因果的。
其实我想对于DBA来说，太多东西是相通的了，如果真“率先”“大量采用MySQL”，我想精通这方面的人不会比Oracle少。 -
以前看他的blog,都不知道博主，原来博主跟博客一样帅啊。那啥，T－shirt都跟blog的背景色配的呢。。。 看完之后受益良多。
-
抽象化，站得高，才能看得远。
-
已经改好了。谢谢提醒。
-
给力
14 条回复
关注此讨论 回复