用好Cache，优化应用.docVIP

　　用好Cache，优化应用 　　 服务集成平台5.6的性能测试进入尾声，这期的优化也算告一段落。这次主要的优化工作还是在三个方面：应用服务器（Apache,JBoss）配置，业务流程，Cache Client包（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和Rep