中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会，首次举办的APMCon以“驱动应用架构优化与创新”为主题，致力于推动APM在国内的成长与发展。
云和恩墨创始人 盖国强于数据库性能优化专场发表了题为《从传统银行到互联网金融--Oracle数据库架构设计与性能优化实践》的演讲，现场分享了从传统银行到互联网金融的架构规划与性能优化的实践案例。
以下为演讲实录：
大家好!我今天分享给大家的主题是《从传统银行到互联网金融 — Oracle数据库架构设计与性能优化实践》。我会通过两个案例把我的一些经验分享给大家。刚刚主持人跟我讲，说上学的时候看过我的书，今天还来跟大家分享这个知识，可能是我比较年长了。
稍微介绍下我自己，还有我的职业生涯，其实就是一句话，就是O2O。
我前半部分就是线上完成的。我们和ITPUB这个论坛一起成长，今天这个论坛是数据库方面最大的论坛。我们伴随着它的成长，它也帮助我们获得了成长，所以，那里是我们这一伙人的精神家园。我的经历可能对大家有一些借鉴，前面是在互联网上学习技术，帮助他人，然后在帮助他人的过程中帮助了自己，这是我真实的体验。
我还写作出版过一系列的书，通过书帮助其他的读者学习技术，我们还会去分享这些技术。Oracle ACE 总监是Oracle公司给予的最高荣誉，总监这个称号到今天就10位，10年时间，每年会有一位授予这个称号，这是我的一段线上生涯。
线下生涯，非常荣幸把我们线上结识的一些朋友，最终聚集到一起创办了一个公司，为用户提供服务。这个互联网时代带给我最大的帮助，或者是说，它让我走到了一个不一样的人生里面去。我可以说，我生活里面绝大多数的朋友、伙伴，甚至是一部分人变成了家人，这些人，这些朋友，甚至是我们一些家人都是通过互联网的方式认识的，最后走到了一起，这是我线上线下走过的两段历程。
今天我们来看一下，无论是互联网技术在蓬勃发展，还是传统企业，技术都是在不断地进步。所有的，不论前端使用各种各样的应用，最终是要在数据库里面。数据是核心资产，这个方向变革越来越快。
我总结了一下，企业级数据应用的现状，或者是发展的历程，就是合久必分，分久必合。大家可以思考一下企业级数据库应用是不是走过这样一些路，我稍微展开了一下，大概就是这样一些历程：企业构建一个IT系统，后端有数据库承载企业级数据。这个数据库不断地积累，数据量膨胀带来一些问题，甚至性能上的衰减。出现这些问题的时候，企业开始做一些优化和变革，这些优化和变革包括什么?可能通过分表的方式去提升性能，更进一步地使用分布式数据库，或者拆分成多个数据库去解决并发的问题。再到今天，互联网技术蓬勃发展，有别于传统的一些架构去承载业务。
还有一些企业级数据环境变化，是业务驱动导致的。比如，一个金融机构，由于监管需要，要求把各种各样的业务拆分成多套独立环境。有一些和企业目标相违背，企业要求系统是稳定的、高效的、成本最优的，但是，如果我们将数据库拆分、分散分布、分布式部署，往往耗费更高的成本。这里面存在着很多的矛盾。
在这样一种场景之下，国内很多企业开始走向了自然而然的数据整合。传统的企业在过去很长时间内，系统是处于村落式建设的状态。用户一套应用上线的时候，就部署一套独立的IT系统，这里面不仅仅有数据库，还有存储，有应用，就是一套完善的IT假酒。那么，经历十几年或者二十几年IT建设以后，国内很多企业现状都是这样的。
我列举一些客户案例。企业IT环境里面系统丛生，无数的IT系统，无数的数据库。这里我举个例子，这个是我们的几个客户，客户授权了的。有各种各样的系统，有数据仓库、门户，没有一个业务应用，就是构建一套IT系统。到今天现状是什么?企业有大量的系统，有大量的数据库为他们带来了大量的成本负担。
我们有一个非常典型的用户，可以跟大家分享一下。09年的时候，我们为这个用户做了咨询的服务，做了优化。当时用户只有一套核心系统，一套核心数据库，存在一些问题，我们为他提供了服务，为他做了优化。2015年的时候，他找到我们，他现在有50套了。集中式的拆分成50套，带来一些问题：
• 第一，成本攀升了。原来一套各种知识产权的问题，硬件的问题，现在变成了50套。
• 第二，故障率提升了。原来一套数据库，现在变成50套。
因为存在这样一些问题，用户通过思考，通过整合降低投入，改善运维，这是一个自然而然的情况。
当用户有50套IT环境的时候，这个系统整体上非常非常的复杂。数据库版本和操作系统不一样，数据库结构不同。所以，我们打一个比喻，就像管理一个动物园一样，每一个系统的标准都不统一，运维成本和管理成本都是非常高的。就像有不同的动物，脾气禀性习惯不一样，今天这些动物都是走向集中的一个时代。
我举一个例子，这是我们的一个客户，是我亲自执行的一个项目，大约在几年前做的，来自于邮政储蓄银行。他们是一家传统的金融机构，传统的银行。它最初的企业级IT架构是什么样子的呢?31个省市，每一个城市有一套独立IT系统，分布式部署。每一个城市是独立运营的，最后数据再汇总。这种架构很明显，不管是运维还是成本上存在很多的问题，在几年以前还是走向整合集中。那么，这样一个企业级的数据环境走向整合，面对的第一个问题是什么?就是容量规划。如果我们最初是分布式的架构，如果我将它整合成几套数据库，数据层来讲，需要什么样的软硬件架构才可以支持这样的一个集中式系统?所以，这是第一个被考虑到的因素。那么，如何去规划这样的容量?希望选择什么样的IT技术架构来支撑它?我介绍一下支撑这个项目做出来的整体方案。
第一，我们必须通过科学的数据去量化，整合以后系统的负载压力，根据负载和压力去选择我们的技术设施。如何量化这些数据?这跟今天大会的主题非常吻合，就是APM应用性能管理，数据库也是一种应用软件：
• 第一，就是将所有数据库系统的这些数据汇总起来，然后绘制动态趋势。比如，我将一个长期趋势绘制出来。
• 第二，将31套系统的性能数据进行整合和叠加。将它融合在一起，来推测整合之后的系统容量。
所以，我觉得在今天，不管是在过去还是今天，一个系统建设过程中科学的、量化的容量推演计算，实际上是非常重要的。
那么，数据库里面如何实现我刚刚讲的性能的推演或者容量规划?其实很简单，Oracle数据库拥有非常非常完善的自我监控和信息采集系统。我们要做的是什么?就是持续地记录，收集Oracle自身这些指标，然后将这些指标的趋势推演出来就可以了。Oracle有两组这样相关的指标。第一组，是 Stat信息，第二组是Event，就是等待，是客观的、统一的指标。这两者将它们抽取出来，然后，获得长期的趋势，最后就可以通过叠加，迁移得出来一个整体的趋势。
这里给大家展示一个CPU的维度。
我们通过31套数据环境，将它进行整合以后，推演出来的CPU指标是什么?大家可以看到这个峰值120个C，如果进行线性整合，偏移120个CPU，峰值的时候可以承载整个系统的压力，这个是对于现网的压力。
那么，如果我希望在峰值的时候，我的系统负载只有50%，我需要对这个资源乘以2倍。3年以内，在这个系统的生命周期以内，系统容量还会增长多少?我可以继续得出未来的那个值。所以，通过这样一些性能数据的计算推演，就可以科学得出一个系统的容量规划。因此，在我们面对这样一个大型应用系统整合的过程当中就可以做出数据化、量化、科学化的推测。
这个系统峰值承载多少IOPS，直接影响到需要配置什么样的存储支撑这样的业务系统。当我们面对一个系统整合的项目，进行容量规划时，即使是一个单系统，一个新系统，也应当遵循这样一些量化指标。
进一步，我跟大家分享一下，传统的金融企业向新时代迈进过程当中会经历什么阶段?这同样来自于刚刚提的中国邮政储蓄银行系统建设过程。大约分三步：
1、物理集中。就是把全国分散的服务器系统搬到北京来，建立一个集中式数据中心，现实生活就是这样做的。而且，他们不仅搬迁了服务器，把人也搬到北京来了，把各省运维人员带到北京来，构建一个集中式数据中心。
2、数据集中。将后端分散的数据库整合起来，数据集中了以后，才可以发展。
3、应用集中。数据集中起来了以后，能够通过应用重构为一家银行提供更快捷的统计输出决策支持。
这三个步骤和今天的云的三个阶段非常相似：第一个阶段，几乎就是构建一个IaaS，然后是PaaS，然后是SaaS。所以，传统企业走过的这样一个历程，把今天最流行的技术进行了一个推演。
邮政这个项目，受到了国家的高度重视。工信部称之为开放式支持系统、支持银行交易的一个突破。为什么这样讲?大家知道，我们国家几大银行里，前四大行，核心都是使用大型机在支撑。邮储银行做了一个突破，是非常独特的一家银行。
前面跟大家分享的，是在这样的一个整合过程中，我们需要注意的一些要素以及如何进行性能规划和容量推演。
这个是第一步，系统整合起来后，是不是还会遇到其他的一些问题?那么，在现实当中会变成什么样子?那从前期的设计，到后期的落地，我跟大家分享一下第二阶段的故事。
系统整合以后，大概的呈现是这样的，我稍微把它细致一点分享给大家：
• 第一，整个系统，整个服务器配置是惠普，主机内存是1个TB，这个配置当时看起来很高。当然，今天已经不高了，今天很多用户的内存都是2个T起步。
• 第二，并发比较高，4000多并发访问这个数据库，大概有4300左右。
• 第三，性能数据。我们看到了这个系统处于一种高等待的状态，在等待某种资源。第一个叫做log file sync，是指Oracle在写日志的时候，我们做一个事务的时候，后台在写日志，这个阶段是一个等待。这个过程等待时间占到了47%，也就是说，成为了非常显著的一个瓶颈，甚至会影响整个系统的容量。
如何去解决这样的问题呢?首先，我们看一下整体的系统架构。
其实也是很难得的，一家大型银行，成为五大行之一了，这样的一家银行整个数据安全如何保障?从这个架构图可以看到，前端两个做集群，通过Oracle的RAC实现，Oracle自动存储管理的一个软件来管理存储，然后，底端有三个存储。
从上面的图大家可以看到，底层存储也是多层存储，在这些层面上没有单点。另外，首先同城有同步复制的一套系统。第二，有一个异地远程。这个就是异步复制，这样形成了一个两地三中心的一个架构。同步和异步相配合，保障数据安全。
除此之外，用户还做了一些其他的设计，整个系统设计非常的精细。这里列了两点：第一，oracle写日志的时候，写日志是非常重要的，确保可以始终获得CPU。第二，用户担心写日志有瓶颈，直接把日志弄到内存里面去了，就是几乎把物理消除了。这样一个架构在现实的运行过程中，实现的数据是什么样的?运行状况是什么样子的呢?
上图里列了一个常态数据。第一，大家可以看到，每秒可以产生2兆左右的Redo写出去，Transactions每秒1300多笔。如果大家使用Oracle数据库就会理解这个，Oracle数据库每秒超过1000就是比较忙的数据库了。
在这样一个状态下，正常运行的时候，系统的资源利用率、系统负载率非常的低。那么，为什么会出现瓶颈?瓶颈来自于何方?
这里，我插播一组数据。在我的职业生涯里面，我认为我的这些方法对我的帮助非常大，用今天的词来讲就是性能管理。我在学习过程中，自发地为我自己创建了一组性能数据，这组性能数据来自于遇到的所有数据库。我都会记录下来，形成我的数据库。包括什么信息?我用一个表格展示给大家看：
每一个数据库并发多少?每秒执行的SQL有多少?日志有多少?使用的系统资源是什么?CPU，内存，IO等，有这样一组性能数据以后，我为自己建立了一个标尺。我们搞数据库的，最害怕别人问什么问题?这个数据库到底可以承载多少业务?我这个数据库现在性能是好的还是不好的?其实这样的问题比较难以回答，因为它需要的条件太多了。这个数据库现在在做什么?将来能承载多少业务?跟你的整体硬件水平有关系。但是，如果你跟用户讲，我还需要很多很多的数据才可以给你答案，用户产生一个意识，你不太懂。所以，我形成了这样的表格，它是我的一个标尺，我不需要那么复杂的交互，给我一个基本数据，我量它就可以了。在我的知识库里面负载最高系统能承载什么样的业务?什么叫做高?什么叫做低?我大约有一个尺子，我马上可以给一个靠谱的答案。所以，这个是我想跟大家分享的一个我的经验和方法。
我这里面有一些数据大家可以看一下，比较繁忙的数据库，比如说，你看到最忙数据库是什么样子的?最后一行，这个系统数据库每秒4000多的事务，意味着每小时可以做到1500万左右的事务，2个节点集群可以做到3千万每秒，这个已经是比较繁忙的系统了。还有很多，比如，我的保险类客户，可以做到100万，证券50万。去年是证券交易的低谷，整个行业不景气，客户系统非常的闲，今年稍微好一点。这样我有一个标尺，有了这些数据后可以做什么呢?
外行看热闹，内行看门道。我这里用一组数据，这一组数据比较早，双11支付宝的数据。这是支付宝一个哥们在双11之后发布的一组数据，这一组数据发布了以后，我瞬间可以把他的系统架构算出来。
我觉得如果搞数据的，就是要有对数据的敏锐，你要能看到别人看不到的。比如，这里公布了一些数据，说事务数41亿，41意味着什么?支付宝都是 Oracle数据库做的，这个数字没有什么概念，太大了，已经不知道意味着什么。如果换算成每秒，就是4万7000秒。如果支持每秒4万多笔，将近5万笔，这意味着我用什么样的IT架构支撑它?一台可以支撑吗?我没有见过那么高容量的单机系统，支撑不了。什么样的架构呢?所以，后面又有一个数据，将这个数字除以20，那就是每秒2000多的事务数。刚刚讲了银行1秒钟1300多，但是，如果支付宝峰值的时候呢?10倍交易量，这个数据又上升到2万，不是单一的数据库可以支撑的。如果再除以20，就是4到5000，就可以支撑了。
这个数字跟我刚刚说的那个数字非常像，就是前面表格里另外一家电子支付的公司，每秒到4000多，将近5000。所以如果有这样的数据，就可以把整个IT架构推算出来。更可怕的是什么?另外一个数据，比如说，还公布了数据当天的业务交易是1亿5000万，1亿零500，两个数据一对比，就知道一笔业务要执行41个Trans。你是算的出来的，在座有很多做金融的，你算一下，我做金融的交易，哪些是要分事务?做多少的事务?可以推算出某一个数据是不是不合理?所以，从这以后不再发布这个数据了。但是，我想说的是通过我们分析可以看到一些有意思的事情，这个就是性能数据。
这里可以看到这个系统处于非常高的等待。前台提交一个数据的时候，Oracle后台要写日志，通知前台以前，整个就是处于log file sync 的等待。这个跟后台紧密关联在一起，意味着后台写，写和操作又是串行的。前台的等待就是4000多用户可能都同时处于这个等待。所以，看起来是非常惊人的。但是，我们最重要的是什么呢?就是看一下后台，如何看这个后台呢?log file parallel write 有一个相应的等待时间。所以，我们不仅仅看表象，我们要看真实的情况，要看写日志的过程。下面是这个数据库里写日志的数据。
这里有两个内容需要做一个简单的计算。第一，这个数据库现在运行了300分钟，300分钟是多少秒?1万8000秒，然后，我们计算一下，当前的日志等待是1万5000秒，这意味着什么?因为我刚刚讲了Oracle写日志的一个进程是串行的。工作1万6000秒，意味着这个峰值能力非常接近了，还有2000多秒工作时间，如果2000多秒都满了，就已经累死了，就是全负荷，不间断工作。这是这个系统瓶颈所在。这个系统负载百分之零点几的时候，整个很低。单进程的日志已经满负荷工作了，所以，如果这个系统的压力再上一下呢?这是这个系统的问题。
如果我们已经知道了这个问题，我把它很容易地讲给了大家，但是，分析这个问题的时候，触动了很多专家。我们最后帮用户把它解释清楚了，很难的一个事情，我们把它直接讲出来了。我们知道了这样的一个问题，这样的一个现象，如何解决这个问题?我其实只有四个字给大家，就是大道至简，一个问题找到根源了，如何去解决它?就是看这个数据库产品特性，有什么特性和功能可以支持你去消费这个状况。所以，解决很简单，但是定位很难。我列出一些问题的解决方案：
1、如果写日志慢，可以提供高速的存储加快日志，减少Log File Parallel Write等待。
2、合并短小事务，降低每秒处理的事务数量。
3、这个是终级手段，有另外一个参数可以设置COMMIT_WAIT=nowait。Oracle有一系列参数可以设置，但这样会带来不一致性的问题。所以，一般很少采用。
4、增加实例，分担单个实例每秒处理事务数量。单一数据库如果在日志写上，可以做成集群，分散负载。
5、数据库级切分，增加新的数据库来分担每秒处理事务数量。
6、数据库版本升级到12c。Oracle认识到，日志写的时候遇到了瓶颈，软件上面有问题，
所以，12C新版本里面，把日志写变成了并写，有助于缓解这个问题。
我讲了Oracle数据库优化，大多数的优化都是一样的。根据瓶颈找出相应的解决方案，然后，不外乎就是分分合合，提高并发，提高整个的承载能力。
我们把问题分析清楚了，是因为一个单进程问题。那么，如何验证它?客户会说，你不仅要说给我听，要证明给我看。如何证明呢?因为它的日志是落地存的，有一个同步复制系统，意味着日志写了两份，我们认为这个复制带来了额外消耗，至少是一倍的消耗，堵塞了这个快速性。对于用户第一个建议，把同步复制剔掉，看一下单机系统下的性能，验证是不是因为这个问题所导致的。
我们可以从数据来进行对比，最初的状态，300分钟，9万9600秒的等待，占了47%。当我们把用户的同步复制剔掉后，300分钟变成4600秒，4万9000秒的等待，占了29%，这是线性的，正好就是一半。
所以，通过这样一个分析过程，我们最终帮用户把问题找出来，并且证明了出来。然后，就可以去相应地做一个解决方案。
到Oracle 12C，提供一项技术，叫做scalable LGWR，可以让日志变成一个架构，最终提供100个并发，改善它的性能。Oracle数据库整合过程当中，在Oracle12C以前，将很多用户扔在一个数据库里，这是之前的模式。整合虽然带来了优化和改进，但是，这种模式下整合是非常的复杂。所以，在Oracle12C里面，提供了新的功能——多租户。多租户下，Oracle可以构建一个CDB容器，非常非常像容器的实现。构建一个大容器以后，其他的数据库可以做一个子集插接进来。
接下来我分享一个互联网金融的客户。互联网金融面临的就是快速增长，一年数百倍的增长。这是一家我们的客户，发展一年后，系统里面将近1.5亿注册用户。系统爆发式增长，面对大量的问题，对于很多新兴企业、互联网模式企业，想要快速奔跑的时候，通常还是选择成熟稳定的系统，方便它快速研发。所以，最初都是选择Oracle，最后证明商业模式是可行，当然以后可能会转变。所以，我觉得一个公司在不同的阶段，选择是不一样的。
他们在选择Oracle的时候也会面临一些问题，我分享一下我们的解决方法。当用户遇到非常严重的瓶颈以后，我们如何去帮助他?预测规划容量，就是选择一个适合他的基础架构，这个是核心。跟我前面的思路基本上差不多，前面那个思路就是基于现有平台，根据性能做推荐。这个系统，我是根据现有的压力去推测，根据未来的增长预期，去设计未来的压力。
我们首先也是一些方向上的。比如，从CPU资源的消耗来看，当前系统的1/8配可以承载什么量，如果我把1/8配扩成满配单节点会怎样，这就是几步推演，1/8配单节点大约承载45倍业务，满配就是90倍。如果扩成多节点会怎样，其实这里不是核心的问题了，这里90倍，已经可以承载一定阶段了。再往下，就是评估其他的资源，比如IO等。这里我主要讲一下思路，根据现有系统运行的负载率，我会计算把这个系统跑满后需要的一个资源量。然后，再测算一下将来需要几十倍增长率的时候需要的增长量。核心就是Oracle在高并发情况下需要解决的一些问题。如果是多节点，考虑的就是心跳交换量，还有性能。综合考虑这些因素来推测未来的压力。我今天就讲到这里。
