在大型互联网的网络应用中，很多都会使用到Memcached或者类型似的Cache服务，用来提高网络响应的速度以及减少对数据库的访问，因为数据库是直接对硬盘进行操作，相对Memcached的直接内存操作，那肯定是要慢很多的了，因而适当的使用Memcached，提高系统的响应能力及吞吐量，这个效果还是明显的，特别是高并发的情况下效果更明显。
任何东西都有个适当原则，并不是任何东西都放到Memcached中，再从Memcached中读出来，就一定可以保证系统的性能，相反的，使用不当，Memcached反而会成为一个性能瓶颈，当然还不是Memcached本身的问题，而是根据使用场景的不同需要调整相应的策略，更加充份发挥其功效，并且不让它产生负担而成为性能瓶颈，毕竟Memcached是作为中央集群服务，和应用本身是不会在一台机子上，即使是通过内网访问，也是在存在着IO开销的，如果并发越大，这种IO开销尤为明显，毕竟Memcached也只是一个服务，任何服务对于高并发的访问，反应都会变慢的
我所在的小组，负责中文站的应用及菜单，这些应用以及菜单的数据量本身并不大，全量应用的数据及菜单数据读入到内存也分别只有几十K，并且这些数据都不是经常变化的，因而为了提高响应速度，就将这些数据以全量的开式放到了Memcached中，后面的验权工作就直接根据这些全量数据进行验权，再把符合用户权限范围的菜单显示给用户，这种逻辑本来是没有什么问题的，日常的访问也比较正常，并发一直维持在一个可接受的范围之内，CPU的load也是在一个合理的范围之内。
可是这种状况在昨天一下就被打破了，早上8点到10点的这段时间之内，4核服务器的LOAD曾一度是彪到10几了，并且响应非常慢，这个就让整个小组的人整个提高了注意力，经过排查，是有一个URL访问并发在这段时间之内很高，这个URL是被旺旺客户端调用的，旺旺客户端在升级完成后，新版的旺旺会调用这个URL展示给用户符合用户权限的应用，难怪一下LOAD就突然的上来了。可是后面分析，旺旺那边的升级的用户本次约20%，并且在那两个小时的请求数也才几万，LOAD这么高，肯定是程序中有什么处理不正确的问题，Memcached负责人提供给我们那两小时的cache调用情况，并发最高时的TPS达到了3000多，流量是16M/S，超过中文站最高的应用的cache使用量的好几倍，虽然响应没有堵上，但是Memcached的响应时间肯定是慢了不少，这些时候Memcached就成了我们应用的性能瓶颈了。
经过和大家的商量，再考虑到我们应用的特殊性，数据都不是经常变化的，那就在我们的应用本身中增加一份cache，让应用在读Memcached数据之前，先检查本地内存中是否有数据，如果有数据，那再看一下当前是否是到了需要和Memcached的数据进行同步了，这个同步是通过时间控制的，如果到了同步时间，那就先让本地内存与Memcached进行一次同步，再把结果返回给应用，可以用一个简单的图区分一下原来的cache读取方式和现在的cache读取方式：
这样处理起来看似麻烦一点，看效果还是很显著的，我们设置了10秒钟的同步时间，也就是原来每秒钟都要访问数十次或者更多的，到现在只需要10秒钟去访问一次，这样一处理后，由空闲时间的每秒3M/S多从Memcached获取数据，到后来只有300K/S左右，也就是说性能一下提交了10倍，达到了这样的效果，大家都非常高兴，我们现在对下周一高峰并发有了信心，可以回家去睡个安稳觉了。
--------------------------------------------我是分割线--------------------------------------------
不久前公司培训讲到某项目查询服务器的性能优化，最重大的变化就是大量地使用了Memcached缓存，期间讨论到风险和不足，再次想起这篇文章，以前也和几个同事分享过，记录一下。
还有一点需要补充的就是分布式缓存的过期策略问题。一个相对严谨可靠的缓存策略可能需要你考虑很多复杂应用场景，曾经碰到过有人在库存和商品相关项目开发中使用分布式缓存而造成前端显示和实际数据有巨大出入的惨剧。我认为正确使用缓存的一个重要原则即你必须知道哪些数据适合缓存，而哪些数据千万不能缓存。
本文转自JeffWong博客园博客，原文链接：http://www.cnblogs.com/jeffwongishandsome/archive/2012/06/20/2557101.html，如需转载请自行联系原作者
