First Stage
第一阶段主要是在官方推荐的Java客户端之一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也是必要的。
（1） 应用传入需要操作的key，通过CacheManager获取配置在Cluster中的客户端。
（2） 当获得Cache Client以后，执行Cache操作。
（3） A.如果是读取操作，当不能命中时去集群其他Cache客户端获取数据，如果获取到数据，尝试写入到本次获得的Cache客户端，并返回结果。（达到数据恢复的作用）
B.如果是更新操作，在本次获取得Cache客户端执行更新操作以后，立即返回，将更新集群其他机器命令提交给客户端的异步更新线程对列去异步执行。（由于如果是根据key来获取Cache，那么异步执行不会影响到此主键的查询操作）
存在的问题：如果是设置了Timeout的数据，那么在丢失以后被复制的过程中就会变成永久有效的内容。
5. LocalCache结合Memcached使用，提高数据获取效率。
在第一次压力测试过程中，发现和原先预料的一样，Memcached并不是完全无损失的，Memcached是通过Socket数据交互来进行通 信的，因此机器的带宽，网络IO，Socket连接数都是制约Memcached发挥其作用的障碍。Memcache的一个突出优点就是Timeout的 设置，也就是放入进去的数据可以设置有效期，自动会失效，这样对于一些不敏感的数据就可以在一定的容忍时间内不去更新，提高效率。根据这个思想，其实在集 群中的每一个Memcached客户端也可以使用本地的Cache，来缓存获取过的数据，设置一定的失效时间，来减少对于Memcached的访问次数， 提高整体性能。
因此，在每一个客户端中内置了一个有超时机制的本地缓存（采用lazy timeout机制），在获取数据的时候，首先在本地查询数据是否存在，如果不存在则再向Memcache发起请求，获得数据以后，将其缓存在本地，并设置有效时间。方法定义如下：
Java代码
- /**
- * 降低memcache的交互频繁造成的性能损失，因此采用本地cache结合memcache的方式
- * @param key
- * @param 本地缓存失效时间单位秒
- * @return
- */
- public Object get(String key,int localTTL);
Second Stage
第一阶段的封装基本上已经可以满足现有的需求，也被自己的项目和其他产品线使用，但是不经意的一句话，让我开始了第二阶段的优化。单位里面有个同学说 Memcache客户端里面在SocketIO代码里面有太多的synchronized，多多少少会影响性能。虽然过去看过这部分代码，但是当时只是关 注里面的Hash算法，那天回去后一看，果然有不少的synchronized，可能是与客户端当时写的时候Jdk版本较早的缘故造成的，现在 Concurrent包被广泛应用，因此优化并不是一件很难的事情。但是由于原有whalin没有提供扩展的接口，因此不得不将whalin除了 SockIO部分全部纳入到封装过的客户端中，然后改造SockIO部分。
因此也有了这个放在Google上的
open source: http://code.google.com/p/memcache-client-forjava/
一． 优化synchronized部分。在原有代码中SockIO的资源池分成三个池（普通Map实现），Free，Busy，Dead，然后根据SockIO使用情况来维护这三个资源池。
优化方式，首先简化资源池，只有一个资源池，设置一个状态池，在变更资源状态的过程时仅仅变更资源池中的内容。再次，用 ConcurrentMap来替代Map，同时使用putIfAbsent方法来简化Synchronized，具体的代码可以看open source的代码部分。
二． 原以为这优化后，效率应该会有很大的提高，但是在初次压力测试后发现，并没有明显的提高，看来有其他地方的耗时远远大于连接池资源维护，因此用 JProfiler作了性能分析，发现了最大的一个瓶颈：read数据部分，原有设计中读取数据是按照单字节读取，然后逐步分析，为的仅仅就是遇到协议中 的分割符可以识别，但是循环read单字节和批量分页read性能相差很大，因此内置了读入缓存页（可设置大小），然后再按照协议的需求去读取和分析数 据，效率得到了很大的提高。具体的看最后部分的压力测试结果。
上面两部分的工作不论是否提升了性能，但是对于客户端本身来说都是有意义的，当然提升性能给应用带来的吸引力更大。这部分细节内容可以参看代码实现部分，对于调用者来说完全没有任何功能影响，仅仅只是性能。