岑文初

jdk采用1.5的压力测试结果压了一个周末回来就无法响应了，看了看它的GC输出：

全都是[Full GC [Tenured: 786431K->786431K(786432K), 3.4802480 secs] 1022399K->1022399K(1022400K), [Perm : 36711K->36711K(98304K)], 3.4808510 secs]

替换jdk1.5为jdk1.6昨天中午开始做压力测试到今天中午我取了一下日志，看见GC输出如下：

[GC [PSYoungGen: 256608K->3608K(257792K)] 859002K->606698K(1044224K), 0.0562040 secs] [Times: user=0.17 sys=0.01, real=0.05 secs]

这就很明显的看出了差别了，前者已经把家底全部都用完了，出于out of memory的状态了。后者还是普通的GC回收，回收效果很好，同时看了看jboss启动的时候回收后占用的YoungGen就1300K左右，因此跑了一天的压力测试应该说还算是正常。

Full GC也就是在年轻代无法满足内存分配要求的时候才去做，这时候其实对于中老两代来说应该已经可能被占用完毕了，Full GC发生频率也越来越高，服务器响应速度也越来越慢。

因此对于持久的压力测试来说，打印出GC可以很好的分析出应用本身的内存使用状况，避免长期运行中少量内存泄露最终导致的应用不可用。

顺便说一下memcache 客户端修改后的测试结果：

  测试方案：

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

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

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

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

         测试结论：

                   老版本的SIP性能和以前一样，并发500的时候，TPS接近480，CPU 68%

                   新版本的SIP性能比老版本好很多，并发500的时候，TPS接近770，且系统压力很小，CPU利用率平均只有16%

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

    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消息缓存。

Memcached 是什么？

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

内存存储：不言而喻，速度快，但对于内存的要求高。这种情况对CPU要求很低，所以常常采用将Memcached服务端和一些CPU高消耗内存、低消耗应用部署在一起。（我们的某个产品正好有这样的环境，我们的接口服务器有多台，它们对CPU要求很高——原因在于WS-Security的使用，但是对于内存要求很低，因此可以用作Memcached的服务端部署机器）。

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

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

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

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

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

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

几个应用点：小对象的缓存（用户的Token、权限信息、资源信息）；小的静态资源缓存；SQL结果的缓存（这部分如果用的好，性能提高会相当大，同时由于Memcached自身提供向上扩容，那么对于数据库向上扩容的老大难问题无疑是一剂好药）；ESB消息缓存。

优化MemCached系统Java客户端的原因

MemCached在大型网站被应用得越来越广泛，不同语言的客户端也都在官方网站上有提供，但是Java开发者的选择并不多。由于现在的MemCached服务端是用C写的，因此我这个C不太熟悉的人也就没有办法去优化它。当然对于它的内存分配机制等细节还是有所了解，因此在使用的时候也会十分注意，这些文章在网络上有很多。这里我重点介绍一下对于MemCache系统的Java客户端优化的两个阶段。

第一阶段：封装Whalin

第一阶段主要是在官方推荐的Java客户端之一whalin开源实现基础上做再次封装。

1. 缓存服务接口化：定义了IMemCache接口，在应用部分仅仅只是使用接口，为将来替换缓存服务实现提供基础。
2. 使用配置代替代码初始化客户端：通过配置客户端和SocketIO Pool属性，直接交由CacheManager来维护Cache Client Pool的生命周期，便于单元测试。
3. KeySet的实现：对于MemCached来说本身是不提供KeySet的方法的，在接口封装初期，同事向我提出这个需求的时候，我个人觉得也是没有必要提供，因为缓存轮询是比较低效的，同时这类场景，往往可以去数据源获取KeySet，而不是从MemCached去获取。但是SIP的一个场景的出现，让我不得不去实现了KeySet。
   SIP在作服务访问频率控制的时候需要记录在控制间隔期内的访问次数和流量，此时由于是集群，因此数据必须放在集中式的存储或者缓存中，数据库肯定撑不住这样大数据量的更新频率，因此考虑使用Memcached的很出彩的操作——全局计数器（storeCounter,getCounter,inc,dec），但是在检查计数器的时候如何去获取当前所有的计数器？我曾考虑使用DB或者文件，但是效率有问题，同时如果放在一个字段中的话，还会存在并发问题。因此不得不实现了KeySet，在使用KeySet的时候有一个参数，类型是Boolean，这个字段的存在是因为在Memcached中数据的删除并不是直接删除，而是标注一下，这样会导致实现keySet的时候取出可能已经删除的数据。如果对于数据严谨性要求低，速度要求高，那么不需要再去验证Key是否真的有效，而如果要求Key必须正确存在，就需要再多一次的轮询查找。
4. 集群的实现：Memcached作为集中式缓存，存在着集中式的致命问题：单点问题。虽然Memcached支持多Instance分布在多台机器上，但仅仅只是解决了数据全部丢失的问题，当其中一台机器出错以后，还是会导致部分数据的丢失，一个篮子掉在地上还是会把部分的鸡蛋打破。因此就需要实现一个备份机制，能够保证Memcached在部分失效以后，数据还能够依然使用，当然大家很多时候都用缓存不命中就去数据源获取的策略。然而在SIP的场景中，如果部分信息找不到就去数据库查找，很容易将SIP弄垮，因此SIP对于Memcached中的数据认为是可信的，做集群也是必要的。
5. LocalCache结合Memcached使用，提高数据获取效率：在第一次压力测试过程中，发现和原先预料的一样，Memcached并不是完全无损失的，Memcached是通过Socket数据交互来进行通信的，因此机器的带宽，网络IO，Socket连接数都是制约Memcached发挥其作用的障碍。Memcache的一个突出优点就是Timeout的设置，也就是可以对放进去的数据设置有效期，从而在一定的容忍时间内对那些不敏感的数据就可以不去更新，以提高效率。根据这个思想，其实在集群中的每一个Memcached客户端也可以使用本地的缓存，来存储获取过的数据，设置一定的失效时间，来减少对于Memcached的访问次数，提高整体性能。

因此，在每一个客户端中都内置了一个有超时机制的本地缓存（采用Lazy Timeout机制），在获取数据的时候，首先在本地查询数据是否存在，如果不存在则再向Memcache发起请求，获得数据以后，将其缓存在本地，并设置有效时间。方法定义如下：

/**

  * 降低memcache的交互频繁造成的性能损失，因此采用本地cache结合memcache的方式

  * @param key

  * @param 本地缓存失效时间单位秒

  * @return

**/

public Object get(String key,int localTTL);

第二阶段：优化

第一阶段的封装基本上已经可以满足现有的需求，也被自己的项目和其他产品线所使用，但是不经意的一句话，让我开始了第二阶段的优化。有同事告诉我说Memcached客户端的SocketIO代码里面有太多的Synchronized（同步），多多少少会影响性能。虽然过去看过这部分代码，但是当时只是关注里面的Hash算法。根据同事所说的回去一看，果然有不少的同步，可能是作者当时写客户端的时候JDK版本较老的缘故造成的，现在Concurrent包被广泛应用，因此优化并不是一件很难的事情。但是由于原有Whalin没有提供扩展的接口，因此不得不将Whalin除了SockIO，其余全部纳入到封装过的客户端的设想，然后改造SockIO部分。

结果也就有了这个放在Google上的开源客户端：http://code.google.com/p/memcache-client-forjava/。

1. 优化Synchronized：在原有代码中SockIO的资源池被分成三个池（普通Map实现），——Free（闲）、Busy（忙）和Dead（死锁），然后根据SockIO使用情况来维护这三个资源池。优化方式为首先简化资源池，只有一个资源池，设置一个状态池，在变更资源状态的过程时仅仅变更资源池中的内容。然后用ConcurrentMap来替代Map，同时使用putIfAbsent方法来简化Synchronized，具体的代码可参见Google上该软件的源文件。
2. 原以为这次优化后，效率应该会有很大的提高，但是在初次压力测试后发现，并没有明显的提高，看来有其他地方的耗时远远大于连接池资源维护，因此用JProfiler作了性能分析，发现了最大的一个瓶颈：Read数据部分。原有设计中读取数据是按照单字节读取，然后逐步分析，为的仅仅就是遇到协议中的分割符可以识别。但是循环Read单字节和批量分页Read性能相差很大，因此我内置了读入缓存页（可设置大小），然后再按照协议的需求去读取和分析数据，结果显示效率得到了很大的提高。具体的数据参见最后部分的压力测试结果。

上面两部分的工作不论是否提升了性能，但是对于客户端本身来说都是有意义的，当然提升性能给应用带来的吸引力更大。这部分细节内容可以参看代码实现部分，对于调用者来说完全没有任何功能影响，仅仅只是性能。

压力测试比较

在这个压力测试之前，其实已经做过很多次压力测试了，测试中的数据本身并没有衡量Memcached的意义，因为测试是使用我自己的机器，其中性能、带宽、内存和网络IO都不是服务器级别的，这里仅仅是将使用原有的第三方客户端和改造后的客户端作一个比较。场景就是模拟多用户多线程在同一时间发起缓存操作，然后记录下操作的结果。

Client版本在测试中有两个：2.0和2.2。2.0是封装调用Whalin Memcached Client 2.0.1版本的客户端实现。2.2是使用了新SockIO的无第三方依赖的客户端实现。checkAlive指的是在使用连接资源以前是否需要验证连接资源有效（发送一次请求并接受响应），因此启用该设置对于性能来说会有不少的影响，不过建议还是使用这个检查。

单个缓存服务端实例的各种配置和操作下比较：

从上面的压力测试可以看出这么几点，首先优化SockIO提升了不少性能，其次SockIO优化的是get的性能，对于put没有太大的作用。原以为获取数据越大性能效果提升越明显，但结果并不是这样。

单个缓存实例和双缓存实例的测试比较：

结果显示，单个客户端对应多个服务端实例性能提升略高于单客户端对应单服务端实例。

缓存集群的测试比较：

这部分和SocketIO优化无关。2.0采用的是向集群中所有客户端更新成功以后才返回的策略，2.2采用了异步更新，并且是分布式客户端节点获取的方式来分散压力，因此提升效率很多。

开源代码下载

其实封装后的客户端一直在内部使用，现在作了二次优化以后，觉得应该开源出来，一是可以完善自己的客户端代码，二是也可以和更多的开发者交流使用心得。目前我已经在Google Code上传了应用的代码、范例和说明等，有兴趣的朋友可以下载下来测试一下，与现在用的Java Memcached客户端在易用性和性能方面是否有所提高，也期待更多对于这部分开源内容的反馈，能够将它做的更好。

First Stage

       我也和其他使用Memcached Cache的同学一样，看了官方网站的内容，然后去下载了whalin memcached Client，后来Stat的时候遇到问题，就给作者发了邮件说明了情况，作者让我下载 2.0.1 版本，这个版本也是比较不错的一个版本，后续的封装也是基于这个版本之上。

         第一阶段主要是在whalin的客户端作了再次封装。

1.       Cache服务接口化。

定义了IMemCache接口，在应用部分仅仅只是使用接口，为将来替换Cache服务实现提供基础。

2.       使用配置代替代码初始化客户端。

通过配置客户端和SocketIO Pool属性，直接交管由CacheManager来维护Cache Client Pool的生命周期，方便实用以及单元测试。

3.       KeySet的实现。

对于MemCached来说本身是不提供KeySet的方法的，在接口封装初期，同事向我提出这个需求的时候，我个人觉得也是没有必要提供，因为Cache轮询是比较低效的，同时这类场景，往往可以去数据源获取KeySet，而不是从MemCached去获取。但是SIP的一个场景的出现，让我不得不去实现了KeySet。

SIP在作服务访问频率控制的时候需要记录在控制间隔期内的访问次数和流量，此时由于是集群，因此数据必须放在集中式的存储或者缓存中，数据库肯定是撑不住这样大数据量的更新频率的，因此考虑使用Memcached的很出彩的操作，全局计数器（storeCounter,getCounter,inc,dec），但是在检查计数器的时候如何去获取当前所有的计数器，曾考虑使用DB或者文件，但是效率还是问题，同时如果放在一个字段中并发还是有问题。因此不得不实现了KeySet，在使用KeySet的时候有一个参数，类型是Boolean，这个字段的存在是因为，在Memcached中数据的删除并不是直接删除，而是标注一下，这样会导致实现keySet的时候取出可能已经删除的数据，如果对于数据严谨性要求低，速度要求高，那么不需要再去验证key是否真的有效，如果要求key必须正确存在，就需要再多一次的轮询查找。

4.       Cluster的实现。

Memcached作为集中式Cache，就存在着集中式的致命问题：单点问题，Memcached支持多Instance分布在多台机器上，仅仅只是解决了数据全部丢失的问题，但是当其中一台机器出错以后，还是会导致部分数据的丢失，一个篮子掉在地上还是会把部分的鸡蛋打破。

因此就需要实现一个备份机制，能够保证Memcached在部分失效以后，数据还能够依然使用，当然大家很多时候都用Cache不命中就去数据源获取的策略，但是在SIP的场景中，如果部分信息找不到就去数据库查找，那么要把SIP弄垮真的是很容易，因此SIP对于Memcached中的数据认为是可信的，因此做Cluster也是必要的。