放翁（文初）的一亩三分地

http://t.sina.com.cn/fangweng

优化杂谈

Author :放翁

Blog：http://blog.csdn.net/cenwenchu79/

         当应用遇到规模化问题的时候，就是考虑性能优化的时候了。今天同事和我聊起了NIO在客户端的使用与BIO有什么优势，也勾起了我前一阵子和其他同学交流优化的一些想法，纯粹个人的一点想法。

CPU利用率和Load

         在过去做压力测试的时候，我们经常会关注两个指标，CPU和Load。有同学觉得CPU利用率上去了Load肯定也上去了，Load上去了CPU利用率同样会上去。但是在一些需要优化的场景下，常常会看到Load很高，CPU利用率却可能比较低（多核更是可能出现分配不均的情况）。Load其实就是等待处理的任务队列，当你的应用在等待同步消息返回处理的同时，CPU还是会将时间切片分配给这些线程，而真正需要CPU的线程，却不得不在到了时间片以后暂时放弃工作被挂起。因此在程序设计的时候就要考虑如何利用好CPU的这个资源，如何均匀的将压力分摊到各个CPU上（有时候就一个线程在不断循环，导致单个CPU负荷很高）。

NIO在客户端的使用

         Http消息设置keepalive和采用NIO的方式复用信道、BIO结合连接池的方式，最基本的目的就是降低建立TCP产生握手的成本，最大限度的复用已有的资源，但是否NIO就只有复用信道这点呢？

         NIO和BIO在数据传输和处理的模式上有不同，NIO采用的是BufferPacket+Channel的模式，这其实和操作系统本身的传输模式很类似，而BIO的Stream的模式是Java自己独特的模式。在采用NIO的这种数据传输模式以后，可以充分利用操作系统本身对传输的优化，因此这是一方面好处。另一方面异步和事件机制的使用，可以降低对于昂贵的资源申请，在高并发下提高处理能力。

NIO客户端的编程模型最大特点：依赖反置，松耦合带来性能提升。在请求流程协议中支持“票根”，也就是我们说的回执。例如，你今天面试完了，不需要你在阿里巴巴前台等着结果，直接留个电话，有消息就会直接通知，电话就是通知结果和服务请求者的关联手段。（此时阿里巴巴前台和会议室就会有足够的空间给其他人来面试，这就是资源）

         服务端使用NIO就不多说了，这里主要说一下在客户端的使用场景。两者是否真的有很大的差别，是否NIO有绝对的优势，其实还是和场景有关。简单说来就一个判断标准：应用对于通道的利用率是否够高。下面列了4种场景：

1． 一次请求数据量很少，服务处理速度很快。

2． 一次请求数据量很多，服务处理速度很快。

3． 一次请求数据量很少，服务处理速度很慢。

4． 一次请求数据量很多，服务处理速度很慢。

场景1，传输效率很高，服务处理速度很快，一次请求很快就被完成，采用NIO和BIO，在性能优势上除了操作系统对NIO的优化以外，BIO连接池不输于NIO。在易用性上，BIO更加容易处理。（NIO的异步机制，就要求消息传输协议需要有会话码来提供异步处理入口选择如何处理）

场景2，传输过程比较长，消耗时间比较多，服务处理速度很快，因此交互的时间大部分都还是在数据通道传输上，由于NIO在传输过程中依然是串行化的，因此BIO的连接池优于NIO，同时NIO一个客户端只有一个通道，因此BIO开的连接池越大，并行处理能力越强，因此BIO效率比较好一些。

场景3，传输量比较少，服务处理比较慢，很明显这是通道利用率低的表现，NIO有绝对的优势，特别是在高并发下。信道和服务端客户端资源被充分利用。

场景4，传输量比较多，服务处理也比较慢，这时候可以发现信道利用率取决于服务事件和传输消耗时间的比例，这类场景某些情况下BIO也会优于NIO。

单线程和多线程

         在使用多线程来优化程序的时候，是否考虑过多线程的使用场景，多线程不是万能药，在某些情况下还可能是毒药。使用多线程的过程中，需要考虑这么几个因素：

1． 资源竞争，复杂度增加。

为什么前面提到的NIO客户端在处理数据流发送和读取的时候都是采用单线程，数据流的发送和读取都是在一个数据通道上的，而读取和发送本身时间消耗是固定的（不论是多线程还是单线程），同时增加了复杂度（需要处理数据包整合问题）。这其实就是在资源上的串行化操作直接导致了任务的串行化，因此任务多线程反而起到了反作用。

2． 是否是关键路径的工作，占关键路径的比例。

首先，在优化以前需要考虑优化的内容是否是关键路径的工作，如果不是，那么增加复杂度实现的多线程模式，就没有价值。其次就是看是否是在关键路径中占有比较大的比例，同样的，还是投入产出比例（多线程带来的复杂度以及在高并发下的一些资源保护措施都需要很多的维护成本）。

3． 任务的合理切分。

在NIO的客户端，接受数据的事件将会写得很轻量级，但是接受到数据然后分析数据还原成业务对象，则会通过线程池的方式来分别处理。就好比监听连接到来，和实际的去建立连接分成了两个阶段的任务，让事件型的任务单纯，快速执行，让与业务相关的部分通过多线程并行的方式提高处理效率。总的来说就是把任务划分成为系统性的任务和业务性的任务，前者消耗时间少，设计尽量简单高效，采用单线程处理即可，后者通常情况下在处理流程和资源上不冲突的情况可以通过多线程并行提高效率。

         优化应用关注点：

A．关键路径是否可以优化，关键路径的任务拆分。

B．关键路径上的单个任务是否可以拆分并行执行。（是否有资源竞争，是否会有流程上的前后依赖，是否增加复杂度引入新的不稳定因素）

C．系统资源和依赖外部系统是否会成为瓶颈。（单机的CPU,IO都会在一定的压力下成下降趋势，并行执行反而降低了处理能力）

因此，可以看到不论是MapReduce设计下的Hadoop，还是Erlang语言级别的特性，都尽量的希望任务之间可以并行执行，相互之间低耦合，通过异步事件消息通知方式来交互，同时数据没有共享，防止资源竞争导致无法并行高效处理。系统设计还是要根据场景来判断使用什么方式优化，越简单越好。

    中午左右收到一个看我blog的朋友的邮件，最近他在研究mapreduce，然后想用hadoop来做一些工作，不过遇到了一些问题，我这边也贴一下他的几个问题，同时觉得自己把自己的一些看法分享一下，当然只是自己的一些想法，也许对新学习的同学有帮助。

   问题：

1. 从Map（K,V）的方式来看，难道mapreduce只能做统计？
2. 目前我想除了日志分析之类的功能外，还想做一个全文检索的功能，类似windows查询一下，通过关键字查询文件的位置即可（可能还要根据匹配度做排序），这个我很迷茫不知道怎么下手，痛苦ing
3. 你的实践是一个单机模式，如果用户把一个1G的log已经上传到hdfs了，此时分割工作已经完成，只需要从client那里得到文件基本信息和块的location就可以了，那mapreduce怎么进行下去呢？

   我给回复的邮件内容：

   首先，MapReduce的思想和Hadoop的MapReduce的架构不是一个概念，说的具体一点也就是Hadoop的架构设计只是MapReduce的一个子集思想的实现。每个人都可以根据自己对MapReduce的理解去实现业务处理，简单来说多线程处理就是MapReduce的一种最简单的实现，复杂来说多机协调工作就是一种复杂的实现。

   MapReduce的思想里面最值得借鉴的：

   a.问题分而治之。（找到流程的关键路径，优化可以并行处理的工作）

   b.计算靠近数据。（这也是hdfs存在的最重要的特点，计算的转移往往要比数据转移廉价，特别是对海量数据的处理）

   c.数据规模化随着并行处理成数量级递减。

   剩下的内容就是各个框架对于非业务性需求的处理，例如容灾，如何尽量少穿数据协调处理等等。

   针对他提出的三个问题：

    1. Hadoop的mapreduce从架构上来说最适合的就是统计分析计算。做其他方面的工作需要考虑是否适合，而不是为了技术而技术，先有需求再有技术选型。
    2.  对于你这个需求直接用搜索技术实现就可以了，不一定要硬套在mapreduce上。
    3. 对于海量数据是否一定要到hdsf上，或者就简单得数据物理或者逻辑切割来直接处理，根据自己业务场景选择。hdfs的特点就是对文件切割，容灾，数据逻辑存储和物理存储无关性（便于扩容管理，同时也是计算靠近数据的技术保证）。

    是否使用MapReduce框架，HDFS存储关键还是看你是否真的需要，当现有框架对自己来说并不合适的时候可以对小规模问题定制MapReduce的处理，最简化就是你去多线程或者多进程处理问题，需求决定技术选型。

当前问题:

1.       不小比重的Rest请求都是无效请求，全部接纳数据消耗比较多的时间。

2.       Multipart类型的大文件流请求无法做到合理快速过滤。（参数错误请求，数据文件过多请求，文件大小过大请求）

归结来说，TOP平台处理的服务在解析参数时比较消耗时间和带宽(客户端网络速度慢导致传输字节流比较慢，文件比较大导致带宽占用严重)

处理方式：

通过自行解析字节流方式来lazy化处理请求，减少无效请求对于解析参数时间消耗（导致web容器连接消耗）及带宽消耗。

优化目标：

         Get由于内容长度有限不列入在优化范围。

         优化Post方式的请求（普通的和Multipart），要求优化后：在正常请求处理上两者处理速度不低于传统方式，非正常请求在策略命中情况下（后面会谈到什么情况下优化失效），性能有明显提高。

具体实现：

        由于现在用的是传统IO模式，因此可以用流的方式来lazy解析和处理请求（NIO用channel + buffer package就无法lazy了）。

         一共有三个组件角色：

1． 请求处理配置策略：配置在解析参数时，优先的规则（参数可以从header,uri,post body中获取，相互之间的优先性），异常抛出规则（字节流长度，文件大小，文件个数限制等），字节流解析模块的参数配置（字节流解析的窗口大小，超时时间等）。

2． 线程上下文：用来保存处理过的请求参数。一来复用，二来也是由于请求字节流处理不可逆（不保存字节流副本），必须保留。

3． Http请求字节流解析模块。根据具体的配置以及解析策略来解析字节流，同时将解析结果保存在线程上下文中。主要的实现代码在于对Post消息体逐步解析部分（普通的Post和multipart）

压力测试结果：

•    正常请求场景（ 100并发用户，multipart 文件大小300k，当前业务场景这个值已经满足了）：

普通post的处理能力1000TPS。（servlet方式处理差不多，不过有波动）  

  multipart处理能力610TPS。（apache开源项目fileupload，处理能力400TPS左右）

错误请求场景

         异常情况的处理有了很大提高，对于远程客户端传输较慢或者是大流量图片的错误请求都有很大的优化。

优化存在问题：

1． 参数缺失导致优化失效。

2． sign类似的交验，导致获取所有的参数。

3． 当前图片限制在300k，由于考虑处理速度快，就都没有设置超过阀值存储到本地，因此在高并发大流量的情况下也会有内存问题，当然已经做了部分保护。

针对上面的两个问题，作了部分的协议限制，对于API2.0希望将所有的系统参数和业务参数区分开，放入到Http header中或者url中，这样可以避免系统参数缺失导致优化失败，同时大量过滤系统参数出现问题的无效请求。

Sign类似的交验放在流程最后，避免过早获取所有参数。

作安全保护，设定简单丢弃或者io交互来缓解这个问题。

         这部分内容还有很多可以做得工作，其实最初的目的就是为了防止系统对于无效请求的处理消耗，我想在很多系统都会有这样的问题，利用缓存设置黑名单防止攻击也是这样的初衷。因此这点可以考虑在很多系统设计的时候都作一样的优化，对正常的不能优化，起码对错误的可以做一些优化，防止在异常请求高涨的时候，系统被击垮.

其实想说这句话很久了,和很多同事接触,有时候或多或少的都会发现大家会陷入在自己的一亩三分地里面.

         主要表现得症状

1.       PD的需求就是目标，踏实的实现，不懂的就猜。

2.       经验盖过一切，设计系统就是要够完备够复杂。

从开发人员角度来看，第一种人多半比较有自己的想法，同时也有不少的工作经验，同时可能对技术比较着迷。另一种人多半是刚刚工作或者经验不足，要么就是习惯性把工作当任务，而不是爱好，写程序也就是一份赚钱的活。但看起来其实各自都在自己的一亩三分地上捣鼓，忘记了作为一个开发人员最基本的原则：“满足客户需求”。

先说1类型吧，在我们的Team有一个刚毕业一年多的同学，很勤奋，不论从学习以及工作，实实在在，踏踏实实。我们这边来需求，通常大需求我们都会全体过一下，一些小点的需求他就自己考虑一下就作了。那天正要上线，突然说了一下设计修改的内容，发现不仅满足不了PD原有的需求，而且给系统带来了缓存暴增的隐患。然后找来PD一谈，其实他要的功能已经在现有系统中已经实现，只是需要做部分的修改，而不需要新的去建立一套机制。这样的情况其实在前前后后出现了不少次数了，但其实一直没有和他细谈。后来我下班时候和他一起回家的时候说：“很多时候， PD为了让你理解，从开发的角度想要去描述一个需求，但其实最终失去了他自己想要的东西。因此对你来说第一步不是急忙的去考虑如何实现PD的想法或者和他争论他的设计是否合理，而是需要先问他：你想要什么，想要实现的东西最终目的是什么，能满足客户的什么需求？当他能够说清楚他想要什么，也知道要的东西能给客户带来什么价值的时候，我们再回过头来看，究竟应该怎么做？”这其实和我每次和同学分享一些设计的时候步骤是一样的，首先为什么要这么做，然后才是考虑如何从我的目标去寻找行动的方法方式，不然你会发现你和别人讨论了许久的东西，实现出来的时候已经背离了你的目标很远。因此在做任何需求或者设计的时候第一个问题就要问自己为什么要做，作的过程中时刻要记得我的目标是什么。这让我想起了我在离开阿软的那些日子和王坚博士谈话以及听他的一些对于设计的理念，很多时候还没有到规模化的情况下，先解决客户的需求，在解决客户需求以后，逐步的去考虑规模化问题的设计。（当然不是说第一版设计就可以随便作，良好的基础能够提升后续改进的速度）。

二类型的就比较多了，其实是很多开发人员的通病，包括有时候我自己也会陷入这样的误区。通常情况下有两种场景会陷入这样的误区，同时当事人却又不愿意改变。第一种情况就是觉得自己有不少的经验，同时对技术很执着，希望设计出来的都是很完美的，一次发布就可以满足个1，2年，但其实从这些年的设计角度来看，首先系统都是不断迭代进化的，因此一步到位的说法基本上不靠谱（除非就是一模一样的场景代码重复使用），其次系统的架构要做的足够灵活，通常情况就需要先做核心功能，预留出足够的空间和切入点，这样对未来扩展和需求变化有足够的适应度。从这两点来看，其实设计初期就是要求找到客户最想要的，扩展可以实现客户可能要的，防范客户没有估量到的。但这其实就需要和我们的产品设计师有充分的交流，好的产品设计师不会告诉你你怎么去实现，但是他会告诉你我想要的是什么，这些能给客户带来什么，这时候你可以告诉他我能够通过什么方式来满足你的需求。这样的开发和产品设计交流的结果才是技术化的产品，大家各司其职，同时也通晓对方领域的一些情况，对对方领域的只能给出建议，不是指导，这点在TOP我很庆幸有很好的黑羽同学，我们的交流就是这样产生良性互动。这有点撤远了，刚才说了第一种场景，然后说说第二种场景，就是初期其实大家都没有明确细节，但是在实施过程中开发人员会根据自己的接触面来选择一些技术和架构设计，最后看起来很复杂，很完美，但其实越是复杂的设计背后有越多的隐患。但是此时因为已经设计好了，就不愿意再去简化，也不愿意听任何人的意见，其实这是很危险的。我过去也犯过类似的错误，但是其实当你冷静下来，想想那句话，我们的目标是什么：“满足客户需求”，这时候你就会考虑，这么复杂的系统会不会给客户带来更多的不稳定以及复杂度，其实客户不关心你背后如何实现的，但是你需要满足客户的最基本的需求，用起来方便，高效，实实在在提供了解决问题的手段。

今天下午面试了一个外部的同学，工作年限比我长，看了简历也经历了很多项目，同时在描述的时候写了对高并发，分布式等等都很熟悉和热衷，我开始看了简历就担心，可能我这边不一定要他，因为我怕他开口就是说一大堆如何做高并发和分布式的内容。在我看来如果你没有搞清楚你什么时候要用牛刀，什么时候要用剪刀的人，和你谈论牛刀的构造其实没啥意思，因为在我看来，技术只要你肯花时间去学，没什么学不到的，但是做事方式和项目设计经验却是长时间积累的。幸好今天和他一谈，他对于技术的态度以及架构设计的思想都和我想的比较接近，不是为了技术而技术，不是为了过程而过程，了解如何从简如繁，再从繁入简，最终能够找到自己的目标。当然后来还是谈了很多技术细节的问题，毕竟干活还是要一个好手，作了那么多年如果没有经验和技术积累也是很可怕的事情。最后我问了他两个问题：1.你学习一个新技术的过程是怎么样的？2.你和你同事如果在设计方案上有冲突你怎么解决？他告诉我他学习新技术首先会去考虑这个技术的特点是什么，和其他技术的差别，他的擅长领域是什么，这样才能够用到实处。第二个问题他和我说就是开会讨论，最后大家群体决定。我对他第一个问题感到很满意，因为我就需要这样的同事，第二个问题我给了他一个建议，其实在很多时候，将别人的架构设计的优点融入到自己的设计中，不再以方案作为边界，那么大家最终就很容易达成一致，因为你在接受别人的思想时其实能够看到自己的不足，同时对待别人不是用否定的态度，会让你更容易得到认可和接受。（这点作起来需要不断的改变程序员自身的好胜个性，我起码还是出于变化中…）

我记得我小时候上政治课的时候，老师给我们划分了三种人：有能力但是没有道德的人是危险的人，没有能力但是有道德的人是对社会无害的人（觉得像葛优说的那个对社会无害的海龟一个概念），有能力同时也有道德的人是对社会有益的人。我觉得其实程序员也就可以从两个纬度看：

1.       有能力，有经验，对技术有追求。

2.       对产品化和客户没有任何感觉。

拥有了素质1但是没有素质2，那么最多也就只能说是试验室的花朵，在大学搞搞研究还不错，实际要做出产品来可能就是纸上谈兵，好钢始终用不到刀刃上，有力没地使。

素质1有所欠缺，素质2很明晰，对自己目标不断追求，其实这样的人，有时候笨鸟也会飞的比聪明的鸟更高。

拥有1，2的人，当然就是最好的人，只需要学会做人那么就可以发挥自己的能量。（程序员有时候就是很难改变自己的个性，去学会如何沟通和理解）
         最后一类就是自以为有1和2的人，这类人最怕就是面试的时候被考官通过，那么后续的问题就大了。

说了怎么多，其实也无非想说出一个程序员这些年的经历，从做开发到做基础平台，到做业务平台，该怎么踏实做事，该在什么时候找到自己的瓶颈，该在什么时候改变自己的状态，都需要自己好好的让自己冷静下来想想。做基础平台需要耐得住寂寞，同时也要知道自己是有客户的，服务不好客户，那么基础组件平台就是玩具。做业务平台需要学会去分析和沟通，需要去了解每一个层次的设计如何协作，同时在兼顾业务需求的同时满足隐性需求（稳定性，可用性，响应速度，规模化等等）。但归根到底，能给开发人员不断能量的不是技术本身，而是你用技术给你的客户带来的价值，对你的认可是长期做事的一个最基本的动力，因为当你现在觉得纯做技术能够支持你不断向前走的时候，其实在不远的将来你会体会到原来过程和目标是同样重要的。走出自己的一亩三分地，给自己多一点的空间，会让自己看得更远，走的更高。

   今年blog更新的速度比去年慢很多，当然最大的原因就是工作的转变。当选择留在云公司还是去淘宝，自己做了很快的抉择，去淘宝。其实在阿软的后面这一年，对自己来说是一个技术提升的阶段，工作任务不紧，技术预研范围较大，但对于自己这么一个已经到了30的人来说，应该是把技术转变为产品的时候了，因此义无反顾地选择了TOP作为我新的开端。

    其实每个人都会有自己不同的阶段，任何阶段都有自己的目标，同时当你发现在一个阶段停留很久，都没有什么突破，或者渐渐失去目标的时候，那么就需要考虑如何找到新的起点。对我来说，技术追求和提升是没有止尽的，但是需要真正的将所学的作出一点实在的产品，同时在参与产品团队的过程中，学会沟通，交流，分析问题，全面地看问题，这些也是不可缺少的成长经验，如果仅仅局限在狭隘的某一个技术立领域，那么就和普通的学生无异。

    到了TOP，自己的工作分成了三大块：1.救火及防火。2.整体架构支持。3.核心代码的编写。前期花了不少时间在1上，同时和各个Team交流，参与各个团队的关键性设计评审，以及对平台的统一规划，让我实实在在的作了一点2的事情。（说道实实在在，记得在阿软很多团队都抱怨我所在的架构组整天派一个人挂个名字，然后就算是架构支持了，当然这有很多原因造成，并不一定是负责架构的同学的问题）。对于3这点当然是自己最乐意做的，也是自己一直告诫自己要不断提升的，不论自己有多少理由说自己忙碌，写代码是我们这种人的生命所在，不然就会漂浮在空中，渐渐的走向“另一个世界”。 但自己觉得其实还少了一块，就是对业界的发展深入了解，这会让我看的不够远（幸好我们的产品经理黑羽同学总还会给我一些新的思路），到了年底将会多花一点时间作这部分内容。

    去年年底我写了关于对于Open API的思考和探索的一篇文章作为年底总结，今年一样，对于当前自己的工作将会有一份总结和规划，即是对今年平台发展的一个回顾，也是对平台未来的一点思考，大致已经列了一个纲要，对外可能部分内容不能全写出来，不过就算不写细节也会将一些思路写一下，大家可以相互探讨一下。这部分内容也将会成为我12月份参加淘宝内部淘宝大学讲课的内容，希望能够将今年新进淘宝的同学吸引到TOP来，为TOP增加人气。

   下面是一个mind 图，大致描述了一些内容：