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 图，大致描述了一些内容：

   今天是转岗到淘宝的第七天，也算是一周吧，期待来这个团队已经有快大半年了，这次阿软的重组给了一个机会，过去的就过去吧，不再回首有任何的抱怨和遗憾，需要面对的是新的将来。

    很奇怪，来到淘宝，都是熟人，Boss是早就相识的菲青，TOP团队的自雪，凤先，秀芳及我不认识但是认识我的其他同学都很热情，运营，PD,OST都是以前阿软的老同学，还有其他几个团队的朋友，感觉回到了家，而不是离开了家。

    原先来淘宝是比较坚决的，同时也得到王博士的支持，心里还是比较有底的，不过就是担心过来以后和淘宝已有的团队合作可能会有磨合期，因为担心有“小圈子”。结果却是很出乎我的意料，TOP的人就和做的事情一样，是一批开放的人，自雪，凤先，张三各个都很放的开的和我聊，对于架构，对于技术，对于未来的发展，这些人坐在一起什么都可以说，自己觉得自己早先是用老思维来看待这个团队了。这个团队很年轻，很有活力和创造力，缺少的只是一些经验，而我经验是有一些，但是那些斗志已经在去年一年被磨砺的差不多了，正好是我回炉好好再热一热的时候了。来之前就和黑羽有过接触，也看过他对于TOP的一些构想，在我的计划中就有和他交流的部分，上周找了一个时间碰了一下，果然有很多和我一致的想法，同时还有一些比我更加深入的idea，特别是对于大淘宝未来的一个构想。其实来到TOP我所要做的就是在技术的架构上找到商业的感觉，让商业驱动技术，技术沉淀积累来支持商业的畅想。

    这七天过的很快，全身心投入的工作，时间总是过的很快，而且过去那种沉闷的心情和处事的态度在这里得到了改变。明天基本上就看完了TOP的大部分代码，整理了一些review的建议，同时昨天还花了一些时间去看了看google appengine，写了几个小应用，看了看源码（部分反编译），因为要给boss对于小应用hosting方面的一些想法。

   总的来说还是和我原先的计划一样，商业上和PD运营交流，了解未来TOP商业发展方向，以及对技术架构的一些需求。架构上从代码和文档看起，文档不是很多，所以就只好每个工程看过来，也不错，看到自雪同学写的代码还是不错的，同时也看到了淘宝的基础组件的推广力度之大，这比在阿里软件强的多，其实也是我一直希望看到的，人人都是技术牛人，都在做重复的事情，但是却没有技术沉淀，其实大家完全可以吧自己的构想增强在别人的基础之上，而不是什么都自己搞一套，淘宝的技术应该来说在政策上得到了支持，技术积累效果还是不错的，这里还不得不提到我的淘宝同学毕玄同学的服务基础框架HSF，虽然现在还没有接触，但是应该已经发展的挺好的。

   有两个能够用人，担得起起技术团队发展的Boss，有这么一些年轻有冲劲的小同学，有这么一些乐于倾听分享协作的老同学，有这么一些很有商业feeling的非技术团队同学，要做好TOP，我想只有三个字：“没问题”。这是我在入职七天写的随记，一年后再来回看我今天说的这些话，在来看看这个团队创造的价值。

   附：在淘宝申请好了花名：放翁。陆游的字，武侠小说的人就连扫地的都没有了，历史名人也没有了，不过诗人倒是没有人用，指不定还开创了淘宝同学入职的花名新取法。

   好好工作，天天向上，为了TOP，为了家里的BB，为了自己的一点理想，踏踏实实的走自己的路，让别人开车去吧，^_^

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/cenwenchu79/archive/2009/08/12/4440248.aspx

   昨天是去淘宝工作的第一天，最近最头痛的就是花名，在我儿子出生的时候我就知道起名字是最麻烦的事情，而起花名更是痛苦，因为你的选择余地更小，同时还不能和前人重复，好不容易找到两个还不错的，结果一个给其他部门的老大保留了，一个因为拼音和一个同学相似而无法使用。想用文初，结果还给一个淘宝的活跃用户使用了，问了HR不取花名是否可以，回答说，不可以，太折腾了。

   昨天开了一整天的会，主要还是协调两个平台之间将来的合作模式，同时也梳理了双方的现有功能，将未来双方的边界做了初步定夺，同时也对将来的一些需求做了初步的规划，系统的模块化也提上了最近的日程。

  今天会化一些时间看看已有的代码熟悉一下Top的情况，同时也看看一些流程性的文档，希望能够尽快的对Top全方位的了解，这样便于从细节实现到整体架构设计都能给出自己的意见。

  初来乍到不容易，很多需要从新开始的，不过对我来说合作的人，做的事情还是有一定的基础，因此只是需要一周左右的过渡期，后续应该会走的更加顺畅。

Author : 岑文初

Email: wenchu.cenwc@alibaba-inc.com

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

Date: 2009-5-26

目录

需求转而学习

“软”负载均衡

LVS （Linux Virtual Server）

Virtual Server三种模式介绍

Virtual Server三种模式的比较

Virtual Server三种模式实践

三种模式下的简单压力测试

HA-Proxy

HA-Proxy安装和使用

HA-Proxy的压力测试结果

“软”负载学习心得

需求转而学习

         很多时候不少做开发的同学都认为技术更新的快，新技术、新概念层出不穷，大家乐此不疲的去跟随着所谓的“技术趋势”走在风头浪尖上，但其实往往忘记了一个最重要的问题“满足客户需求”。其实技术就是为满足需求服务的，用最小的代价来满足用户的需求，以最简单高效的方式来达到目标，就是每个开发者应该追求的。（不要因为自己的架构很简单就脸红拿不出手，只要你在满足用户当前需求的基础上对未来有所考虑，那么化繁为简就是一种能力的表现）

         SIP（服务集成平台）5.7版本中对于未来多个服务提供商，多种类型的服务，在每日几亿的调用压力下，需要找到一个解决方案：可以分流不同服务提供商的服务，分流不同类型的服务，服务隔离化来减少服务相互之间影响以及服务提供商之间的影响。

         当前SIP的前端是通过硬件F5作负载均衡，因此是无状态无差别的服务负载，这也使得无法区分不同的服务提供商的服务请求和不同类型的服务请求，导致服务提供商之间的服务会产生相互影响（旺旺即时通信类API在峰值占用了大部分的服务处理资源，淘宝宝贝上传类API占用了大量的带宽）。近期还有更大的两类API将会接入，因此寻找一个服务可分流的方案势在必行。（当然过去也考虑通过三级域名配置在负载均衡上来解决这些问题，但是这样首先对于开发者来说不透明，其次也是一种比较僵化的设计方案，扩展和维护也有一定的难度）

         在过去也尝试过Apache等Web容器自己的一些load balance特性，当然效果不是很好，和硬件基本无法比拟，而一些专有的“软”负载均衡方案和开源项目也没有深入的去了解，因此借着这次机会，好好深入的挖一挖“软”负载均衡。

“软”负载均衡

         作为互联网应用，随时都需要做好用户量突然增大，访问量突然上升的准备。今年热门的词汇“云”我就不多说了，这里就简单说说服务器的横向扩展。其实和DB，文件系统等一样，当资源成为瓶颈的时候，就需要考虑如何通过扩展或者提升资源能力来满足用户的需求，这就是我们常说的横向扩展和纵向扩展。（对于横向扩展和纵向扩展的优劣大家应该都很清楚了，这里也不做赘述）横向扩展中就会要求使用负载均衡的能力，如何根据资源能力不同以及资源在运行期负荷动态变化将负载合理分配是判断负载均衡优劣的标准。

         软件负载均衡一般通过两种方式来实现：基于操作系统的软负载实现和基于第三方应用的软负载实现。LVS就是基于Linux操作系统实现的一种软负载，HA Proxy就是基于第三应用实现的软负载。（后面会详细介绍这两种方式的使用）

         最早期也是最原始的软负载均衡：“Round Robin DNS”，通过轮询方式在DNS绑定多个IP的情况下，将用户对于同一个域名的请求分配到后端不同的服务节点。这种方案的优点：配置简单，负载分配效率高。缺点：无法知晓后端服务节点服务情况（是否已经停止服务），无法保证在一个Session中多次请求由一个服务节点服务，每一个节点都要求有一个外网IP。

         另一种较为常见的就是基于分发器的Load balance。服务使用者通过向分发器发起请求获得服务，分发器将请求分发给后端实际服务处理的节点，给客户提供服务，最常说的反向代理模式就是典型的分发器Load Balance。这类负载均衡处理可以基于应用级转发，也可以基于IP级别转发，当然基于应用转发效率和损耗比较大，同时分发器本身也会成为瓶颈。

LVS （Linux Virtual Server）

         LVS是在Linux操作系统基础上建立虚拟服务器，实现服务节点之间的负载均衡。LVS主要是处理OSI模型中的4层消息包，根据一定的规则将请求直接转发到后端的服务处理节点，有较高转发效率。

         Virtual Server是Load Balancer和一组服务器的逻辑组合统称，使用服务者只需要与Virtual Server进行交互就可以获得高效的服务。真实服务器和Load Balancer通过高速ＬＡＮ进行交互。Load Balancer能够将请求分发到不同的服务端，在一个虚拟IP下并行处理多个请求。

Virtual Server三种模式介绍

Virtual Server有三种基于IP级别的负载均衡实现方式：IP address translation（NAT）、Direct routing、IP Tunneling。

         NAT(Network address translation)：由于IPV4的某些缺陷和安全原因，某些网段例如（10.0.0.0/255.0.0.0, 172.16.0.0/255.240.0.0 and 192.168.0.0/255.255.0.0）不能被用于互联网，因此常常被用作内部局域网，通过网络地址翻译的方式可以让这些网段的服务器访问互联网或者被互联网访问。网络地址翻译主要作用就是将一组ip地址映射到其他的一组ip地址，当映射比例为1:1的时候通常称作静态映射，而当映射地址为M:N(M>N)的时候（M为被映射地址数量，通常是内部ip），则成为动态映射。而对于Virtual Server的NAT模式来说，就是利用了NAT的特性，将内部的一组服务器通过映射到一个虚拟的IP，然后以一个外网虚拟服务节点的身份对外提供服务。

         上图是一个实际的NAT范例，对外的服务IP为202.103.106.5，内部建立了虚拟IP为172.16.0.1，然后将内部其他两台实际服务的服务器172.16.0.2，172.16.0.3映射到172.16.0.1这个虚拟IP。客户端向202.103.106.5发起请求服务，Load Balancer查看请求数据包，如果是请求目标地址是注册的虚拟IP及监听端口的时候，那么通过NAT按照一定算法选择某一台实体服务器，再重写报文目标地址，转发请求到实际的目标服务器，当目标服务器处理完毕以后，将处理结果返回给Load Balancer，由Load Balancer修改源地址，返回给客户端。

         IP Tunneling：IP管道技术是在IP报文上再次封装IP报文协议的一种技术。允许将一个目标为A的IP数据报文封装成为目标为B的IP数据报文，在特定的IP 管道中传输。

         上图就是IP Tunneling模式的运作原理。首先客户端还是通过访问对外的一个服务IP请求服务，当Load Balancer接受到请求以后，检查VIP注册信息，然后根据算法选择实际的一台后台服务器，通过IP管道封装技术对IP报文再次封装，然后将消息通过IP管道转发到实际的服务器，实际的服务器通过解包处理请求，然后根据包体内实际的服务请求地址，将处理结果直接返回给客户端。

         Direct routing：利用Load Balancer和实际服务器共享同一VIP，简单的通过修改消息报体目标MAC地址，转发请求，然后再通过实际服务器配置VIP为本地回环，直接处理消息报文，而不再转发，当处理完以后，直接将处理结果返回给客户端。

         上图就是Direct Routing的运作流程，当外部请求到Load Balancer时，通过查找VIP注册信息，直接选择一台后端服务器作为新的目标地址，修改消息报文中的目标地址Mac地址，转发到目标服务器，目标服务器由于配置VIP在本地网卡回路中，因此直接处理消息，将处理完的结果直接返回给客户端。

Virtual Server三种模式的比较

         下表是官方整理出的关于Virtual Server三种不同模式的区别：

	NAT	TUNNEL	DR
服务器要求	无要求	需要支持IP管道	无 arp组件（当前也有补丁）
网络要求	Private	LAN/WAN	LAN
可支持后端服务器节点数	较少（10-20）	较多	较多
服务网关	Load Balancer	本身	本身

NAT：根据其实现原理，可以知道这种模式对于操作系统，网络都没有太多的要求和约束，但是由于消息需要打解包，同时消息的响应都必须经过Load Balancer，因此Load Balancer自身成为了瓶颈，这样一个Load Balancer能够支持的后端服务节点数量就有限了。当然可以采用混合模式来解决这个问题，也就是通过TUNNEL或者DR模式作为前端模式串联起多个NAT模式Balancer。

TUNNEL：这种模式要求操作系统支持IP Tunnel，通过对IP报文再次封装转发，达到负载均衡的目的。设计这种模式的初衷是考虑，对于互联网很多服务来说，服务请求数据量和返回数据量是不对称的，返回的数据往往要远远大于请求的数据量，因此如果请求和返回都走Load Balancer会大量占用带宽，影响处理能力。IP Tunnel设计中请求是通过Load Balancer，但是返回是直接返回到客户端的，因此节省了返回的带宽，提高了请求处理的能力。

DR：这种模式要求Load Balancer和后端服务器处于同一个局域网段。DR模式处理消耗最小，消息转发和回复基本没有损耗，因此效率应该是最高的，但是约束是相对来说最多的。

    小A，30，所在公司在去年的经济危机中没有倒下，但是在今年却倒下了。小A觉得能够把一个公司混倒闭了，也算是人生的一点经历。

    公司是没了，但是工作还要继续，生活还要继续，现在将要面对一个新的环境，环境很陌生，但也比较熟悉，工作职责很清晰，但也充满了挑战。人过30，有了孩子，真的成熟了很多，知道了什么叫做责任感，知道了未来真的需要好好规划，需要一个机会，需要一个平台来找到自己，实现自己的价值，不让这黄金时代就这么过去。

   小A将要面对的挑战在心里面已经做好了准备，也有了自己的一套短期的规划及工作安排，要成长有时候就要有压力。在小A即将离开原来团队的时候，和手下的一个同学发了火，因为在这阵子调整过程中，同学的心态一直变的很差，但是小A已经竭尽全力去分析他的未来，虽然听进去，但是过几天依然又开始放弃自己，这种态度让小A原本很看好他发展的心情变得很沉重，最后就在那个探讨会上说了他一些比较重的话，虽然说完以后自己也有些后悔，可能我对他和对我自己一样，要求太高了吧，就像博士说的，如果对一个人没有想法了，就恭维几句即可，大家你好我好大家好，只有当对这个人还存在一定的期望的时候才会表现出这种比较急切的感觉。

   新的开始，新的挑战，新的环境，新的机遇，新的难题，新的称呼

   好的心态，好的沟通，好的未来

   一切都需要小A用自己的能力去证明，走自己的路，让自己走的更好。

         这篇blog的问题不能算是解决，仅仅只是一种分析和猜测，后续的一些行动可能会证明一些猜想，也可能什么都解决不了。如果有和我相同情况的同学，也知道是什么问题造成的，请不吝赐教。

问题：

上周周末，没有和同事们出去Outing，在家管孩子，去生产环境观察了一下集群机器的当前运行状态，发现应用在这些多核机器上压力极端不均匀。

         Top一下大致状态如下：

         峰值的时候，单CPU的使用率都到了80%，这种情况对于多核服务器来说是很不正常的使用。对于Java的开发者来说，多线程编程是无法控制线程如何在CPU上分配的，因为Java本身不实现线程机制，说是跨平台的语言，但是性能及特性会根据操作系统的实现有很大的差异，因此Java调优有时候需要对系统配置甚至内核作调优。

分析：

         首先在测试环境下作了多次同样的压力测试，尝试了与线上一样的操作系统版本，相似的配置，但测试结果却是负载分配很均匀。

         此时重新启动了一台问题机器，发现负载降下来了，同时也很均衡，也就是说在当前的压力下不应该有这样高的cpu消耗，同时也排除了硬件或者操作系统的一些配置问题。

         在CPU满负荷的情况下，很多时候会认为应该是循环造成的，对于单个CPU的消耗更是。通过Top H查看具体到底哪一个线程会长时间消耗CPU。

         可以看到PID为13659的线程是“罪魁祸首”，但13659究竟在干什么，是应用的线程还是系统的线程，是否是陷入了死循环，不得而知。接着就按照Java的土办法，Kill -3 pid，然后看看输出日志。

         根据线程号来查找dump出来的日志中nid，发现这个线程是VM Thread，也就是虚拟机线程。（这里作一下转换，将13659转换成为16进制就是0x355b）

         用pstack看了一下这个线程的工作，结果如下：

Thread 2074 (Thread 1846541216 (LWP 13659)):

#0 0x0659fa65 in ObjectSynchronizer::deflate_idle_monitors ()

#1 0x065606e5 in SafepointSynchronize::begin ()

#2 0x06613e83 in VMThread::loop ()

#3 0x06613a6f in VMThread::run ()

#4 0x06506709 in java_start ()

#5 0x00aae3cc in start_thread () from /lib/tls/libpthread.so.0

#6 0x00a1896e in clone () from /lib/tls/libc.so.6

         搜索了一下ObjectSynchronizer::deflate_idle_monitors，发现了sun的bug库中有bug关于jdk1.6中由于这个方法导致运行期问题的说法：http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=803cb2d95886bffffffff9a626d3b9b28573?bug_id=6781744

         然后就直接去openjdk官方网站去查找这个类的代码，大致了解一下他的作用，具体的代码链接如下：http://xref.jsecurity.net/openjdk-6/langtools/db/d8b/synchronizer_8cpp-source.html
主要工作应该是对资源对象的回收，在加上pstack的结果，应该大致知道是对线程资源的管理。但具体代码就没有进一步分析了。

接着就分析一下自己的应用：

         压力测试（高强度、长时间）都做过，没有发现什么异常。

         本身应用是否会存在的缺陷导致问题呢。有人说VM Thread兼顾着GC的工作，因此内存泄露，对象长期积压过多也可能影响，但其实在dump的结果可以看到，GC有单独的工作线程，同时我也观察到GC这些线程的工作时间长度，因此由于GC繁忙导致CPU上去，基本上来说可以排除。

         其次在SIP项目中使用了JDK的线程池(ExecutorService)和LinkedBlockingQueue。后者以前的文章里面提到在1.5版本里使用poll方法会有内存泄露，到1.6虽然没有内存泄露，但是临时锁对象增长的很快，会导致GC的频度增加。

行动：

         上面零零散散的一些分析，最终让我决定有如下的行动：

1.       升级某一台服务器的JDK，当前是1.6.0_10-b33，打算升级到1.6的14版本。比较观察多台机器的表现，看是否升级了JDK可以解决问题。

2.       去除LinkedBlockingQueue作为消息队列，直接由生产者将生产结果按照算法分配给消费者线程，避免竞争，锁的消耗，同时也防止LinkedBlockingQueue带来的资源消耗。

3.       测试环境继续作长时间的压力测试，同时可以结合Jprofile之类的工具来分析长时间后可能出现的问题。

后话：

         这年头真的啥都要学一点，求人不如求己。

SA,DBA,测试都需要能够去学习一些，起码在初期排查问题上自己能够做点啥，要不然别人也忙，自己又无从下手。就好比这次压力测试好不容易排上队，但是还是满足不了及时上线的需求，因此自己去LoadRunner压，好歹给出一个零时的报告先大家看着。应用的异常有时候是应用本身设计问题，也可能是开发语言的问题，也可能是操作系统的问题，因此要去定位这种比较复杂的问题，真的需要有耐心去好好的学习各种知识，现在看来知识还是匮乏啊，要不然就可以分析出openjdk中可能存在的问题。

         昨天在看Cache Client代码的时候，发现在从资源池中获取SocketIO部分代码在高并发情况下效率不高，因此考虑通过一些变通的方式来提高效率，下面说的内容仅仅是当前自己琢磨出来可以部分提高效率的方法，希望看了这篇文章的同学能够有更好的方式或者算法来提高效率。

情景：

       Cache Client 的SocketIO资源池是一个两级的Map，具体定义为：ConcurrentMap<String, ConcurrentMap<SockIO, Integer>>。第一级Map以Host作为Key，第二级Map以SockIO本身作为Key，三种SockIO状态（可用，占用，废弃）作为value。之所以采用一个Pool来存储三种状态主要是考虑到在高并发下，多个池之间保持原子性的复杂。

每一次获取可用的SocketIO的操作需要经历：1.遍历Host所在的Map。2.逐个比较状态。3.原子方法获取可用SocketIO。（并发问题所要求的，具体代码可以下载：http://memcache-client-forjava.googlecode.com/files/alisoft-xplatform-asf-cache-2.5.1-src.jar ）。

在修改过去的版本里面，首先遍历的过程是一个固定顺序的过程（keyset），这样会导致在高并发的情况下，越来越多的资源申请命中率会下降，因为压力总是落在keyset靠前的那些SockIO上（重复比较）。需要考虑通过什么手段可以提高在高并发下的申请命中率。

思考：

1． 资源申请的越早，被释放的可能性越高，因此是否可以考虑采用更新SockIO最后申请时间来作为后续申请的初步依据。（本身复杂度带来的耗时可能会超过命中率降低带来的损耗）

2． 采用随机数的方式来确定keyset的起始游标，也就不是每次都从keyset第一位开始（可以把keyset看作一个首尾相接的数组）。

3． 在每次资源回收的时候纪录下该资源为可用（当前为每一个Host就记录一个可能可用的资源，简单化操作），作为申请的首选尝试。（尝试不成功在去遍历）。

当前实现了2,3组合，发现效果明显，在500个并发下，每个线程200次操作（一系列动作），压力测试结果如下：

Cache test consume(cache测试总共耗时)，average boundle consume（每个线程总耗时），average per request（每个线程每次操作总耗时）

没有作任何改动以前的测试结果：

cache test consume: 11507741, average boundle consume: 57538, average per request :115

采用了2策略以后的测试结果：

cache test consume: 10270512, average boundle consume: 51352, average per request :102

采用了2，3策略以后的测试结果：

cache test consume: 9140660, average boundle consume: 45703, average per request :91

       服务集成平台5.6的性能测试进入尾声，这期的优化也算告一段落。这次主要的优化工作还是在三个方面：应用服务器（Apache,JBoss）配置，业务流程，Cache Client包（http://code.google.com/p/memcache-client-forjava/ ）。这里把过去和这次优化对于Cache的使用作一个经验分享，希望大家能够用好Cache，提速你的应用。

       这里还是通过一些点滴的启示来介绍优化的一些心得，很多时候还是要根据具体情况来判断如何去具体实施，因此这里所说的仅仅是在一些场景下适用，并非放之四海皆准的教条。同时也希望看此文的各位同学，如果有更好的思路可以给我反馈，技术在交流中才会有发展。

积少成多，集腋成裘

       性能提不上去，多半是在一些容易成为瓶颈的“暗点”（IO，带宽，连接数，资源竞争等等）。Memcached Cache现在已经被大家广泛使用，但是千万不要认为对Cache的操作是低损耗的，要知道这类集中式Cache对Socket连接数（会牵涉到linux操作系统文件句柄可用数），带宽，网络IO都是有要求的，有要求就意味着会有损失，因此积少成多，集腋成裘。服务集成平台是一个高速的服务路由器，其大部分的业务数据，访问控制策略，安全策略以及对应的一些控制阀值被缓存在Cache服务端，因此对于Cache的依赖性很强。每一次对于客户端的性能提升，总会给服务集成平台性能带来不小的影响，但是每一次优化速度后，客户端可以优化的空间越来越小，这时候需要一些策略来配合，提升应用整体性能。当前主要采用了以下几点策略：

1．  从数据获取角度来做优化，采用本地数据缓存。（因为大家的应用需要能够线形扩展，支持集群，所以才不使用应用服务器本地缓存，但是在某些缓存数据时间性不敏感或者修改几率较小的情况下，可以采用本地缓存结合集中式缓存，减少对远端服务器访问次数，提升应用性能）。

Cache Client的IMemcachedCache 接口中的public Object get(String key,int localTTL)方法就是本地数据缓存结合远程Cache获取数据的接口。具体流程参看下图：

2．  从数据更新角度，采用异步数据更新。（即不等待数据更新结果，直接进行其他业务流程）。这类操作使用场景比较局限，首先数据不会用作判断（特别是高并发系统中的阀值），其次不需要返回结果作为后续流程处理输入（例如计数器），时时性要求比较低。（这类操作其实是采用了集群数据传播的一种策略，原先对于集群中所有节点都想即时传播到，但是这样对于性能损失很大，因此采用key对应的主Node采用即时设置数据，其他的通过后台任务数据传播来实现，由于key对应的主Node是数据第一操作和读取节点，因此这类数据传播操作时时性要求较低，适合这样处理）。具体接口参见Cache Client 使用文档。

3．  一次获取，多次使用。这点和系统设计有关，当前服务集成平台的安全流程是链状的，一次请求会经历很多安全拦截器，而在每一个安全拦截器中会根据情况获取具体的业务数据或者流程控制策略等缓存数据，每一个安全拦截器都是彼此独立的，在很早以前是每一个安全拦截器各自在需要数据的时候去远程获取，但是压力测试下来发现请求次数相当多，而且好些重复获取，因此将这些业务数据作为上下文在链式检查中传递，按需获取和设置，最大程度上复用了数据。（其实也是一种减少数据获取的方式）。

4．  规划好你的Cache区。有些同学在使用Cache的时候问我是否有什么需要注意的，我觉得在使用Cache之前，针对需要缓存的数据需要做好规划。那些数据需要放在一个Cache虚拟节点上，那些数据必须分开放。一方面是根据自己业务系统的数据耦合程度（未来系统是否需要合并或者拆分），另一方面根据数据量及读写频繁度来合理分配（毕竟网络IO还是稀缺资源）。当然有时候业务系统设计者自己也不知道未来的发展，那么最简单的方式给Key加上前缀，当前可以合并，未来也可以拆分。同时数据粒度也需要考虑，粒度设计太小，那么交互频繁度就会很高，如果粒度太大，那么网络流量就会很大，同时将来业务模块拆分就会有问题。

巧用Memcached Cache特有接口

       Memcached Cache提供了计数器一整套接口和add，replace两个接口。这些特有接口可以很好的满足一些应用的高并发性处理需求。例如对于资源访问次数控制，采用Cache的计数器接口就可以实现在集群中的数量控制，原本通过Cache的get和put是无法解决并发问题的（就算是本地缓存一样），这就是一组原子操作的接口。而Add和Replace可以满足无需通过get方法获取内容，就可以对于key是否存在的不同情况作出相应处理，也是一种原子性操作。这些原子操作接口对于高并发系统在集群中的设计会很有帮助。

Cache Client Cluster

       Memcached Cache是集中式Cache，它仅仅是支持将数据能够分片分区的存储到一台或者多台的Cache Server实例中，但是这些数据并没有作冗余，因此任何一个服务实例不可用，都会导致部分缓存数据丢失。当然很多人采取持久化等方式来保证数据的完整性，但是这种方式对于效率以及恢复的复杂性都会有影响。

       简单的来想，为什么不把数据在多保存一份或者多份呢，当其中一份不可用的情况下，就用另外一份补上。这就是最原始的Cache Client Cluster的构想。在这里具体的设计细节就不多说了，主要说一下几个要点，也让使用Cache Client Cluster的同学有大致的一个了解。

       先来看看Cache Cluster的结构图：

       这张图上需要注意四个角色：Application（使用Cache的应用），Cache Cluster（Cache配置的虚拟集群），Cache Node（Cache的虚拟节点，在同一个Cluster中的Cache Node数据保持完全一致），Cache Instance（Cache虚拟节点中实际包含的Memcached Cache服务端实例）。

       应用仅仅操作Cache Node，不了解具体数据存储或数据获取是操作哪一个Cache 服务端实例。（这点也就是Memcached Cache可扩展性的基础设计）。Cache Cluster又将多个Cache Node组成了虚拟的集群，通过数据冗余，保证了服务可用性和数据完整性。

       当前 Cache Client Cluster主要有两种配置模式：active 和 standby。（这里是借鉴了硬件的名词，其实并不完全一样，因为还是考虑到了效率问题）

       Cache Client Cluster主要的功能点：

1．  容错。当被分配到读取或者操作数据的Cache虚拟节点不可用的情况下，集群其他节点支持代替错误节点服务于客户端应用。

2．  数据冗余。当操作集群中某一个Cache虚拟节点时，数据会异步传播到其他集群节点。

3．  软负载。客户端通过对操作的key作算法（当前采用简单的key hash再取余的方式）选择集群中的节点，达到集群中节点简单的负载分担。同时也由于这种模式，可以使得key都有默认的第一操作节点，此节点的操作保持时时更新，而其他节点可以通过客户端异步更新来实现效率提升。

4．  数据恢复。当集群中某一节点失效后恢复时，其数据可能已经完全丢失，此时通过配置成为Active模式可以将其他节点上冗余的数据Lazy复制到该节点（获取一个复制一个，同时只支持一个冗余节点的数据获取(不采取遍历，防止低效)）。

Active模式拥有1,2,3,4的特性。Standby模式拥用1,2,3特性。（其实本来只考虑让Standby拥有1特性）。未来不排除还会有更多需要的特性加入。Active在key不存在的情况下会有些低效，因为会判断一个冗余节点是否存在内容，然后决定是否修复当前节点。（考虑采用短期失败标示之类的，不过效率不一定高，同时增加了复杂度）

运行期动态扩容部署

       Memcached cache客户端算法中比较出名的是Consistent Hashing算法，其目的也就是为了在节点增加或者减少以后，通过算法尽量减小数据重新分布的代价。采用虚拟节点，环状和二叉树等方式可以部分降低节点增加和减少对于数据分布的影响，但是始终还是有部分数据会失效，这点还是由于Memcached Cache是集中式Cache所决定的。

       但如果有了Cache Cluster的话，数据有了冗余，就可以通过逐步修改集群中虚拟节点配置，达到对于单个虚拟节点的配置动态扩容。

       支持动态部署前提：

配置文件动态加载。（配置文件可以在Classpath中，也可以是Http资源的方式）通过Cache Client 中Cache Manager可以停止Cache 服务，重新加载配置文件，即时生效。

当前动态部署的两种方式：

1.              修改集群配置中某一套虚拟节点的服务实例配置（socketPool配置），增加或者减少后端数据存储实例。然后动态加载新的配置文件（可以通过指定远端的http配置作为新的配置文件），通过集群的lazy的修复方式，逐渐的将数据从冗余节点复制到新的节点上来，最终实现数据迁移。

2.              修改集群配置中某一套虚拟节点的服务实例配置（socketPool配置），增加或者减少后端数据存储实例。然后动态加载新的配置文件（可以通过指定远端的http配置作为新的配置文件），在调用Cache Manager主动将数据由某一虚拟节点复制到指定的集群中，实现数据批量迁移，然后根据需要看是否需要修改其他几套虚拟节点配置。

存在的问题：

1.       当前没有做到不停止服务来动态部署。（后续考虑实现，当前将编译配置和重新启动服务器的工作节省了）

2.       不论是lazy复制还是批量数据迁移，都是会将原本有失效时间的数据变成了无失效时间的数据。（这个问题暂时还没有一种可行的高效的方式解决）

后话

       性能优化这点事还是那句老话，需要了再去做也不迟。同时如果你开发的是一个每天服务访问量都是上亿，甚至更高的系统，那么有时候斤斤计较会收获不少。（当然是不影响系统本身业务流程的基础）。

       Cache客户端自从作为开源放在Google上也收到了不少朋友的支持和反馈，同时自己业务系统以及其他部门同学的使用促使我不断的去优化和满足必要的一些功能扩展（但是对于Cache来说，还是那句话，简单就是美，高效是使用Cache的最原始的需求）。

       当前Cache Client版本已经到了2.5版本，在Google上有详细的Demo(单元测试，压力测试，集群测试)和说明使用文档。是否速度会慢于其他Memcached客户端，这不好说的很绝对，反正大家自己拉下去比较一下看看就知道了，当然为了集群和其他的一些必要的附加功能还是做了一些性能牺牲。

项目地址在：http://code.google.com/p/memcache-client-forjava/

在首页的右侧有demo,doc,binary,src的链接，直接可以下载使用和察看。希望对需要的同学有帮助。

爱这行

       从事任何行业都一样，只有真正的爱上了这份工作，才会投入热情，才会在顺境中自我警醒，在逆境中寻找突破。这个行业的竞争很激烈，你停下来走，别人就立刻会跑步超过你，没有对这一行业的一种热情，就很难在困境中保持一种执着的态度坚持到底。

踏踏实实“扎马步”

       今天无意中看了“校长”的“程序员&司机”，其中谈到了关于程序员速成的问题。其实速成班毕业的 “系统杀手”早已在遍布大江南北，只是在互联网时代，互联网的应用型软件生命周期越来越短，业务驱动主导的情况下，这种速成方式看起来反而提高了企业生产效率。但这样的人才也就只能写几个Facebook上的插件应用或者iGoogle上的Gadget，真的要出Google，Amazon，Yahoo改变互联网世界的企业，还是需要踏踏实实先学“扎马步”的人。

       很多在学校的同学或者刚刚毕业的朋友都看什么热门学什么，Spring，AJAX，Hibernate等等，又有多少人在看Spring之前把J2SE的NIO，XML，Collection等先好好学习一下，在看AJAX之前把Http协议、DTD、XML Schema好好看一下，在学习Hibernate以前先把J2EE事务规范搞清楚。Java最大的好处就是开源，能够让人们站在更高的起点来作出更多的创新，但是对于学习者来说，不了解自己站在什么上面的时候，可能摔下来会很痛。在用的时候多问一些为什么，在遇到问题的时候多找找原因，在了解以后多提出一些优化的方案，这样才会进步的更快，走的更远。

       记得我前一阵子回家的时候和妈妈聊起最近的工作，虽然妈妈不太明白，但是也知道我现在做的东西技术含量比较高，嘱咐我“千万不要什么都教给自己的同事，徒弟带出就不要师傅了”（这当然是老一辈的观念了）。我和她说：“不要担心，这种学的会的不教迟早也会，学不会的教了也学不会”。其实这里说的学的会的就是技术，而学不会的就是经验和能力。这个行业的人在日积月累过程中并不会去比较掌握的知识面有多广多深，毕竟这行业更新很快，其实能力强的人在多年的学习中就积累了很多的找问题，分析问题，总结问题，提出建议，发掘创新的能力，这些才是这行业人在发展中最宝贵的财富，也是一个人成长的标志。开始的过程中，踏踏实实地“扎马步”，了解一些最基本的知识，那么上层技术的发展对于他来说仅仅只是一个短暂的学习过程，甚至可以触类旁通。因此还是要奉劝每一个新入行的同学，踏踏实实，静下心来做技术，就算工作安排得都是一些浮躁和重复的工作，用高效的方式来结束那些重复劳动，多留一些时间给自己打基础。

逆境养兵、顺境攻城掠地

       普通人的工作经历通常都是起伏不定的，一个人的能力是否能够得到体现，不仅仅靠自己的努力，有时候也需要“天时”、“地利”。马云比较有名的一句话：“今天很残酷，明天更残酷，后天很美好，但是大多数人死在明天晚上，看不到后天的太阳！！！”，其实也在说明一件事，就是很多时候需要一种坚持的精神才能得到宝贵的机会。

今天是我进入阿里巴巴满3年，这3年让我感触很深的是：1.逆境不要气馁，厚积薄发。2.顺境不要懈怠，一股作气，把握机会展现自己最大的能力。3.在逆境和顺境的转换过程中，创造机会，不要坐等机会，要学会不在其位，也谋其职。最后一点就拿我自己的亲身经历来说，我原来就职于一家通信公司，因此对于互联网应用的开发和架构设计要比很多人弱，进入阿里巴巴以后工作了半年（主要作业务开发），正好阿里软件创立，当时被分配到了阿里软件第一个产品负责客户模块，当时的应用是通过MDA框架配置搭建的，开发人员很大程度上不需要自己做太多的编码，但是这个平台并没有搭建过如此复杂的大型应用，因此存在着不少问题，当然这些问题都是通过业务产品线的人反馈给平台部的人，当时平台部门人员很少，但是却要修复和完善诺大一个平台，因此常常搁置开发人员的反馈。当时在自己工作之余就琢磨和研究平台，同时跟踪调试平台，最后直接给出解决方案，逐渐的就融入到了平台开发中，最后被吸收到了平台部门，进入平台部门以后遇到了两位很好的老大，根据我的特质给我安排了研究和学习的工作。接下去就是不断地参与阿里软件各个基础平台的构建，核心技术的研究和探索，找到了兴趣和工作的最佳结合点。因此，当你困惑的时候首先不是去抱怨，而是审视一下自己是否还有作的不够的，是否还有可以提升的空间，多给自己制造一些机会，也许我们不用等到后天，也不会死在明天夜里，明天早晨我们就看到了太阳。

海纳百川、冰冻三尺

       很多朋友可能听老师或者前辈也说过类似的话，就是作为一个技术人员要广也要钻。就好比现在很多人都要DB Scale out，同时也要Scale up。我从自己的角度来说一下广和钻的看法。广：1.要有容人之量。（很多时候程序员最大的毛病就是喜欢在技术上比较，未尝不是好事，但是一个人的能力总归有限，多看看别人的，多听听别人的，也许能够让自己少用时间获得更多的收获，特别是自己战友的声音）2.触类旁通，多问个为什么，多跨过界去学习。在阿里巴巴，PD、SA、DBA、UI等等职位各司其职，作为开发的我们其实也应该去了解如何去画Use Case，如何假设服务器和应用环境，如何写一些略微复杂的SQL，了解一些DB的特性，如何能够简单的作出一些基础的页面，使用简单的css来美化一下门面。这些就是需要多跨过界，多虚心的去学习。钻：1.本职工作技术一定要扎实，每作一个技术点就要把技术吃透，同时延伸开来，发掘更多的技术亮点。2.多接触新鲜事物，但是有选择的去了解，有目的的去学习和实践（目的的源泉就是工作的需求）。3.学会分享，一个人自己搞懂一个技术很容易，一个人要把他熟悉的技术写下来就会发觉原来自己还有那么多没有搞清楚，一个人如果要把写下来的东西宣讲给别人听，他就会发现，原来写下来的仅仅是那么一小块，因此学会分享，从自己了解，到记录分享，到演讲传播就是一个不断深化和广化的过程。个人觉得小公司锻炼人（啥都自己干），大公司培养人（该干的要干好），因此自己常回头看看自己在广和钻上的不足，可以让自己进步的更快，学的更全面。    

       学中医积累经验，学西医寻找突破

       中医以对人体经络血脉了解为基础，通过望闻问切来寻找病理根源，行医年限越久，找问题解决问题的经验越强。西医以科学技术为手段，通过试验化的方式不断寻找突破，并且将成果积累并且传递给更多的人，但是否年限越久越有能力，或者是使用得器材越广越资深，这点全要看个人对于医术的理解，如果仅仅停留在对器械的使用和对成果的依赖，那么只会成为一个庸医。当然这里绝对没有对中西医的差别化或者评价，仅仅要说明的是，在手段丰富的情况下，容易忽视了本质，只看到了皮毛，积累的时候多一些追根溯源，站在别人的成果上才更踏实，因此在对经验积累上向中医多学一些，在寻找突破，传播技术上多学一点西医的风格。不过说到低,还是要看学习的人,静的下心,沉得住气,才会有积累,才会有突破.

不做一个纯粹的“技术人员”

       不做一个纯粹的“技术人员”，其实也就是说要培养自己多方面的能力，我仅仅把自己想到的一些点列出来说说：

1． 项目产品化的思想。现在就算在学校里面给导师作项目都讲究一个商业价值，更不要说在企业里工作。作为一个开发或者架构师最重要的就是要有产品化的概念，这也是项目是否成功的关键。软件的目的是为人服务，如何服务的好，那就要以一个产品的思路去做项目，而不是作为实验室的实验品，为客户提供好服务就会给公司带来商业价值，对自己的工作也会有很好的肯定。这是一个良性循环，反之则是恶性循环（多赢变成多输）。如何做到产品化，首先就是需要去了解需求，而不是布置需求，其次就是设计时多听取一些不同角色的意见，最后就是在客户的反馈过程中反省。

2． 多一些设计，少砌两块砖。代码写的再好，其实也只是用砖块砌墙砌的比较好罢了，这年代已经不会为了节省两块砖而给一个优秀工作者了，同时技术的日新月异，总是摆弄技巧，学习花拳绣腿已经跟不上时代了。多了解一些行业背景，多参与一些架构设计，将业务设计用良好的架构体系来实现，那才是一个称得上有能力的技术人员。

3． 学会前瞻，学会自己找事。记得我刚进平台组，最不适应的就是我的老大基本不太给我布置太详细的任务，这就好比进入大学，老师不给作业，自己反而心里没底了，其实自己找事的过程就是一个自己学习的过程，当我一天下来感觉没干什么，没学到什么，心里就开始发虚。如何能够前瞻性的去选择一些目标，如何对现有情况提出一些创新和建议，都是一种更高能力的要求。现在SIP组也是一样，在我们这个组里虽然现在每周还是布置一定工作，但是我对其他两个同学的要求也是希望能够有前瞻性，学会发现问题，预防问题，更甚者就是提出创新。当你具备了这种环境的时候，你就需要锻炼自己的能力了。

4． 做个让老大放心的人。这点也许很多人和我一样在业务上很早就让老大觉得可以安心睡觉了，但是其实另一方面，如何在商业角度看问题，如何培养新人，如何协调部门合作等等，都会让你的老大更加安心。另一方面来看，其实在这些能力的培养过程中，你不再局限于业务水平的提升，让自己在更多方面更加成熟。

六脉神剑

       今天是我进入阿里巴巴3年整。在阿里巴巴有个说法，只有在阿里巴巴工作了3年，才能算是一个真正的阿里人，因为理解阿里巴巴的文化，需要三年时间的沉淀。这里就从一个写代码的角度分享一下阿里巴巴的六脉神剑文化。

客户第一：如果你是做架构的，作平台的，作开发工具的，那么客户就是和自己一样的开发者，多学习一下开源项目的精神，多从使用者角度去考虑问题，那么你的东西才会被更多的人认可和使用，永远不要去做一个“玩具”的开发者。如果你是做产品的，那么就多听，多想，多问，永远不要急着去写代码。

拥抱变化：敏捷开发的基本原则。互联网应用尤其如此，不要害怕变化，在需求和架构之间找到平衡点（说起来比较容易^_^）。

团队合作：一个人的力量始终有限，分享，交流，合作能够让自己事半功倍，学的更多，看得更远。

诚信：说到就要做到，做了就要做好，做软件开发一样也需要有责任感，贴满狗皮膏药的代码上如果注释是你的名字未来也会给你蒙羞。踏踏实实地用心去写代码，去设计架构，不经意间得到的要远远比那么一点工资来的多。

激情：还是那句话，你如果不爱这行，乘着年轻赶快转行。

敬业：专业执着，精益求精

很感谢各位能看完这篇感受分享，以上都仅仅是个人的一点感受，能够引起共鸣那么证明我们的经历很相似，如果能够给到你一点帮助，那写这些就真的有意义了。不论你在别人眼里是一个资深架构师还是开发人员，其实如果你爱这个行业的话，你应该就是一个写代码的，但是每个人的经历都是一本“写代码的自我修养”，珍惜自己的选择，让自己在兴趣和工作中找到最佳结合点。

       今天看了“Database Sharding at Netlog, with MySQL and PHP”一文，和去年我们讨论扩展的思路很类似（不过这种分布式扩展，计算，存储的思路都很类似），但是这片文章的作者是在日益爆炸式增长的用户数据下实践的分享，因此这里将文中的一些思想记录下来分享一下。

       Netlog拥有4000万活跃用户，每个月有超过5000万的独立用户访问网站，每个月有5亿多的PV。数据量应该算是比较大的。作者是Jurriaan Persyn，他从一个开发者角度而非DBA或者SA角度来谈Netlog是如何通过数据切分来提高网站性能，横向扩展数据层的。原文在：http://www.jurriaanpersyn.com/archives/2009/02/12/database-sharding-at-netlog-with-mysql-and-php/

       首先，还是先谈到关于数据库在数据日益庞大的情况下一个演变过程。
   
   第一阶段：读写同在一台数据库服务器

   

第二阶段：读写分离（可以解决读写比例均衡或者读居多的情况，但是带入了数据复制同步的问题）

   第三阶段：部分数据独立部署结合读写分离。（部分数据根据其业务独立性情况，可以将所有的数据独立存储到数据库服务器，分担数据读写压力，前提是要求数据具有较高的业务独立性）

    
       第四阶段：数据分拆结合读写分离（三阶段的增强）

       第五阶段：问题出现，分拆也无法解决数据爆炸性增长，同时读写处于同等比例。

       解决问题两种方式：DB Scale up ，DB Scale out。前者投入以及后期扩展有限，因此需要进行数据切分。

       上图就是将photo的数据切分到了10台数据库服务器上。

       切分数据的两个关键点：

1． 如何根据存储的数据内容判断数据的存储归属，也就是什么是内容的分区主键。

2． 采用什么算法可以根据不同的主键将内容存储到不同的分区中。

分区主键的选择还是要根据自身的业务场景来决定，Netblog选择的是用户ID。

采用什么方式将分区主键映射到对应的分区可以通过以下四种方式：

1． 根据数据表来切分。（前提就是数据独立性较强，和前面提到的三阶段类似）

2． 基于内容区间范围的分区。（就好比前1000个用户的信息存储在A服务器，1000-2000存储在B服务器）

3． 采用Hash算法结合虚拟节点的方式。（这类在memcached等等分布式场景中最常见，其实也是一个难点），缺点就是在于动态增加存储节点会导致数据部分或者全部失效。

4． 目录式的分区。最简单也是最直接的方式，key和分区的对应关系被保存，通过查找目录可以得到分区信息。适合扩展，就是增加查询损耗。

如何将数据分布的尽量均匀，如何平衡各个服务器之间的负载，如何在新增存储机器和删除存储机器的时候不影响原有数据，同时能够将数据均摊，都是算法的关键。在分布式系统中DHT（Distribute Hash Table）被很多人研究，并且有很多的论文是关于它的。

数据的横向切分给应用带来的问题：

1． 跨区的数据查询变得很困难。（对于复杂的关联性数据查询无法在一个请求中完成）

2． 数据一致性和引用完整性较难保证。（多物理存储的情况下很难保证兼顾效率、可用性、一致性）

3． 数据分区之间的负载均衡问题。（数据本身的不均衡性，访问和读写的不均衡性都会给数据分区的负载均衡带来困难）

4． 网络配置的复杂性。（需要保证服务器之间的大数据量频繁的交互和同步）

5． 数据备份策略将会变得十分复杂。

解决这些问题当前已经有的一些开源项目：

1． MySql Cluster，解决读写分离问题已经十分成熟。

2． MySql Partitioning，可以将一个大表拆分为很多小表，提高访问速度，但是限制与这些小表必须在同一台服务器上。

3． HSCALE和Spock Proxy都是建立与MySql Proxy基础上的开源项目，MySql Proxy采用LUA脚本来进行数据分区。

4． HiveDB是MySql分区框架的java实现。

5． 另外还有HyperTable,HBase,BigTable等等。

Netblog几个需求：

1．              需要灵活的可扩展性。对于存储增加减少需要能够动态的及时实施，因为数据量增长很快，如果策略会导致数据失效或者部署需要重新启动，则就不能满足需求。

2．              不想引入全新的数据层和与原有系统不匹配的抽象层，因为并不是所有数据都需要切分，仅仅在需要的情况下通过API的方式来透明切分数据。

3．              分区的主键需要可配置。

4．              需要封装API，对开发人员透明数据切分的工作。

      Netblog Sharding的实现

    上图就是Netblog的Sharding的结构图，主要分成了三部分：Shard，Sharddb，Sharddbhost。Shard就是一个表，里面存放了部分用户数据。Sharddb是一个表的组合就像一个虚拟的DB。Sharddbhost是具体的存储分区。Shard，Sharddb可以根据负载的情况被移动到不同的host中去。

       对于Shard的管理，Netblog采用的是目录查询的管理方式。目录信息也存储在MySql中，同时会通过互备，Memcache，集群来确保安全性和高效性。

       Shard Table API采用了多一层的映射模式来适合各种不同属性的查询情况。数据和记录在数据库中存储除了UserID以外还有对应的ItemID，ItemID的作用就是定义了具体获取数据的字段信息，例如关联照片表时，ItemID就是PhotoId，关联视频表时，ItemID就是videoID。

       一个获取用户id为26博客信息的范例：

1．Where is user 26?

   User 26 is on shard 5.

2．On shard 5; Give me all the $blogIDs ($itemIDs) of user 26.

That user's $blogIDs are: array(10,12,30);

3．On shard 5; Give me all details about the items array(10,12,30) of user 26.

Those items are: array(array('title' => "foo", 'message' => "bar"), array('title' => "milk", 'message' => "cow"));

对于Shard的管理Netblog采取的措施主要有这些：

1． 服务器之间的负载均衡根据用户数，数据库文件大小，读写次数，cpu load等等作为参数来监控和维护。根据最后的结果来迁移数据和分流数据。

2． 移动数据时会监控用户是否在操作数据，防止不一致性。

3． 对于数据库的可用性，采用集群，master-master，master-slave复制等手段。

最后通过三种技术来解决三个问题：

1． Memcached解决shard多次查询的效率问题。

根据上面的范例可以看到，一次查询现在被分割成为了三部分：shard查询，item查询，最终结果查询。通过memcached可以缓存三部分内容，由前到后数据的稳定性以及命中率逐渐降低，同时通过结合有效期（内容存储时效）和修改更新机制（add,update,delete触发缓存更新），可以极大地解决效率问题。甚至通过缓存足够信息减少大量的数据库交互。

2． 并行计算处理。

由于数据的分拆，有时候需要得到对于多Shard数据处理的结果汇总，因此就会将一个请求分拆为多个请求，分别交由多个服务器处理，最后将结果汇总。（类似于Map-reduce）

3． 采用Sphinx全文搜索引擎解决多数据分区数据汇总查询，例如察看网站用户的最新更新情况或者最热门日至。这个采用单独系统部署，通过建立全局信息索引，来查询数据情况。

以上是技术上的全部内容，作者在最后的几个观点十分值得学习，同时也不仅仅限于数据切分，任何框架设计都可以参考。

“Don't do it, if you don't need to!" (37signals.com)

"Shard early and often!" (startuplessonslearned.blogspot.com)

看起来矛盾的两句话，却是说出了对于数据切分的一些考虑。

首先在没有必要的情况下就不要考虑数据切分，切分带来的复杂性直接影响可用性，可维护性和一致性。在能够采用Scale up的情况下，可以选择Scale up降低框架复杂度。

另一方面，如果发现了业务增长情况出现必须要扩展的趋势，那么就要尽早着手去实施和规划扩展的工作，并且在切分和扩展过程中要不断地去优化和重构。

后话：

       其实任何架构设计首要就是简单直接，不过度设计，不滥竽充数。其实就是要平衡好：可用性、高效性、一致性、可扩展性这四者之间的关系。良性循环、应时应事作出取舍和折中。用的好要比学会用更重要，更关键。

目标：

         根据四方面的配置调整，观察SIP5.5在高并发下的性能情况。

         由于SIP接收的请求都是服务型处理请求，因此认为Apache+Jboss只会带来多余的转发损耗，所以正好这次也作一个验证，看看Apache+JBoss是否不适合于这种纯动态服务请求的情况。 
        四方面环境比较：

1． JBoss APR模式与Http1.1模式性能差异。（确切来说应该是JBoss内置Tomcat采用APR的情况）。

2． 是否采用Apache+JBoss和Apache不同的转发模块带来的性能差异。

3． Memcached Client版本优化后对性能影响。

4． ISP有不同延时对于SIP的性能影响。

前置条件：

SIP版本5.5，并发用户600，ISP默认耗时20ms，Apache配置和JBoss WebContainer配置，一些优化配置参见附加信息。

最终结果：

       SIP采用Apache(Mod_jk)+JBoss(APR)+Cache2.4.2，具体配置参见附加信息。

测试结果表格：

       详细的测试报告可以参看：http://spreadsheets.google.com/pub?key=pcsQ9Wm01cIEjjQcistPNDg

JBoss配置差异测试比较：

补充：

         配置成为Http1.1模式的两种情况下，测试结果TPS波动频率很高，在Mod_jk模式下波动幅度也很大。

1.         可以证实在非APR模式和高并发的情况下Web容器处理请求能力不稳定，同时也直接影响到了SIP的性能。

2.         在测试中发现不采用APR模式的情况下，Web容器会消耗大量的socket连接通道。

Apache模块差异测试比较：

补充：

         Weblogic.so模块是以前系统遗留的http请求转发模块。在测试过程中Weblogic模块的测试中波动频率和幅度都很大。根据测试结果可以看出：

1.       在APR模式下，Apache+JBoss对于SIP这种无静态资源访问，纯API性质的服务来说依旧会有比较好的优化效果，特别是在接受请求环节。（不论是TPS还是TPS波动区间和频率都有很好的表现）

2.       Weblogic.so这个模块性能绝对不行，稳定性极差。

Cache客户端版本差异测试比较：

补充：

         2.4.2和2.4版本在单独测试的环境下：500并发用户，每个并发用户1000次get和set，性能相差40%左右。

         上面测试结果可以看出：

1．    在无apache时，性能有所提升，但不明显，而在有apache时，性能大幅提升，证明在无apache的情况下,memcache客户端已经不是性能瓶颈，因此替换版本效果不大，在http请求处理性能大幅提升的情况下，memcache客户端性能优化的优势就得到了体现。

2．    在测试中也发现Apache + JBoss波动频率和区间都小于其他几个测试情况，图形十分平稳，证明处理请求不是系统瓶颈。

ISP响应时间差异测试比较：

测试优化总结：

1． 不要认为内存使用无关性能。现在很对开发者认为内存申请分配是由gvm来管理，但是内存是否合理使用很可能会影响互联网应用的高并发下性能。GC带来的系统短暂停滞会在高并发下影响性能。

2． 使用java的方法需要有足够的“理由”和“度”。Java在1.5以后对concurrent方面做了很不错的支持，但是这些并发处理毕竟会消耗资源，因此在能够避免频繁使用的情况下尽量优化流程。在一些简单的场景下，是否有必要使用一些比较耗时的方法，例如split，用起来很方便，但是在设计底层通信操作的时候还是分秒必争（JProfiler看看消耗的时间占用的比例以及调用的次数），用一些自己简单的方式替换。

3． 眼见未必为实，测试才得真知。在SIP5.5中考虑连接后端ISP方式由HttpURLConnection替换成为HttpClient，感觉HttpClient的开发模式更加容易认为是共享传输通道（Get,Post都单独作为包来交由HttpClient单个实例），虽然看到HttpURLConnection说明中提到会共享通道。结果一压，HttpClient根本上不去，原因是构建这些Get,Post本身也很耗时，同时HttpURLConnection底层共享优化的也很不错。HttpClient的优势还是在于去构建简单的客户端，能够处理附加cookies等额外需求。

4． 链式处理的情况下，上下文中共享信息减少数据频繁访问缓存。

5． 操作系统配置以及Web容器的配置会直接影响应用的性能，特别是一些Socket交互比较频繁，会有很大并发的应用。具体的配置可以参见最后的说明。

6． APR模式对于服务器处理能力有很大的影响，Epoll和Unix socket都会来带很大的性能提高（降低资源消耗）。

7． 在过去谈过异步Servlet的方式（Servlet3.0的特性之一），但是JBoss5测试下来看，稳定性并不好，并且可能会有一些并发问题。

8． 先列出性能瓶颈可能点，然后分别对已经优化的模块进行单独测试，最后整合并且通过多场景测试来验证优化结果。

附加信息：

JBoss Web Container配置：

<Connector port="8128" address="${jboss.bind.address}"   

         maxThreads="1024" maxHttpHeaderSize="8192"

         emptySessionPath="true" protocol="HTTP/1.1"

         enableLookups="false" redirectPort="8443" acceptCount="1024"

         connectionTimeout="20000" disableUploadTimeout="true" useBodyEncodingForURI="true"/>

Apache work的配置：

Keep alive off

<IfModule worker.c>

ServerLimit          80

ThreadLimit          128

StartServers         10

MaxClients           8000

MinSpareThreads      64

MaxSpareThreads      800

ThreadsPerChild      100

MaxRequestsPerChild 10000

</IfModule>

Linux配置信息：

执行：vi /etc/sysctl.conf   

添加一行：net.ipv4.ip_local_port_range = 1024 65535

       再执行：sysctl -p

         更改ulimit –n属性，可用端口数，还有ip_conntrack_max 

APR：

       Tomcat优化了IO(sendfile,epoll,OpenSSL)。操作系统的一些函数(随机数的产生，系统状态的获取等)，本地进程优化(共享内存，NT的管道，Unix的Socket)。Tomcat有配置监听器直接会检测APR模块是否存在，在bin目录下建立native目录，并且放置对应的so或则dll即可。

    在大型网站中常常会遇到大流量的数据输出问题,过于频繁的输出到DB、文件、第三方系统都会带来不稳定性和低效率。因此需要采用一定的方式来解决这个问题，其实这部分内容的简单处理框架早就用在实际项目中，不过今天正好有外部的朋友问起我，我就整理了一下作为google的开源代码放上去了，这里也简单介绍一下，有兴趣的朋友可以去看看，最好是能够给一些建议。

场景：

         应用频繁访问接口服务器，需要控制每个应用在可配置时间段内（例如一分钟）对于某一服务的访问次数，同时需要记录每一次访问内容到数据库中。

几个点：

1． 高并发情况下，集群服务器需要全局计数。（需要将更新和判断作为原子操作，而非两阶段操作，保证高并发事务）

2． 异步日志批量输出。防止高频率访问第三方系统（DB,本地IO），提高性能。

3． 采用黑名单简化计数器判断。

1,3通过memcache就可以实现，如果需要使用客户端可以看看google code上的：http://code.google.com/p/memcache-client-forjava/

这里主要在说一下2，在很多场景中都会有这样的需求，一些需要输出到DB或者文件的内容需要缓存起来异步批量操作，提高性能也降低对于第三方系统的压力。大致设计结构图如下：

 自上而下来看，ThreadA,B,C都是程序中其他模块的线程，他们需要输出记录到数据库或者DB中。当有数据到达需要输出时，仅仅只是将数据放入阻塞队列中，而有一个消费者线程池中的线程发现队列中有数据就将数据写入其中某一个线程的数据分页中（每一个线程维护一个自己的内存分页，当页满或者到达了配置的输出间隔时间以后就将页内数据交给输出线程池中的输出线程完成批量数据输出）。

下面是三个类图，囊括了这个小工具框架的所有类：

         上图是对外提供的异步输出模板，其他模块可以直接使用模板来输出数据。

上图是异步输出器包，是异步输出模板的内置逻辑实现，其他线程直接使用异步输出模板来输出记录。

         上图是消费者和输出线程的接口和默认实现类，可以替换及扩展。

整个框架基本都可以通过配置文件扩展每一个角色（异步输出类，消费者，写出者），扩展方式就是通过在classpath下增加目录META-INF/services/然后将需要扩展的接口作为文件名称，内容就是接口的实现类，这样既可扩展和替换任何一个角色的具体实现。

具体的代码和测试用例可以去http://code.google.com/p/asynwriter/ 下载。

该文前半部分在程序员1月刊上,由于杂志篇幅有限,因此后半部分没有被刊登,这里就在blog上增加一下：

 

三. 服务集成平台

经过前面的介绍和实践两部分，在Open API在概念和实际操作上都有了一定的理解和认识，这里就再谈谈服务集成平台的作用、角色和定位。这里大致描述一下集成平台当前的实现点，这些实现点也就是服务集成平台的价值所在。

服务集成平台（SIP）的角色和作用

图 3 SIP Role

ISV（独立软件开发商）最关心什么？

1.       服务资源是否丰富。这关系着是否能够创新。

2.       服务质量是否有保证。这关系着是否能够满足用户最基本的需求。

3.       开发集成是否便利。这关系着开发成本。

ISP（独立服务提供商）最关心什么？

1.       服务安全性是否可靠。如果损害到自身或者用户利益，则就失去了原来开放的初衷。

2.       是否有足够多的应用开发者使用服务。

3.       服务的非业务性需求是否可以满足。（服务监控告警，计费，统计分析等）

SIP是连接ISV和ISP的“桥梁”。它能解决什么双方最关心的什么问题？

1.       丰富的ISV资源以及丰富的ISP资源。这其实是一个良性循环的过程，就好比一个建材市场，买家和卖家数量远远要比在单独一家实体店中多，从淘宝的B2C模式就可以看出，市场大了以后传统的“大鳄”都要聚集人气。

2.       统一安全标准和多种控制策略，即保证了ISP的安全，又能够让ISV开发起来方便。在前面实践过程中可以很明显的看到，众多的应用id，各自的安全流程，让开发者Mash up无形中增加了很大的开发成本和维护成本。

3.       SIP目的就是让ISP专注于业务服务的开发，而将非业务性的需求，如安全，服务监控预警，日志分析统计，计费，社区等都一揽子解决。这样既解决了ISP的第三个问题，同时也为ISV关心的服务质量无形中作了促进。

在年初的时候，分析和研究国外的Open API时，感觉类似于SIP形态的产品在国外还没有，大家都是各做各的，但这阵子回过头来看，YouTube和Google开放平台，Flickr和Yahoo开放平台，这些平台都属于SIP形态的产品，而且Google要比当前我们做的SIP还要更进一步，那就是数据格式规范化(GData)，而SIP当前仅仅只是做到流程规范化。

那是否任何公司都适合去做SIP这类形态的平台呢，这不仅仅是技术问题，还是一个资源的问题。阿里巴巴每一家子公司都有实力去做一个这样的开放平台，但各自独做一套的结果就是资源浪费，同时技术没有得到积累（SIP技术积累是在ISV和不同形态的ISP接入中逐渐产生的），最重要的是这些子公司其实真正需要关注的是如何将业务和数据开放给开发者，吸引更多的开发者来构建出围绕Open API的创新应用，最大化数据和服务的商业价值。

服务集成平台功能特性

服务路由

         服务集成平台就好比硬件里面的“路由器”，服务调用者只需要提供服务注册的名称，就可以调用到某一个服务提供商提供的服务，对于调用者来说无需关心此服务的地址以及提供者。

         根据现阶段的服务集成来看，主要分成四类的服务路由，同步服务路由，异步服务路由，订阅服务路由，大数据量上传服务。同步服务路由就是普通的Http无状态单次请求和响应。异步服务路由应用于服务提供商提供的服务无法在当时处理完毕，先返回一个请求响应，当服务处理结束以后再将服务处理结果返回给服务调用者（短信业务就是一种异步服务）。订阅服务和互联网上RSS之类的订阅十分相似，服务调用者只需要订阅服务即可获得服务提供商推送的服务内容。大数据量上传服务其实也是属于同步服务，但是由于消耗资源和性能压力不同，因此被单独作优化处理。

         对于服务形态不同，服务路由需要支持REST风格的服务路由和类REST风格服务的路由，但对于开发者来说，调用的方式都是用服务名称来路由。

正式环境和测试环境的隔离和切换

         对于服务开发者来说，在应用开发期间需要有外部测试环境的支持，在商用以后需要有正式环境支持，同时两个环境的切换需要尽量的简单。

         服务集成平台支持服务提供商提供测试环境和正式环境的不同服务路由，同时两套环境切换成本低。当服务提供商只有一套环境的时候可以根据策略配置的不同，对调用者访问的范围，频度，次数作限制，保证测试服务不影响正式服务。

安全

         提供对应用身份认证以及服务提供商身份认证的支持，采用多种数字签名算法实现基本的身份认证，支持IP白名单和动态算法更新后端插件提供更高级别的服务安全保证。

         细化了用户授权流程。对于用户Token细分为请求级别和会话级别，同时对于会话级别的权限操作，失效时间可根据服务提供商的配置自定义。同时平台托管维护每个应用每个用户的多身份绑定Token，降低服务提供商开发维护成本。

         服务提供商可配置服务访问量控制和频率控制（所有应用或者单个应用）。也支持配置需要订购才可以使用的服务（有限次数订购，无限次数订购）。

         支持多级服务安全策略配置，为服务配置（无授权，应用授权，用户授权，可选用户授权）等多种级别的安全策略。注：可选用户授权是指如果没有被用户授权的情况下使用接口将返回部分公开数据，而在用户授权情况下使用则返回全部的私有和公开数据。

         对服务提供商多级分类，提供不同的安全策略组合。

监控与告警

         服务使用者服务使用出错监控和告警。

服务提供商提供的服务可用性，超时状况的监控和告警。

服务集成平台服务处理状况，内部模块运行状况监控和告警。

日志采集与统计分析

         高并发下日志采集异步处理，采集服务正常访问和异常访问日志，采集用户绑定类，异步服务类，平台内部服务类等特殊日志。

         每日，每周，每月访问日志统计分析，基础报表和趋势分析图的创建。

         支持分析结果预警配置。

         历史统计数据管理和归档。

平台内置服务

         平台为服务提供商以及服务调用者提供了平台级别的服务，为开发商和服务提供者获取平台业务数据以及运行期配置安全策略提供方便。

         平台提供一系列平台模块监控、配置、重置服务，支持在线问题查找、定位、解决的一套机制。

非功能性需求（当前情况）

         性能：压力测试单机500并发用户1600+的tps，多机处理能力线性增长。

         模块化：内部处理模块化结构，支持运行期配置、装载、卸载。

容错：服务集成平台核心数据都缓存在Memcache中，因此Memcache集群以及容错策略的扩展都为平台稳定和容错作了基础保证。

配套支持

         通过ISV,ISP,Admin三个Portal，使开发者，服务提供商以及后台维护人员能够自主维护基本信息和查看相关数据。

         为开发者提供社区，测试区的支持，并且提供开发工具包和文档，方便开发。

扩展集成

         支持不同平台的服务集成。支持Google,Flickr,Yahoo等等不同的服务平台的服务集成，当前还没有完全将安全体系集成，只能够支持安全流程透传，消息数据完整过滤。

服务集成平台的一些发展趋势

1.       数据集成和流程集成

当前很多服务都是基础的数据型服务，使用者通过数据筛选获取相应的数据，然后展现给用户，这些服务的集成相对来说功能比较单一，流程也不复杂。但随着服务提供商的发展，数据类型服务将会作为基础服务的一部分，而越来越多业务处理型服务会成为使用者的首选，此时，如何让服务和服务之间数据互通，服务可以通过一定的描述编排，就会变得越来越有价值，就如前面提到的，Google采用GData作为数据规范格式，同时对于安全流程的统一制定，为第二阶段的集成打下了基础。

2.       服务基础平台间的互通

最近Open ID也再次由于各大网站的支持而被人们广泛关注，在未来Open API体系中，伴随着Open ID的发展，服务基础平台之间的服务互通也将会变得越来越容易，但是数据的安全性也会对每个服务平台要求更高。

3.       服务集成平台的层次化

在这篇文章的介绍中仅仅介绍的是最基础的Open API的Mash up，其实当前已经有更高层次的Mash up被广为使用，JavaScript、ActionScript、Flash/Flex这些技术使得展现更为灵活和丰富。因此未来的服务集成平台将会层次化，从数据集成到流程集成到UI集成，会成为一套自下而上的解决方案，适合各种场景的裁剪选择。

四. 对Open API的一些思索和感触

不同角色，不同收获

平台开发者：

         这是我的本职工作和角色。当淘宝等服务提供商的服务接上来以后我就要为它的安全和稳定负责。当SIP一旦出现问题，那么服务提供商和软件开发商将都无法再正常工作，套用蜘蛛侠的一句话：“能力越大，责任越大”。作平台的尤为如此。

服务提供商：

服务提供商接触的最多的就是淘宝的同学，首先看到的就是做一个服务提供商很不容易，要把原有系统中复杂的逻辑抽象出来并不是抽象一个公用函数那么简单，同时对于模块化，边界性，容错性方面的要求要远远高于封闭系统开发本身，因为你现在要面对的是倍于原有访问量上百甚至上千的调用者，对任何一个小疏漏都可能带来灾难性的影响。

软件开发商：

         在写这个文档以前，最多也就是写几个测试的Demo来测试SIP环境中的服务，在淘宝API讨论群中会看到很多新的或者老的ISV在抱怨或者询问一些自己觉得很简单的问题（例如签名等等），同时在监控中也看到很多及其简单错误统计数都会有很高的比例。但是经历过这次对于各种各样国内国外的API的开发，让我深刻体会到了开发者的一些痛苦（当然我没有去使用各个开发社区的第三方语言开发包，这也增加部分的开发难度），我也曾因为签名问题在豆瓣API测试的时候折腾了半天，在调试Google Calendar的时候不得不跟踪开发包代码才找到了一些隐晦的设置通过测试。其实Open API在国内国外都没有完全可以称得上成熟，因此开发者其实是最容易受到影响的。同时他们面对着最难应付的客户，平台或者服务提供商出现问题，客户最先抱怨的也是服务开发商，因此作为平台开发者和ISP其实都要给与一定的支持和帮助，这样才会走向更好的良性循环。

其实上面说的那些无非都是大家最长说的换位思考，一个新兴的开发模式需要各方合作才会走向良好的发展方向。

创意就是财富

         记得前一阵子支付宝能够在上海交水电费引起了很多人关注，杭州本地论坛中都有很多人在问：“什么时候杭州能够也用支付宝交水电费就好了”。其实如果开放了支付服务和水电缴费服务，这种Mash up的应用又有什么难的呢？你都可以直接每个自然月通过Google Calendar设置好日程安排，自动缴完所有的费用，然后短信提示一下即可。未来当各行各业发现了自身资源的潜在价值以后，以服务的方式通过平台互通，那么创意就是财富。

    应该是去年的年初，我受到普元公司的邀请去参加了一次SCA、SOA的技术交流会，当时也是自己第一次去和那么多陌生的朋友交流技术心得，同时也被普元公司的这种纯技术性的交流方式所打动，也在想哪一天阿里巴巴也能够举办一次这样的小规模有针对性地技术交流会那会让我们这些技术人员收益菲浅。一年后的今天，当老大问我有个这样的会议是否要参加的时候，自己毫不犹豫地报了名，虽然看起来和自己专注的工作不是很相关，但是还是那个想法：首先不了解是无法知道是否和自己相关与否，其次就算不相关，多学多听，触类旁通的技术延展只会给自己带来更多的想象空间和创新思维。

    按照会议安排，早晨有两个讲座，下午有四个讲座，每个讲座1个小时左右。第一个出场的是腾讯的安全中心总监杨勇，整个演讲很轻松，首先是对腾讯的整体产品结构和背景作了一下阐述，然后就从安全中心这个整体来讲述安全对于腾讯的意义，如何实施以及一些流程的制定。没有过多的牵涉安全问题的细节，着重是讲述了安全中心面临的四个方面的问题，以及通过什么手段去解决。这其实和他本身所处的工作职责来说相符合，如果仅仅只是来讲某一个安全技术应用，那么就有些太过狭隘了。不过在提问的时候一个问题的回答让我还是留有一些印象的，主持人收集到一个问题：“腾迅安全中心的建设初期遇到的最迫切需要解决的问题是什么？”，他回答道：“其实腾讯安全中心从建设初期到现在一直面临各种迫切的问题，只是随着时间的不同而不同的演变，最早的协议安全到客户端安全到奥运期间的信息安全都是一个发展的阶段”（因为没有ppt以及记录，因此描述的可能不太准确）。但是这个思想任何技术行业都是一样的，时代不同关注不同，需要解决的问题也是在发展的。

   第二个议题是Discuz的剑心带来的“web应用程序中的字符集攻击”，这个演讲就相对来说比较注重专业细节方面的阐述。作为互联网应用开发者，使用Java的人第一堂课就是中文乱码，很多人只看到如何去配置或者写一点转换语句就可以解决，但是对于编码方式就不求甚解，ISO-8859-1,GB2312,UTF-8,UTF-16区别是什么，为什么会引起乱码。其实了解了编码的原理就很能够解释如何会产生乱码，同时产生乱码的时候也可以根据乱码的情况了解可能是因为什么编码转化造成的（阿里巴巴的宝宝写了一篇很详细的文章说了这个问题，进入公司以后我也是看了那片文章才系统地对编码方式做了完整的了解，以前都是碎片）。不过今天听了这个演讲，到让我知道了原来编码方式也被人用来攻击。其实基本的思想主要就是一点：由于信息转发中对于不同编码解析的方式不同或者是过滤不同，导致出现一些漏洞。通俗的比喻就是刺杀秦始皇的图穷匕见，侍卫就好比第一层把关的信息转发者认为着幅图没有威胁，但是真的按照刺客的处理方式那么就是一个最好的攻击性工具。记得我在和同事探讨REST对于Http协议的使用时说最重要的就是REST不再使用Http协议作为传输承载协议而是作为业务协议，那么解析业务的时候究竟是分析协议中指定的编码方式还是内容中的编码方式，结果会大不一样，同时作为安全人员的角度来看，这也会存在一种安全隐患。所以其实任何一种错误都可以被利用作为攻击的手段。

    下午的议题一共有四个，虽然时间比较长一直连续讲到6点多，但是就像主持人讲的，每一个人都“坚持”下来了，呵呵，当然坚持并不是因为不好听，而是做在那儿听比写代码要累很多，当然讲课的同学们也是十分辛苦的。下午第一个演讲的是team509的创始人吴石，讲的主题是“部分软件安全的思考”，内容专业化很强，对很多比较底层的安全问题（操作系统等）作了一些介绍，当然对于我这个门外汉只能听懂个大概意思，不过还是有所了解那些名词的意思到底是什么。第二个是微软的大牛蛙同学，也是安全领域专家讲述了一下微软的SDL(Security Development Lifecycle)，望名生意，安全实施的流程化。第三个演讲是两位同学做的，也是我下午听得比较有感触地，先是网名余弦（钟晨鸣）北京知道创宇信息技术公司的安全研究员，讲的是CSRF蠕虫技术，从一个黑客的角度来阐述CSRF的原理以及危害性。这部分比较技术化一些，但是由于和我关注的Web安全也比较相关一些，所以听起来也不是比较迷糊。虽然听着他讲CSRF，但是其实我脑子里面已经在考虑关于Open API的一些安全问题。其实在阿里软件承载淘宝的API过程中，对于客户端的安全问题就一直都在谈，但是对于SIP来说总是鞭长莫及，因为服务集成平台只会保障ISV和ISP之间的信息交互的真实性，但是用户是否由于ISV的技术问题导致信息伪造提交，那么就不得而知，但是最后表现出来的结果就是ISP的Open API计划为ISP带来了更多的安全隐患，也就是说原来淘宝一家漏洞，以后可能会是千千万万家ISV的漏洞，其实这也是上面几个演讲提到的合作风险问题，第三方的技术能力不得而知，同时产生的风险也会很难控制。其实从这里也多多少少看出来为什么FaceBook，myspace，最早对于用户安全隐私数据的开放不仅仅是开放了数据API，同时也会有整一套上层框架支持，其实也是出于开发者能力不足引起隐私数据被恶意修改而作的防护措施。那么现在Open 用户的数据特别是以后涉及到金额的api如何保证isv不欺诈，isv不被欺骗，这可能是后续需要更加重视的问题。同时，在听了CSRF的攻击中谈到的对于资源定位猜测以及操作的时候，让我对REST的风格又打了一个冷颤，REST对于资源的规划和定位十分容易，但是这也为这类攻击提供了便利，同时对于资源操作依赖于Http协议，也会让资源的安全性打了折扣，这需要对Open API开发人员做更多的安全工作指导，或者提供安全框架来防范Open API可能会产生的安全漏洞。紧接着后面的演讲是北京知道创宇信息技术公司的创始人赵伟，应该是业界比较资深的专家了，本来的议题是“恶意网站检测”，不过他还是讲了他这些年来的一些经历以及安全领域的黑色产业链的问题。平时这方面关注的不多，不过今天这一番交流，让我对安全领域的发展以及现况有所了解，甚至有时候就觉得现在上网就算装了一大堆东西还是感觉在“裸奔”。最后一个议题是51.com的郑歆炜讲的“运维安全经验谈”，总结了运维所面对的问题以及解决方案，协调，沟通，总结，知识库，其实这些对于开发人员来说何尝不是呢。最后小黑作了一个简短的总结，同时预报了明天他会做一次附加的构建安全Web架构的讲座，期待明天半天的研讨会和附加讲座。

    好久没有踏踏实实地坐着好好听课了，这次一天半的学习对于自己来说也算是一次新知识的扫盲，同时也为自己后续的工作可能存在的问题或者可以借鉴的知识作一个铺垫。

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

问题

         小丹同学在旺旺上问我是否可以用Memcached实现简易消息中间件类似的功能。觉得这个需求很奇怪，就问了一下具体的应用场景，然后小丹就上来和我具体的谈了究竟需求是什么。其实小丹的应用场景是这样的：客户需要分析一些业务数据，但是业务数据又是很庞大的，在原有系统每天晚上都有一次日分析，将业务数据分析并且归档，但是如果要产生即时分析的效果，用原有系统无法实现，因为当天的数据内容没有被分析，同时如果即时的去分析并且累加到历史分析数据上，性能也不能满足需求，因此考虑通过消息机制来实现异步分析，至于异步处理的时间容忍度，可以通过配置来实现，同时希望异步分析是可线性扩展的，支持集群，提高效率。为什么不直接使用中间件呢？高并发的稳定性，维护的成本，性能要求，使用成本，这些直接就排出了直接去使用中间件的想法。

起始方案的讨论

         在回到小丹最初提到是否可以通过Memcached来实现类似于简易消息中间件的问题上来。首先是否将消息队列作为一个对象保存在Memcached中，这种做法明显不支持高并发的情况，因为Cache本身的get,put无法保证事务。在Memcached中只有计数器是支持高并发的操作，因此考虑是否使用计数器并且按照一定规则来生成key，通过对计数器的增减来让不同消费者获取到不同的消息，这种机制最大的问题在于：1.轮询的压力不小（小丹希望是订阅者模式，Push过去而不是Pull）。2.计数器增减不论怎么做都实现的是栈而不是队列。那么是否使用我扩展的Memcached的KeySet，这点我自己就反对了，这个功能效率很低，而且对于Memcached本身在高并发下操作是否有影响还不得而知。问题越绕越走向死胡同了。

方案的转变

         转换思路，重新分析小丹的需求，究竟哪几点是他真实需要的：1.通过消息方式解耦Web应用和业务分析处理。2.消息必须较为及时的传递到业务分析模块。3.业务分析模块需要支持集群方式线性扩展性能。实现这些需求真的需要简单的消息中间件或者集中式存储么？看看下图的结构：

回过头来看看Memcached的使用情况，突然发现其实事情可以简单来说，我记得写过一些说明来解释为什么我说Memcached是集中式缓存而不是分布式缓存，其实是客户端的分发算法让很多人觉得好像分布了数据和可无限扩展。其实这种技术结合Hadoop 的HDFS的部分设计思路，可以给出一个比较好的解决方案。看看下图的结构设计：

上图去掉了消息中间件的角色，增加了Asyn Processor Manager的角色，但是此角色也可以去掉，更为简化的实现需求，增加Asyn Processor Manager的功能仅仅是为了提供动态增减Asyn Processor的功能。具体说一下流程：

1．              Web应用启动时，读取本地配置获取Asyn Processor列表载入内存，同时根据Asyn Processor Manager的配置去发起请求获取Asyn Processor最新的可用列表（如果无法获取，则以本地的为准）。

2．              Web应用根据本地实现的分发算法（最简单就是采用key hash），来选择Asyn Processor，发送请求处理的消息。

3．              如果Asyn Processor Manager不存在，Web应用也可以实现定时发起query status请求来确认Asyn Processor的存活状态，并且更新，保证消息的正常发送。如果Asyn Processor Manager存在，那么确认Asyn Processor状态是否存活可以由Asyn Processor Manager来做（Push或者Pull），而Web应用则可以使用对Asyn Processor Manager的定时查询来获得最新的Asyn Processor列表。

4．              Asyn Processor Manager可以提供增加和删除Asyn Processor的接口，这样就可以支持Asyn Processor的增加和删除，但也正因为Asyn Processor Manager的单点易于注册和管理Asyn Processor，也增加了单点的风险，因此每一台Web应用需要对Asyn Processor Manager不可用作好本地化配置的后备策略。

5．              使用Http协议作为消息传输协议，这样避免SA去维护端口的麻烦，同时也能够充分利用REST的方式来完成业务逻辑（Options方法可以用于心跳，Put、Delete可以用于Processor的增减（设置Http Head认证方式即可解决安全问题），Get方式获取信息（xml,json等等格式可以很容易处理））。

上面的方案可以看出，如果去掉Asyn Processor Manager，其实方案很简化，就是每一个客户端有一层类似于Memcached客户端的分发机制，同时比Memcached免去了对于连接池维护的复杂性，仅仅只需要维护状态标示即可。

最后还嘱咐小丹对于Asyn Processor的设计需要合理化，这部分需要支持消息接受和处理的并行处理，提高Asyn Processor的处理能力，同时通过分页批量处理消息的方式减少对于DB的压力（当然需要根据具体的时效性设置消息页的大小以及消息页Flush的时间）。

后话

     今天收到InfoQ的推荐邮件，看了标题就很感兴趣，花了一些时间一看，果然是很不错的一个案例分析，同时也让自己学到了不少。大致罗列一下看后的一些文章重点内容。案例地址：http://www.infoq.com/cn/articles/webber-rest-workflow

    1.通过REST服务请求完成状态迁移，同时合理利用OPTIONS来查看资源操作权限。

    2.合理利用Http Heads来返回资源URI，以及通过ErrorCode来确定操作结果，并且作后处理。

    3.通过返回内容指定后续流程资源定位以及操作来实现流程化。

    4.通过Put报头的两种版本比较标示来防止并发修改。（其实也可以优化来做查询缓存的工作）

    5.使用Atom协议来发布和管理资源（Atom是最适合REST风格服务的数据源格式定义）

    6.URI模版的使用建议，慎用，如果确实能够有把握抽象资源定位。

    7.Auth可以通过轻量级Http Head中的Authentication或者WS-*的方式来实现。（也可以通过https实现）

    总的来说，其实整个案例分析下来以后，可以发现如果要使得服务流程化，那么前提就是数据交互格式统一（XML，Atom），然后利用Http协议作为服务协议而非承载协议，利用已有的操作约定，报文头部标示和返回的错误码来完成资源状态迁移的工作，同时通过在返回内容中嵌入流程化内容，使得整个流程可以贯穿。（这里还是简单的流程串联，其实如果在流程规则协议中增加复杂的逻辑定义，则可以实现更为强大的Web workflow）。

    但对于Open API或者类似的REST流程化业务来说，安全其实还是最大的挑战，特别是在对资源的访问控制权限上。当然可以类似于WS-Security提出一套较为安全成熟的方案，但是性能和使用简易性则会大打折扣，也失去了REST本身的优势。

    下周一应该是我今年最后一次参加内部培训了,所要讲的内容也是我这大半年来都在专注的技术:Open API&SIP。由于文章要在程序员1月刊发表，因此文章暂时不能放在Blog上，不过下周一的培训PPT还是可以分享一下的。有兴趣的集团的同学也可以来阿里软件听。同时也很高兴的看到在csdn的blog在年底冲过了10w，希望明年有更多的分享能够贡献出来^_^

    今天，有一个使用我优化的Memcached cache Client给我发了邮件问到一个参数的作用，觉得还是比较重要的一个参数，因此也说一下，同时也在这里说一下，当前优化过的客户端已经作了几次小的升级，修复了一些边界数据的问题，大家如果在使用的话，最好能够升级。（http://code.google.com/p/memcache-client-forjava/）

   邮件如下：

   你好：
<socketpool name="pool0" failover="true" initConn="5" minConn="5"
  maxConn="250" maintSleep="5000" nagle="false" socketTO="3000"
  aliveCheck="true" >
  <servers>10.0.0.16:11111</servers>
  <weights>10</weights>
 </socketpool>
能解释下maintSleep这个意思么？我看有的资料说吧它设置为0性能更好，能给些建议么？谢谢！！我们现在的PV大约每天500万。

    这个参数是对此连接池维护线程的检查间隔时间的配置，如果配置小于等于0，则将不会有后台线程维护此连接池，参数单位为毫秒，下面解释一下维护连接池的含义，其实就和其他的资源池一样，资源池的目的就是为了解决资源的申请和释放的开销增加系统压力的问题，将资源通过池的方式回收重用，有利于系统性能的提高。memcached cache client 其实是通过socket来和服务端进行通信，建立socket连接也是比较消耗时间的工作，因此配置了池的初始连接数（initConn），最小连接数（minConn），最大连接数（maxConn）。这三者关系如下图，维护他们之间状态转移的就是后台线程。

    后台进程维护资源池的作用就是将有限资源回收，例如数据库连接，如果一台oracle只有500个连接数可以支持，那么如果一个应用都占用了50个闲置，那对于其他需要资源的应用来说无疑是一种浪费。但如果配置了资源管理，但由于应用属于忙时和闲时交替比较频繁的情况，那么如果时间配置的不是很合适，就会达不到原来资源池的作用，资源反复回收和申请。所以对于这个参数的配置，个人觉得一定要配，配置的值需要注意，初始化和最小的值可以是自己预估平时平均并发处理的均值，最大的连接数当然依赖于资源的总数，而维护时间间隔则最好是能够根据闲时和忙时的情况来考虑配置，这样既不会浪费资源，同时也不会使资源池时效。

    顺带说一句，如果对于数据丢失要求不是很苛刻，然后网络情况也不错的时候，可以将aliveCheck设置为false，因为如果是true，在每一次发送任何数据操作之前都会去做心跳检查，这个未来也会考虑去优化。

    一个人，我们阿软的首席架构师赵进。说到对人能力的佩服，我想对于赵进作为首席架构师的能力，我自己真的是很实实在在的佩服。远了不说，就说最近的关于阿里软件自己的基础组件Cache，当前除了SIP以外，其他两个自主产品的cache都采用的我维护的cache组件，这次做外贸重构，其他的架构师作了一个新的Cache，赵进知道后觉得这个关系到未来的整体基础架构统一性的问题，因此反复找我们几个人谈了很久，当然我也很理解架构师为了项目需求不愿意切换或者改变现有成型代码，但是如果作为一种长远的负责的规划，的却是需要统一起来。期间的困难可想而知，赵进最后找了我们的老大来拍板，结果我老大的一句话把赵进打入冷库，连我们老大都因为担心项目影响的风险而不是很赞成，我可以看出当时赵进的失落，但是在他弃而不舍的精神下，我真的算是感动了，大家一起在作了分析和讨论，最后总算确定了一个不算最满意，但也算是达到目的的一个解决方案。

    那么回顾一下我对赵进的感受，那么就能够体现出如果要成为一个架构师，或者是一个首席架构师应该具有的能力，首先就是微笑，其次就是倾听，再则就是引导，最后就是坚持。微笑可以化解敌意，倾听可以找出问题，引导可以商讨解决方案，坚持可以达到目标。当然双赢之类的就不说了。其实说到能力，在我看来技术方面的能力是可以培养的，要成为技术上的能人，需要专注，坚持和勤奋，但是要成为一个架构师那么最重要的还是胸怀和眼界，能够容纳别人才会让别人接受你，这些说起来都很容易，但是做起来却是很难，因为这和个性也有关系，改变自己的个性需要勇气和时间。

    我现在MSN的名字叫做海纳百川，时时告诉自己有容乃大，整天为了一些细枝末节的重复劳动而沾沾自喜，只会变成井底之蛙，要做就要做别人没有做或者做不到的，多了解一些，多学习一些，站在不到巨人的肩膀上也站到石头上，看得更高才会走得更远。

    一年过去之际，勉励自己改变自己。

    有架构师的能力，却没有宽广的胸怀，那么永远只会停留在一个代码编写者阶段。

    有宽广的胸怀，却只有程序员的能力，那么只要努力就会成为架构师甚至首席架构师。
    （打个广告^_^，年底关于Open API的文章由于要发表在杂志上，因此无法在这里贴了，不过到了一月份应该就可以贴了，这篇关于Open API的文章是自己沉淀自己大半年工作的一份总结，也希望能够分享给大家）

    昨天集团架构委员会（虚拟组织）作了第二次交流，各个子公司都说了当前的一些进度，问题和想法，我也大致讲了一下阿里软件的服务集成平台的一些进展和自己的一些思考，这里先贴一下PPT的图片，后面想整理以下关于当前Open API的一些想法以及对Open API Framework的一些思路。

       SIP5.0以后服务的请求量爆发性增长，因此也暴露了原来没有暴露出来的问题。由于过去一般一个新版本发布周期在一个月左右，因此如果是小的内存泄露，在一个月之内重新发布以后也就看不出任何问题。

因此这阵子除了优化Memcache客户端和SIP框架逻辑以外其他依赖部分以外，对于内存泄露的压力测试也开始实实在在的做起来。经过这次问题的定位和解决以后，大致觉得对于一个大用户量应用要放心的话，那么需要做这么几步。

1.       在GC输出的环境下，大压力下做多天的测试。（可以在 JAVA_OPTS增加-verbose:gc -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError）

2.       检查GC输出日志来判断是否有内存泄露。（这部分后面有详细的实例说明）

3.       如果出现内存泄露问题，则使用jprofiler等工具来排查内存泄露点（之所以不一开始使用，因为jprofiler等工具对于压力测试有影响，使得大压力无法上去，也使问题不那么容易暴露）

4.       解决问题，并在重复2步骤。

这里对SIP在jdk1.5和jdk1.6下做压力测试的GC 日志来做一个实际的分析对比，通过对比来大致描述一下如何根据输出情况能够了解应用是否存在内存泄露问题。（这里的内存泄露问题就是在以前blog写过的jdk的concurrent包内LinkedBlockingQueue的poll方法存在比较严重的内存泄露，调用频率越高，内存泄露的越厉害）

两次压力测试都差不多都是两天，测试方案如下：

开始50个并发，每个并发每次请求完毕后休息0.1秒，10分钟后增长50个并发，按此规律增长到500并发。

旧版本SIP是在JDK1.5环境下完成的压力测试，

新版本SIP的JDK版本是1.6，

压力机和以前一样，是10.2.226.40，DELL1950，8CPU，8G内存。

压力机模拟发出对一个需要签名的API不断的调用请求。

看看两个Log的具体内容（内容很多截取部分做分析）

先说一下日志输出的结构：(1.6和1.5略微有一些不同，只是1.6对于时间统计更加细致)

[GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]

<collector>GC收集器的名称

<starting occupancy1> 新生代在GC前占用的内存

<ending occupancy1> 新生代在GC后占用的内存

<pause time1> 新生代局部收集时jvm暂停处理的时间

<starting occupancy3> JVM Heap 在GC前占用的内存

<ending occupancy3> JVM Heap 在GC后占用的内存

<pause time3> GC过程中jvm暂停处理的总时间

Jdk1.5 log：

启动时GC输出：

[GC [DefNew: 209792K->4417K(235968K), 0.0201630 secs] 246722K->41347K(498112K), 0.0204050 secs]

[GC [DefNew: 214209K->4381K(235968K), 0.0139200 secs] 251139K->41312K(498112K), 0.0141190 secs]

一句输出：

新生代回收前209792K，回收后4417K，回收数量205375K，Heap总量回收前246722K回收后41347K，回收总量205375K。这就表示100%的收回，没有任何新生代的对象被提升到中生代或者永久区（名字说的不一定准确，只是表达意思）。

第二句输出：

按照分析也就只是有1K内容被提升到中生代。

运行一段时间后：

[GC [DefNew: 210686K->979K(235968K), 0.0257140 secs] 278070K->68379K(498244K), 0.0261820 secs]

[GC [DefNew: 210771K->1129K(235968K), 0.0275160 secs] 278171K->68544K(498244K), 0.0280050 secs]

第一句输出：

         新生代回收前210686K，回收后979K，回收数量209707K，Heap总量回收前278070K回收后68379K，回收总量209691K。这就表示有16k没有被回收。

第二句输出：

         新生代回收前210771K，回收后1129K，回收数量209642K，Heap总量回收前278171K回收后68544K，回收总量209627K。这就表示有15k没有被回收。

比较一下启动时与现在的新生代占用内存情况和Heap使用情况发现Heap的使用增长很明显，新生代没有增长，而Heap使用总量增长了27M，这就表明可能存在内存泄露，虽然每一次泄露的字节数很少，但是频率很高，大部分泄露的对象都被升级到了中生代或者持久代。

又一段时间后：

[GC [DefNew: 211554K->1913K(235968K), 0.0461130 secs] 350102K->140481K(648160K), 0.0469790 secs]

[GC [DefNew: 211707K->2327K(235968K), 0.0546170 secs] 350275K->140921K(648160K), 0.0555070 secs]

第一句输出：

         新生代回收前211554K，回收后1913K，回收数量209641K，Heap总量回收前350102K回收后140481K，回收总量209621K。这就表示有20k没有被回收。

         分析到这里就可以看出每一次泄露的内存只有10几K，但是在大压力长时间的测试下，内存泄露还是很明显的，此时Heap已经增长到了140M，较启动时已经增长了100M。同时GC占用的时间越来越长。

后续的现象：

         后续观察日志会发现，Full GC的频率越来越高，收集所花费时间也是越来越长。（Full GC定期会执行，同时局部回收不能满足分配需求的情况下也会执行）。

[Full GC [Tenured: 786431K->786431K(786432K), 3.4882390 secs] 1022399K->1022399K(1022400K), [Perm : 36711K->36711K(98304K)], 3.4887920 secs]

java.lang.OutOfMemoryError: Java heap space

Dumping heap to java_pid7720.hprof ...

         出现这个语句表示内存真的被消耗完了。

Jdk1.6 log：

启动时GC的输出：

[GC [PSYoungGen: 221697K->31960K(229376K)] 225788K->36051K(491520K), 0.0521830 secs] [Times: user=0.26 sys=0.05, real=0.05 secs]

[GC [PSYoungGen: 228568K->32752K(229376K)] 232659K->37036K(491520K), 0.0408620 secs] [Times: user=0.21 sys=0.02, real=0.04 secs]

第一句输出：

         新生代回收前221697K，回收后31960K，回收数量189737K，Heap总量回收前225788K回收后36051K，回收总量189737K。100%被回收。

运行一段时间后输出：

[GC [PSYoungGen: 258944K->2536K(259328K)] 853863K->598135K(997888K), 0.0471620 secs] [Times: user=0.15 sys=0.00, real=0.05 secs]

[GC [PSYoungGen: 259048K->2624K(259328K)] 854647K->598907K(997888K), 0.0462980 secs] [Times: user=0.16 sys=0.02, real=0.04 secs]

第一句输出：

         新生代回收前258944K，回收后2536K，回收数量256408K，Heap总量回收前853863K回收后598135K，回收总量255728K。680K没有被回收，但这并不意味着就会产生内存泄露。同时可以看出GC回收时间并没有增加。

在运行一段时间后输出：

[GC [PSYoungGen: 258904K->2488K(259264K)] 969663K->713923K(1045696K), 0.0485140 secs] [Times: user=0.16 sys=0.01, real=0.04 secs]

[GC [PSYoungGen: 258872K->2448K(259328K)] 970307K->714563K(1045760K), 0.0473770 secs] [Times: user=0.16 sys=0.01, real=0.05 secs]

第一句输出：

         新生代回收前258904K，回收后2488K，回收数量256416K，Heap总量回收前969663K回收后713923K，回收总量255740K。676K没有被回收，同时总的Heap也有所增加。

         此时看起来好像和1.5的状况一样。但是查看了一下Full GC的执行还是400-500次GC执行一次，因此继续观察。

运行一天多以后输出：

[GC [PSYoungGen: 257016K->3304K(257984K)] 1019358K->766310K(1044416K), 0.0567120 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]

[GC [PSYoungGen: 257128K->2920K(258112K)] 1020134K->766622K(1044544K), 0.0549570 secs] [Times: user=0.19 sys=0.00, real=0.05 secs]

可以发现Heap增长趋缓。

运行两天以后输出：

[GC [PSYoungGen: 256936K->3584K(257792K)] 859561K->606969K(1044224K), 0.0565910 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]

[GC [PSYoungGen: 256960K->3368K(257728K)] 860345K->607445K(1044160K), 0.0553780 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]

发现Heap反而减少了，此时可以对内存泄露问题作初步排除了。（其实在jdk1.6环境下用jprofiler来观察，对于concurrent那个内存泄露点的跟踪发现，内存的确还是会不断增长的，不过在一段时间后还是有回收，因此也就可以部分解释前面出现的情况）

总结：

         对于GC输出的观察需要分两个维度来看。一个是纵向比较，也就是一次回收对于内存变化的观察。一个是横向比较，对于长时间内存分配占用情况的比较，这部分比较需要较长时间的观察，不能仅仅凭短时间的几个抽样比较，因为对于抽样来说，Full GC前后的区别，运行时长的区别，资源瞬时占用的区别都会影响判断。同时要结合Full GC发生的时间周期，每一次GC收集所耗费的时间作为辅助判断标准。

         顺便说一下，Heap的 YoungGen,OldGen,PermGen的设置也是需要注意的，并不是越大越好，越大执行收集的时间越久，但是可能执行Full GC的频率会比较低，因此需要权衡。这些仔细的去了解一下GC的基础设计思想会更有帮助，不过一般用默认的也不错。还有就是可以配置一些特殊的GC，并行，同步等等，充分利用多CPU的资源。

         对于GC的优化可以通过现在很多图形工具来做，也可以类似于我这样采用最原始的分析方式，好处就是任何时间任何地点只要知道原理就可以分析无需借助外部工具。原始的总是最好的^_^。

         从去年到今年，开放这个词也在互联网上炒得火热，自己一年多的工作也让自己对开放这个词有了自己的一些理解和认识。

         写了那么些，其实思路比较乱，我想从随笔里面也看得出来，但是还是想记录一下自己的一些思考，起码以后回过头来可以看到自己成长的过程。

    昨天贴了这个帖子以后，有同学说我是不是写错了，Memcached Cache应该是分布式的Cache，怎么变成集中式了。

    这里把我另外一部分的内容贴出来。

    Memcached是一种集中式Cache，支持分布式横向扩展。这里需要有点说明，很多开发者觉得Memcached是一种分布式Cache，但是其实Memcached服务端本身是单实例的，只是在客户端实现过程中可以根据存储的主键作分区存储，而这个区就是Memcached服务端的一个或者多个实例，如果将客户端也囊括到Memcached中，那么可以部分概念上说是集中式的。其实回顾一下集中式的构架，无非两种情况：1.节点均衡的网状（JBoss Tree Cache），利用JGroup的多播通信机制来同步数据。2.Master-Slaves模式（分布式文件系统），由Master来管理Slave，如何选择Slave，如何迁移数据，都是由Master来完成，但是Master本身也存在单点问题。

总结几个它的特点来理解一下它的优点和限制。

         Memory：内存存储，不言而喻，速度快，对于内存的要求高，不指出的话所缓存的内容非持久化。对于CPU要求很低，所以常常采用将Memcached服务端和一些CPU高消耗Memory低消耗应用部属在一起。（作为我们AEP正好有这样的环境，我们的接口服务器有多台，接口服务器对于CPU要求很高（由于WS-Security），但是对于Memory要求很低，因此可以用作Memcached的服务端部属机器）

         集中式Cache：避开了分布式Cache的传播问题，但是需要非单点保证其可靠性，这个就是后面集成中所作的cluster的工作，可以将多个Memcached作为一个虚拟的cluster，同时对于cluster的读写和普通的memcached的读写性能没有差别。

         分布式扩展：Memcached的很突出一个优点，就是采用了可分布式扩展的模式。可以将部属在一台机器上的多个Memcached服务端或者部署在多个机器上的Memcached服务端组成一个虚拟的服务端，对于调用者来说完全屏蔽和透明。提高的单机器的内存利用率，也提供了scale out的方式。

         Socket通信：传输内容的大小以及序列化的问题需要注意，虽然Memcached通常会被放置到内网作为Cache，Socket传输速率应该比较高（当前支持Tcp和udp两种模式，同时根据客户端的不同可以选择使用nio的同步或者异步调用方式），但是序列化成本和带宽成本还是需要注意。这里也提一下序列化，对于对象序列化的性能往往让大家头痛，但是如果对于同一类的Class对象序列化传输，第一次序列化时间比较长，后续就会优化，其实也就是说序列化最大的消耗不是对象序列化，而是类的序列化。如果穿过去的只是字符串，那么是最好的，省去了序列化的操作，因此在Memcached中保存的往往是较小的内容。

         特殊的内存分配机制：首先要说明的是Memcached支持最大的存储对象为1M。它的内存分配比较特殊，但是这样的分配方式其实也是对于性能考虑的，简单的分配机制可以更容易回收再分配，节省对于CPU的使用。这里用一个酒窖比喻来说明这种内存分配机制，首先在Memcached起来的时候可以通过参数设置使用的总共的Memory，这个就是建造一个酒窖，然后在有酒进入的时候，首先申请（通常是1M）的空间，用来建酒架，酒架根据这个酒瓶的大小分割酒架为多个小格子安放酒瓶，将同样大小范围内的酒瓶都放置在一类酒架上面。例如20cm半径的酒瓶放置在可以容纳20-25cm的酒架A上，30cm半径的酒瓶就放置在容纳25-30cm的酒架B上。回收机制也很简单，首先新酒入库，看看酒架是否有可以回收的地方，如果有直接使用，如果没有申请新的地方，如果申请不到，采用配置的过期策略。这个特点来看，如果要放的内容大小十分离散，同时大小比例相差梯度很明显，那么可能对于使用空间来说不好，可能在酒架A上就放了一瓶酒，但占用掉了一个酒架的位置。

         Cache机制简单：有时候很多开源的项目做的面面俱到，但是最后也就是因为过于注重一些非必要性的功能而拖累了性能，这里要提到的就是Memcached的简单性。首先它没有什么同步，消息分发，两阶段提交等等，它就是一个很简单的Cache，把东西放进去，然后可以取出来，如果发现所提供的Key没有命中，那么就很直白的告诉你，你这个key没有任何对应的东西在缓存里，去数据库或者其他地方取，当你在外部数据源取到的时候，可以直接将内容置入到Cache中，这样下次就可以命中了。这里会提到怎么去同步这些数据，两种方式，一种就是在你修改了以后立刻更新Cache内容，这样就会即时生效。另一种是说容许有失效时间，到了失效时间，自然就会将内容删除，此时再去去的时候就会命中不了，然后再次将内容置入Cache，用来更新内容。后者用在一些时时性要求不高，写入不频繁的情况。

         客户端的重要性：Memcached是用C写的一个服务端，客户端没有规定，反正是Socket传输，只要语言支持Socket通信，通过Command的简单协议就可以通信，但是客户端设计的合理十分重要，同时也给使用者提供了很大的空间去扩展和设计客户端来满足各种场景的需要，包括容错，权重，效率，特殊的功能性需求，嵌入框架等等。

         几个应用点：小对象的缓存（用户的token，权限信息，资源信息）。小的静态资源缓存。Sql结果的缓存（这部分用的好，性能提高相当大，同时由于Memcached自身提供scale out，那么对于db scale out的老大难问题无疑是一剂好药）。ESB消息缓存。

问题一：连接池泄漏

       看到这个问题，我想很多人都说，都什么年代了，使用开源的现成连接池，怎么还会有这样的问题，又不是那些使用jdbc的年代了。那来看看现象吧。

场景：测试部用loadRunner往死里压，发现很多业务对象不断增长，但是按照业务场景来说，这些业务对象处理以后就自动释放了。（在本地的开发环境验证了是会自动释放的）

JProfiler截图：

       上图中可以看到有很多业务对象已经累积占用了不少内存，在让测试部同学停掉压力测试以后，等待了一会儿，然后用JProfiler主动发起垃圾回收，也看到了Jboss后台有GC回收的记录输出以后，发现这些对象依然存在，也就是说这些对象成为了Memory泄漏的诱因之一。但是就如我所说的，在本地测试以及白盒测试来看，这些对象在一次请求以后，处理完毕一定会被释放，没有被其他Map等Reference，然后通过JProfiler看了看这些对象的Allocation Call Tree，就是我们处理请求的Servlet作为源头的，但为什么Servlet没有被清理掉呢？接着来看看后面二张图

       既然知道对象存在并且被Hold了，那么就去看看线程运行的状况，这一看发现有很多线程都处于Wait的状态（其实在server作dump也可以看到），这张图上就可以看到，我选择了其中一个wait的线程它处于等待状态的原因就是在ibatis的Throttle作increment的时候处于等待状态，看了看ibatis的代码，这部分代码其实是ibatis连接池的一段代码，在连接池被占满以后，处于等待释放的状态，也就是说程序把连接池耗尽了。

       为了验证是否是耗尽了，让DBA老大光辉给我看了看MySql（这部分当天的日志数据都保存在MySql中）的连接情况，发现只有8个连接，看来不是真的耗尽，应该是连接池泄露了。光辉告诉我，这八个连接都在做同一个查询，就是统计某一个API的访问记录次数和流量。在当前的业务流程中对于MySql主要做了两类操作：

       1．访问控制计数器创建的统计查询。

由于要对Open API访问控制，采用了Memcache计数器方式来实现。当发现此类API没有创建过计数器，那么就分析MySql中的数据，创建计数器，后续的访问记录除了插入数据库以外还需要累加计数器，这样访问控制可以高效使用集中式计数器而不需要查询数据库。

2．日志批量异步写入。

对于Open API的记录采用了线程池中每一个线程维护一个内存分页，当页满或者到了刷新间隔时，一次性批量写入数据库，缓解数据库写入压力，这里采用了事务来批量提交。

       对于第一种操作，由于设计中MySql就只会保留当天的数据量，因此只有系统启动的时候做一次统计，对于数据库压力和Sql执行来说应该没有太大的压力，但是由于压力测试是从昨天下午就开始做的，里面的数据已经有上千万，因此这次重新启动开始做压力测试，导致了这个创建计数器的Sql执行很慢。同时日志的批量写入采用的是事务方式来提交，对于MySql其实自己还不是很深入，但是感觉上来说，问题应该出现在这里，由于查询的缓慢在加上事务批量的提交，可能会造成事务失败，同时没有正确的将释放资源的信号传递给ibatis，导致了看起来的连接资源耗尽。

       我将数据库中的记录全部删除，然后重新启动，开始压力测试，问题不存在了，对象都及时得到回收。后续还会去跟进这个问题，在ibatis早期版本，同样是这个类出现了死锁的问题，后来升级得到了解决，但是也看到很多国外的朋友说道2.2和2.3其实还是有死锁的问题，不过我个人觉得可能还是和数据库也有一定关系。

疑问：

       这个问题的背后我还有一点疑问，对于我们来说，如果一个普通的http请求，当超时以后肯定就会自动中断，但是在这个场景中，我足足等了1个小时还是没有释放，也就是说客户端其实已经断开了，但是JBoss好像并不会释放这些处理请求的事务，导致资源被卡。

问题二：LinkedBlockingQueue惹祸

       自从Jdk1.5以后concurrent包为大家提供了很多便利高效的开发新模式，我在不少地方用到了LinkedBlockingQueue，作为消费者和生产者之间的数据通道，消费者们等待在LinkedBlockingQueue门口守候生产者提供数据，获取数据后就开始并行处理。这里我会采用queue.poll(100,TimeUnit.MILLISECONDS)这种方式来半阻塞的获取数据。其实在昨天已经听说LinkedBlockingQueue可能存在着内存泄露的问题，看了看很多网上的人也都提到了这个问题，在1.5种没有得到解决，在1.6中会去fix这个问题，但是没有证据，也不好乱加断定。在问题一搞好以后，然后继续查找潜在bug，这时候不经意的发现有一个对象随着时间的推移始终在增加，但是由于单个对象占的内存不大，因此没有很明显的体现出来，但是对象实例的增加却是很明显的，看看下面两张图：

这两张图的间隔时间2小时左右，可以发现这个对象的instance已经有了很大的增长，同时内存也吃了不少，看了看创建这个对象的Tree，发现就是poll这个方法，也就是我线程池中线程周期性扫描的结果。这期间没有任何访问，仅仅就是放着不动，就有如此大量的增长。我尝试将poll(100,TimeUnit.MILLISECONDS)换成poll()全阻塞方式，对象增长依旧。因此可以看出来服务器的Memory Leak很大程度上由这部分引起，早先没有发现，因为是SIP上线不久，没有太多用户，而这阵子用户越来越多，加上API中的更新类请求比较吃内存，就容易发现此类问题。

       那么是否1.6就解决了这个问题呢，开始使用机器上1.6_01的版本，发现问题依旧，去sun下载了最新的1.6_07，发现的却会回收，但是回收和增长都存在，具体数据描述举例如下：

1.       1000 instance   31k

2.       200 instance    6k (回收了一部分)

3.       1500 instance   46k（发现增长的比以前还多）

4.       300 instance    9k (回收了一部分)

5.       2000 instance   62k （发现增长的比以前还多）

也就是说，回收时有发生，但是总体趋势还是在上升，这个真的还需要好好测试，有兴趣的同学也可以试验一下我的测试方式，就仅仅只需要使用一个LinkedBlockingQueue，然后定时的去pool，1.5绝对增长的不小。

       对于这个问题，我只能再去验证，如果发现真的暂时不可避免，那么只有考虑替代方案了。

这是今天作了Memory Leak的一些分享，希望也能给其他遇到或者将会遇到问题的同学一个分享，说一句，如果有条件的话用JProfiler去分析性能绝对是不错的，没有条件么就dump,gc输出来查找问题。
   刚刚作了测试现在的场景可以用take来替换poll，原来是看中了poll的timeout方式，take完全没有问题，看来如果要在1.5版本用，还是老老实实用take。

       集团内部很多团队都使用Memcache来提高应用性能，最近的一次工作汇报中提及了Memcache的Hash算法需要研究来满足一些需求，同时提高Memcache的利用效率。讨论了一下最后自己总结了这么几点是对Hash算法需要着重考虑的。

问题：

1.       存储数据如何均匀分散。如何把数据尽可能的散开存储，这样对于Memcache的可扩展性才会有充分利用，试想如果算法每次都会把数据定向到某几台机器，那么就会导致集群机器之间利用率的不均衡，无法发挥出集群效应。

2.       增减机器减小对原有数据存取的影响。由于业务量的增长势必需要对后端的服务器有所扩容，但是增加或者减少机器如何尽可能小的影响已有的缓存数据，这点直接影响业务处理以及应用的效率。

3.       提高Memcache效率。Memcache在压力测试下也会暴露出对于网络资源的消耗问题，毕竟也是网络间的Socket数据交互。

解决的一些思路和方法：

1．       Consistent Hashing是一种比较好的解决思路。可以参看一下：http://tech.idv2.com/2008/07/24/memcached-004/ 其中主要两个亮点就是稀释节点以及环状分区段管理。稀释节点就是将原来的节点再复制几十倍，使得离散度更高，数据更加分散。环状分区段管理，就能够将数据分区管理，在加入和减少节点时对数据产生影响最低，最好的类比就是解放前的地下工作者单线联系，如果被捕不会涉及到所有的地下党同志。

2．       集群的机器使用Memcache最好结合本地Cache，这里我们自己写了一个本地的类似于Memcache有超时时间Cache，两者结合一起使用缓存信息，在压力测试下提高了20%左右的性能。这里和我们的系统也有关系，我们对于Memcache有比较大的依赖，虽然已经对于每一个请求处理都防止重复获取信息，将必要信息放在线程上下文中，但是在运行期间还是会有不少的请求。

存储到Memcache中的数据类型：

1． 一次写入多次读，很少更新。这种数据系统启动以后构建，在非命中情况下不采用从后备数据源中获取数据来填充Memcache。（也是提高效率，同时防止一些攻击性的请求）

2． 多次写入多次读取。这类数据往往是在运行期被构建，非命中下会从后备数据源中获取，或者是某一种计算结果的缓存。

对于第一类数据来说，增加机器需要重新构建，如果采用分区分段，那么只需要构建某一部分的数据，或者是移动数据。对于第二类数据，增加机器如果采用简单的Hash算法也问题不大，最多存储多份，命中率降低，但是如果采用分区，也可以降低命中率下降的情况。

引

最近关注Hadoop，因此也顺便关注了一下Hadoop相关的项目。HBASE就是基于Hadoop的一个开源项目，也是对Google的BigTable的一种实现。

       BigTable是什么？Google的Paper对其作了充分的说明。字面上看就是一张大表，其实和我们想象的传统数据库的表还是有些差别的。松散数据可以说是介于Map Entry（key & value）和DB Row之间的一种数据。在我使用Memcache的时候，有时候的需求是需要存储的不仅仅是简单的一个key对应一个value，可能我需要类似于数据库表结构中多属性的存储，但是又不会有传统数据库表结构中那么多关联关系的需求，其实这类数据就是所谓的松散数据。BigTable最浅显来看就是一张很大的表，表的属性可以根据需求去动态增加，但是又没有表与表之间关联查询的需求。

       互联网应用有一个最大的特点，就是速度，功能再强大，速度慢，还是会被舍弃。因此在大访问量的网站都采取前后的缓存来提升性能和响应时间。对于Map Entry类型的数据，集中式分布式Cache都有很多选择，对于传统的关系型数据，从MySQL到Oracle都给了很好的支持，唯有松散数据这类数据，采用前后两种解决方案都不能最大化它的处理能力。因此BigTable才有了它用武之地。

       HBASE作为Apache的开源项目，也是出于起步阶段，因为其实它所依赖的Hadoop也不能说已经到了成熟阶段，所以都有很大的发展空间，这也为我们这些开源爱好者提供了更多空间去贡献。这里主要会谈到HBASE的框架设计方面的知识和它的一些特点，不论是否采用HBASE去解决工作中的问题，一种好的流程设计总会给开发者和架构设计者带来一些思想上的火花。

HBASE设计介绍

数据模型

       HBASE中的每一张表，就是所谓的BigTable。BigTable会存储一系列的行记录，行记录有三个基本类型的定义：Row Key,Time Stamp,Column。Row Key是行在BigTable中的唯一标识，Time Stamp是每次数据操作对应关联的时间戳，可以看作类似于SVN的版本，Column定义为：<family>:<label>，通过这两部分可以唯一的指定一个数据的存储列，family的定义和修改需要对HBASE作类似于DB的DDL操作，而对于label的使用，则不需要定义直接可以使用，这也为动态定制列提供了一种手段。family另一个作用其实在于物理存储优化读写操作，同family的数据物理上保存的会比较临近，因此在业务设计的过程中可以利用这个特性。

看一下逻辑数据模型：

上表中有一列，列的唯一标识为com.cnn.www，每一次逻辑修改都有一个timestamp关联对应，一共有四个列定义：<contents:>,<anchor:cnnsi.com>,<anchor:my.look.ca>,<mime:>。如果用传统的概念来将BigTable作解释，那么BigTable可以看作一个DB Schema，每一个Row就是一个表，Row key就是表名，这个表根据列的不同可以划分为多个版本，同时每个版本的操作都会有时间戳关联到操作的行。

再看一下HBASE的物理数据模型：

物理数据模型其实就是将逻辑模型中的一个Row分割成为根据Column family存储的物理模型。

对于BigTable的数据模型操作的时候，会锁定Row，并保证Row的原子操作。

框架结构及流程

图1 框架结构图

       HBASE依托于Hadoop的HDFS作为存储基础，因此结构也很类似于Hadoop的Master-Slave模式，Hbase Master Server 负责管理所有的HRegion Server，但Hbase Master Server本身并不存储HBASE中的任何数据。HBASE逻辑上的Table被定义成为一个Region存储在某一台HRegion Server上，HRegion Server 与Region的对应关系是一对多的关系。每一个HRegion在物理上会被分为三个部分：Hmemcache、Hlog、HStore，分别代表了缓存，日志，持久层。通过一次更新流程来看一下这三部分的作用：

图2 提交更新以及刷新Cache流程

       由流程可以看出，提交更新操作将会写入到两部分实体中，HMemcache和Hlog中，HMemcache就是为了提高效率在内存中建立缓存，保证了部分最近操作过的数据能够快速的被读取和修改，Hlog是作为同步Hmemcache和Hstore的事务日志，在HRegion Server周期性的发起Flush Cache命令的时候，就会将Hmemcache中的数据持久化到Hstore中，同时会清空Hmemecache中的数据，这里采用的是比较简单的策略来做数据缓存和同步，复杂一些其实可以参照java的垃圾收集机制来做。

       在读取Region信息的时候，优先读取HMemcache中的内容，如果未取到再去读取Hstore中的数据。

几个细节：

1．              由于每一次Flash Cache，就会产生一个Hstore File，在Hstore中存储的文件会越来越多，对性能也会产生一定影响，因此达到设置文件数量阀值的时候就会Merge这些文件为一个大文件。

2．              Cache大小的设置以及flush的时间间隔设置需要考虑内存消耗以及对性能的影响。

3．              HRegion Server每次重新启动的时候会将Hlog中没有被Flush到Hstore中的数据再次载入到Hmemcache，因此Hmemcache过大对于启动的速度也有直接影响。

4．              Hstore File中存储数据采用B-tree的算法，因此也支持了前面提到对于Column同Family数据操作的快速定位获取。

5．              HRegion可以Merge也可以被Split，根据HRegion的大小决定。不过在做这些操作的时候HRegion都会被锁定不可使用。

6．              Hbase Master Server通过Meta-info Table来获取HRegion Server的信息以及Region的信息，Meta最顶部的一个Region是虚拟的一个叫做Root Region，通过Root Region可以找到下面各个实际的Region。

7．              客户端通过Hbase Master Server获得了Region所在的Region Server，然后就直接和Region Server进行交互，而对于Region Server相互之间不通信，只和Hbase Master Server交互，受到Master Server的监控和管理。

后话

       对HBase还没有怎么使用，仅仅只是看了wiki去了解了一下结构和作用，暂时还没有需要使用的场景，不过对于各种开源项目的设计有所了解，对自己的框架结构设计也会有很多帮助，因此分享一下。

这部分内容是分布式计算开源框架Hadoop入门实践的第二部分,讲述了关于实际使用配置的内容.第三部分是对于集群配置的测试结果分析的部分,下周三应该会在InfoQ刊登.

http://www.infoq.com/cn/articles/hadoop-config-tip

http://www.infoq.com/cn/articles/hadoop-intro

SIP的第四期结束了，因为控制策略的丰富，早先的的压力测试结果已经无法反映在高并发和高压力下SIP的运行状况，因此需要重新作压力测试。跟在测试人员后面做了快一周的压力测试，压力测试的报告也正式出炉，本来也就算是告一段落，但第二天测试人员说要修改报告，由于这次作压力测试的同学是第一次作，有一个指标没有注意，因此需要修改几个测试结果。那个没有注意的指标就是load average，他和我一样开始只是注意了CPU，内存的使用状况，而没有太注意这个指标，这个指标与他们通常的限制（10左右）有差别。重新测试的结果由于这个指标被要求压低，最后的报告显然不如原来的好看。自己也没有深入过压力测试，但是觉得不搞明白对将来机器配置和扩容都会有影响，因此去问了DBA和SA，得到的结果相差很大，看来不得不自己去找找问题的根本所在了。

       通过下面的几个部分的了解，可以一步一步的找出Load Average在压力测试中真正的作用。

CPU时间片

       为了提高程序执行效率，大家在很多应用中都采用了多线程模式，这样可以将原来的序列化执行变为并行执行，任务的分解以及并行执行能够极大地提高程序的运行效率。但这都是代码级别的表现，而硬件是如何支持的呢？那就要靠CPU的时间片模式来说明这一切。程序的任何指令的执行往往都会要竞争CPU这个最宝贵的资源，不论你的程序分成了多少个线程去执行不同的任务，他们都必须排队等待获取这个资源来计算和处理命令。先看看单CPU的情况。下面两图描述了时间片模式和非时间片模式下的线程执行的情况：

图 1 非时间片线程执行情况

图 2 非时间片线程执行情况

       在图一中可以看到，任何线程如果都排队等待CPU资源的获取，那么所谓的多线程就没有任何实际意义。图二中的CPU Manager只是我虚拟的一个角色，由它来分配和管理CPU的使用状况，此时多线程将会在运行过程中都有机会得到CPU资源，也真正实现了在单CPU的情况下实现多线程并行处理。

       多CPU的情况只是单CPU的扩展，当所有的CPU都满负荷运作的时候，就会对每一个CPU采用时间片的方式来提高效率。

       在Linux的内核处理过程中，每一个进程默认会有一个固定的时间片来执行命令（默认为1/100秒），这段时间内进程被分配到CPU，然后独占使用。如果使用完，同时未到时间片的规定时间，那么就主动放弃CPU的占用，如果到时间片尚未完成工作，那么CPU的使用权也会被收回，进程将会被中断挂起等待下一个时间片。

CPU利用率和Load Average的区别

       压力测试不仅需要对业务场景的并发用户等压力参数作模拟，同时也需要在压力测试过程中随时关注机器的性能情况，来确保压力测试的有效性。当服务器长期处于一种超负荷的情况下运行，所能接收的压力并不是我们所认为的可接受的压力。就好比项目经理在给一个人估工作量的时候，每天都让这个人工作12个小时，那么所制定的项目计划就不是一个合理的计划，那个人迟早会垮掉，而影响整体的项目进度。

CPU利用率在过去常常被我们这些外行认为是判断机器是否已经到了满负荷的一个标准，看到50%-60%的使用率就认为机器就已经压到了临界了。CPU利用率，顾名思义就是对于CPU的使用状况，这是对一个时间段内CPU使用状况的统计，通过这个指标可以看出在某一个时间段内CPU被占用的情况，如果被占用时间很高，那么就需要考虑CPU是否已经处于超负荷运作，长期超负荷运作对于机器本身来说是一种损害，因此必须将CPU的利用率控制在一定的比例下，以保证机器的正常运作。

Load Average是CPU的Load，它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。为什么要统计这个信息，这个信息的对于压力测试的影响究竟是怎么样的，那就通过一个类比来解释CPU利用率和Load Average的区别以及对于压力测试的指导意义。

我们将CPU就类比为电话亭，每一个进程都是一个需要打电话的人。现在一共有4个电话亭（就好比我们的机器有4核），有10个人需要打电话。现在使用电话的规则是管理员会按照顺序给每一个人轮流分配1分钟的使用电话时间，如果使用者在1分钟内使用完毕，那么可以立刻将电话使用权返还给管理员，如果到了1分钟电话使用者还没有使用完毕，那么需要重新排队，等待再次分配使用。

图 3 电话使用场景

       上图中对于使用电话的用户又作了一次分类，1min的代表这些使用者占用电话时间小于等于1min，2min表示使用者占用电话时间小于等于2min，以此类推。根据电话使用规则，1min的用户只需要得到一次分配即可完成通话，而其他两类用户需要排队两次到三次。

       电话的利用率 = sum (active use cpu time)/period

每一个分配到电话的使用者使用电话时间的总和去除以统计的时间段。这里需要注意的是是使用电话的时间总和(sum(active use cpu time))，这与占用时间的总和(sum(occupy cpu time))是有区别的。（例如一个用户得到了一分钟的使用权，在10秒钟内打了电话，然后去查询号码本花了20秒钟，再用剩下的30秒打了另一个电话，那么占用了电话1分钟，实际只是使用了40秒）

电话的Average Load体现的是在某一统计时间段内，所有使用电话的人加上等待电话分配的人一个平均统计。

电话利用率的统计能够反映的是电话被使用的情况，当电话长期处于被使用而没有的到足够的时间休息间歇，那么对于电话硬件来说是一种超负荷的运作，需要调整使用频度。而电话Average Load却从另一个角度来展现对于电话使用状态的描述，Average Load越高说明对于电话资源的竞争越激烈，电话资源比较短缺。对于资源的申请和维护其实也是需要很大的成本，所以在这种高Average Load的情况下电话资源的长期“热竞争”也是对于硬件的一种损害。

低利用率的情况下是否会有高Load Average的情况产生呢？理解占有时间和使用时间就可以知道，当分配时间片以后，是否使用完全取决于使用者，因此完全可能出现低利用率高Load Average的情况。由此来看，仅仅从CPU的使用率来判断CPU是否处于一种超负荷的工作状态还是不够的，必须结合Load Average来全局的看CPU的使用情况和申请情况。

所以回过头来再看测试部对于Load Average的要求，在我们机器为8个CPU的情况下，控制在10 Load左右，也就是每一个CPU正在处理一个请求，同时还有2个在等待处理。看了看网上很多人的介绍一般来说Load简单的计算就是2* CPU个数减去1-2左右（这个只是网上看来的，未必是一个标准）。

补充几点：

1．对于CPU利用率和CPU Load Average的结果来判断性能问题。首先低CPU利用率不表明CPU不是瓶颈，竞争CPU的队列长期保持较长也是CPU超负荷的一种表现。对于应用来说可能会去花时间在I/O,Socket等方面，那么可以考虑是否后这些硬件的速度影响了整体的效率。

这里最好的样板范例就是我在测试中发现的一个现象：SIP当前在处理过程中，为了提高处理效率，将控制策略以及计数信息都放置在Memcached Cache里面，当我将Memcached Cache配置扩容一倍以后，CPU的利用率以及Load都有所下降，其实也就是在处理任务的过程中，等待Socket的返回对于CPU的竞争也产生了影响。

2．未来多CPU编程的重要性。现在服务器的CPU都是多CPU了，我们的服务器处理能力已经不再按照摩尔定律来发展。就我上面提到的电话亭场景来看，对于三种不同时间需求的用户来说，采用不同的分配顺序，我们可看到的Load Average就会有不同。假设我们统计Load的时间段为2分钟，如果将电话分配的顺序按照：1min的用户，2min的用户，3min的用户来分配，那么我们的Load Average将会最低，采用其他顺序将会有不同的结果。所以未来的多CPU编程可以更好的提高CPU的利用率，让程序跑的更快。

以上所提到的内容未必都是很准确或者正确，如果有任何的偏差也请大家指出，可以纠正一些不清楚的概念。

       工作忙，有些许时间没有更新Blog了，这次在开发监控模块的时候遇到了这个问题，整个问题定位过程真是走了不少路，所以觉得有必要记录下来分享一下。在我看来很多时候结果也许就很简单一个原因，但是开发人员却要探究很久，也许在找到了其他可实现业务逻辑方法的情况下，就会放弃寻找原因，这期间我也是一样。

问题初现：

       在服务集成平台中需要新增一块写入数据库的逻辑，因此考虑最简便就是弄个Spring的BeanFactory来搞定这一切，谁知道，问题就这么出现了。很简单，通过Spring的ClassPathXmlApplicationContext来构建BeanFactory，下面的语句大家应该很熟悉：

ctx = new ClassPathXmlApplicationContext("/spring/sip-*.xml");

       通过通配符来载入ClassPath下的所有的符合规则的spring配置文件。然后在Eclipse中作完单元测试和集成测试，一切正常。然后用我们内部的打包部署，而这些配置文件都被打在Jar中作为lib库依赖。结果启动以后，在分析完日志需要写入到数据库的时候出现异常：

Could not resolve bean definition resource pattern [/spring/sip-*.xml]; nested exception is java.io.FileNotFoundException: class path resource [spring/] cannot be resolved to URL because it does not exist

就提示来说，就是没有找到spring这个目录，也就是在ClassPath下面就没有找到资源。

第一次试图解决问题：

以前调整过Jboss关于ClassLoader的配置，即自上而下搜索还是自下而上搜索，以及是否采用Web容器的ClassLoader，开始怀疑是否是这种修改造成的问题。修改了没有问题，然后就设置断点跟踪Spring的ClassPathXmlApplicationContext的构造过程，发现Spring在分析此类通配类型的过程中，首先将前面的文件目录和后面的具体通配文件分开，先定位文件目录资源，也就是在定位文件目录资源的过程中，找不到spring目录，而出现了那个异常。看了代码中也有对Jar的处理，但是在处理之前就出现了问题。

自己做了尝试，将spring目录和其内容解压到Web的Classes目录下运行正常，或者解压到war下面也是正常的，这些地方其实都是ClassPath可以找到的，但是lib目录下的jar也应该是可以找到的。在仔细跟踪了代码中最后载入这些资源的ClassLoader内的数据，所有的Jar都是包含在内的。

由于工作太多，因此将原有的打包模式作了修改，每次打包将这部分配置解压到war下面，这样就找到了可解决方案了，因此细致的缘由也就没有再去追究。（如果不是后面再次遇到，这个问题就会在此了结）

问题再现：

       监控模块中需要新增一块写入数据库的逻辑，在单元测试和集成测试通过的情况下出现了问题，由于此次是普通的J2SE的应用，所有的配置和依赖都打入在了Jar中，所以问题和前次一样。

       这次决定花一些时间好好找到问题所在，首先觉的Spring的资源载入应该不会不支持从Jar中载入，这是最基本的功能，因此再次打开了Spring的源码。

问题二次定位：

先看看ClassPathXmlApplicationContext的类图结构：

       在完成ASF集成REST以后，接到的任务就是要完成一个日志分析应用。需求没有很明确，只是要有这么一个东西能够满足分析收集后的日志，将分析后的原始数据入库，作为后期分析和统计使用。

       在动手做之前，我还是给这个应用作了最基本的需求定义：灵活配置（输入源，输出目标，分析器的实现等），高效（并行任务分解）。就这两点能够做到，那么将来需求如何变化都可以适应。Tiger的Concurrent包是满足后面那项最好的实现，因此打算好好的实践一把，也就这部分Tiger的特性还没有充分使用过，里面的线程池，异步服务调用，并发控制都能够极好的完成并行任务分解的工作。也就是在这个过程中，看到了IBM开发者论坛上的一片文章，讲关于《应用fork-join框架》，谈到了在J2SE 7 的Concurrent包中将会增加fork-join风格的并行分解库，其实这个是更细粒度的任务分解，同时能够在当前多CPU的情况下提高执行效率，充分利用CPU的一种实现。无关的话不多说了，就写一下整个设计和实现的过程以及中间的一些细节知识。

背景：

       由于服务路由应用访问量十分大，即时的将访问记录入库对于路由应用本身以及数据库来说无疑都会产生很大的压力和影响。因此考虑首先将访问信息通过log4j记录在本地（当然自己需要定制一下Log4j的Appender和Filter），然后通过服务器的定时任务脚本来将日志集中到日志分析应用所在的机器上（这里通过配置可以决定日志是根据什么时间间隔来产生新文件）。日志分析应用就比较单纯的读取日志，分析日志，输出分析结果（包括写入数据库或者是将即时统计信息存入到集中式缓存Memcached中）。网络结构图如下：

图1 网络结构图

Concurrent概述：

       Tiger出来也有些年头了，但是每一个新的特性是否都在实际的工作中使用过，起码我自己是没有作到的，包括对于Concurrent包也只是看过，写了几个Test case玩一下，但具体使用到实际开发中还是比较少的。在这个工作之前，如果考虑要使用对象池或者线程池，那么一定会去采用apache的common pool，不过在现在jdk日益“强大”的基础下，能够通过jdk自己搞定的，就尽量不再引入第三方包了。看Java 的Doc很容易就理解了Concurrent，这里我只是大致的说一下几个自己在应用中使用的接口：

BlockingQueue<E>：看看名字就知道了，阻塞式队列，可以设置大小。适合于生产者和消费者模式，生产者在队列满时阻塞，消费者在队列空时阻塞。在日志分析应用开发中被用于分析任务（生产者）和输出任务（消费者）之间的分析结果存储通道。

Callable<V>：任何需要执行的任务都可以定义成Callable，类似于线程的Runnable接口，可以被Service Executor指派给内部的线程异步执行，并且返回对象或者抛出异常。在日志分析应用开发中，非定时性的任务都定义成为此类型。

ConcurrentMap<K,V>：这个以前常常使用，因为效率要远远高于Collections.synchronizedCollection和synchronized。后面还会提到实践中的几个实用的技巧来防止在高并发的情况下出现问题。在日志分析应用中，此类型的Map作为保存日志文件分析状态的缓存（日志文件分为两种状态：分析中，分析结束。如果不存在于Map中就认为尚未分析，那么将其纳入Map然后启动分析处理线程工作，如果存在于Map中标示为分析中，那么将不会再分析此文件，如果分析结束并且被输出，将会标示此文件分析结束，异步清理线程将会定时根据策略删除或移动文件）。

ExecutorService：内置线程池，异步执行指派任务，并可以根据返回的Future来跟踪执行情况。在日志分析应用开发中，被用于非定时性任务执行。

ScheduledExecutorService：内置线程池，定时异步执行指派任务，并可以根据返回的Future来跟踪执行情况。在日志分析应用开发中，被用于定时性任务执行。

以上就是被使用到的接口，具体实现策略配置就不在此赘述了。

整体结构设计：

       整体设计还是基于开始设定的两个原则:灵活配置,高效性(任务分解,并行流水线执行)。说到任务分解又会想起读书时候的离散数学中关键路径等等。任务分解还是要根据具体情况来分析和设计，不然并行不但不会提高效率，反而还降低了处理效率。

就日志分析来看，主要的处理过程可以分成这么几个任务：

1．             检查日志来源目录，锁定需要分析的文件。（执行需要时间很短，可通过定时间隔执行）。

2．             分析已经被锁定的日志文件，产生分析结果。（执行需要时间根据日志文件大小来决定，因此需要线程异步执行，结果根据设定拆分成细粒度包，降低输出线程等待时间）。

3．             检查分析结果队列。（执行需要时间很短，当前是配置了SingleThreadExecutor来执行检查阻塞队列的工作，同时获取到分析结果包以后立刻创建线程来执行输出任务）

4．             输出分析结果，如果输出成功，将分析过的日志文件在日志文件状态缓存中的状态更新为已分析。（执行时间根据输出情况来定，当前实现的是批量输出到数据库中，根据配置来批量提交入库，后续还会考虑实时统计到集中式Cache作为监控使用）。

5．             清理分析日志文件。（执行时间较短，设定了定时线程池执行清理任务，根据策略配置来执行清理和移动文件任务，并且清除在日志文件状态缓存中的信息）

根据上面的分解可以看到，其实在单线程工作的过程中，容易造成阻塞而影响性能的主要是读取，分析和写出这三个过程的协调，一个一个读取分析和写出，性能一定低于读取和分析并行工作，而分析完毕才写出，性能一定低于分析部分，写出部分。

同时由于细分各个任务，因此任务与任务之间的耦合度降低，可以运行期获取具体的任务实现配置，达到灵活配置的目的。

下面就具体的看看整个流程，以及其中的一些细节的说明，这里根据下图中的序号来逐一描述：

1．              配置了Schedule Executor来检查日志所属目录中的日志文件，Executor的线程池大小以及检查时间间隔都根据配置来设定。

Tip:定时任务可以设置delay时间，那么可以根据你的任务数量以及时间间隔来设定每一个任务的delay时间，均匀的将这些任务分布，提高效率。

2．              当Read Schedule被执行时，将会去检查Analysis Log File State Concurrent Cache（也就是上面提到的ConcurrentMap）中是否存在此文件，如果不存在证明尚未分析，需要将其置入Cache，如果已经存在就去查询其他文件。Tip:这里用了一点小技巧，通常我们对于此类操作应该做两部分工作，get然后再put，但是这样可能就会在高并发的情况下出现问题，因为这两个操作不是一个原子操作。ConcurrentMap提供了putIfAbsent操作，这个操作意思就是说如果需要put的key没有存在于Map中，那么将会把key,value存入，并且返回null，如果已经存在了key那么就返回key在map已经对应的值。通过if (resources.putIfAbsent(filename, Constants.FILE_STATUS_ANALYSISING) == null)就可以把两个操作合并成为一个操作。

3．              日志读取的工作线程完成锁定文件以后，就将后续的工作交给Log Analysis Service Executor来创建分析任务异步执行分析操作，日志读取工作线程任务就此完成。

4．              Log Analysis Schedule是运行期装载具体的接口实现类（采用的就是类似于JAXP等框架使用的META-INF/services来读取工厂类，载入接口实现）。Analysis Schedule执行的主要任务就是分析文件，并且根据配置将分析结果拆分并串行的置入到Block Queue中，提供给输出线程使用。

5．              Receiver主要工作就是守候着Block Queue，当有数据结果产生就创建Write Schedule来异步执行输出。

6．              Log Writer Service Executor根据配置来决定内置线程池大小，同时在Receiver获取到数据包时产生Write Schedule来异步执行输出工作。

7．              Write Schedule和Analysis Schedule一样可以运行期装载接口实现类，这样提供了灵活的输出策略配置。

Tips:在数据库输出的时候需要配置批量提交记录最大数，分批提交提高性能，也防止过大结果集批量提交问题。

8．              写出完成以后需要更新锁定文件的状态，标示成为已经分析成功。这里还遗留一点问题，在一个日志文件分包的过程中每一个包都回记录隶属于哪一个分析文件，文件的最后一个数据包将会被标示。在输出成功以后会去检查哪些包是文件最后数据包，更新此文件为已分析成功，如果出现异常，那么将会把这些文件状态清除，接受下一次的重新分析。这里一个文件部分包提交暂时没有做到事务一致，如果出现部分成功可能会重复分析和记录。

9．              最后就是Clean Schedule被定时执行，根据策略来删除或者移动已经被分析过的文件。

Tips:

ScheduledExecutorService内部可以配置线程池，当执行定时任务比较耗时，线程池中的线程都被占用的情况下，定时任务将不会准确的按时执行，因此设计过程中需要注意的是，定时任务一般是简短的工作任务，如果比较耗时，那么应该结合ScheduledExecutorService和ExecutorService，定时任务完成必要工作以后将耗时工作转交给ExecutorService创建的即时执行异步线程去处理，保证Schedule Executor正常工作。

图2 流程结构设计

类图：

图3 类图1

       上面的类图中主要描述的就是日志分析应用的三个主类：类似于控制台的LogAnalyzer，具体内部资源管理类，配置类。（T表示采用泛型）

图 4 类图2

       类图2主要就是描述了在整个应用中所有的被分解可并行的任务定义。ClearSchedule是用来在控制台输入stop停止日志分析的时候，做后续资源回收工作的任务。CleanSchedule是用来清除被分析后的日志文件任务。ConsumerSchedule是阻塞队列消费者任务。

       其他还有一些辅助工具类以及工厂类和定义类就不画了。

后话：

       做这个设计和开发的过程中又好好的实践了一些编程细节方面的内容，作为架构设计来说，需要多一些全局观和业务观，作为一个良好的开发者来说需要多实践，多了解一些细节，在不断学习和掌握各种大方向技术框架的同时，适当的了解一些细节也是一种很好的补充，同时也可以衍生思考。

       REST风格的服务结合云计算的思想，会被使用的更为广泛，而云计算其实就是一个问题分解和组合处理的过程，可以说是一种宏观的问题解决策略。高效解决问题，提供服务，通过组合体现业务最大价值，就是互联服务的最重要目的。

更多文章请访问：http://blog.csdn.net/cenwenchu79/