Local Cache的小TIP

今天组里的同学和我谈起local cache的一点需求，希望考虑在性能和业务上找到平衡点应该怎么考虑实现。下午给他的意见可能还是有点问题，回家稍微整理了一下，说出来也可以激发大家的讨论，觉得现在local cache + 远端cache是提高性能的必备，所以如何做好local cache 很有讲究。

    由于有网络传输带来的性能损失（包括连接数并发限制），很多大请求量系统都会考虑做部分本地缓存。但本地缓存最大的问题就是数据同步，如果让集中式存储（cache,queue）来通知只会增加复杂度，因此通常最简单的方式就是根据业务数据的敏感度设置不同长短的本地失效时间。但现在如果要设置一个较短的有效期（例如一秒），对于计算机来说已经大大的减轻了压力（1秒对程序来说太久了），但是整体本地缓存对后端保护的效果不佳（特别是后端如果是并发处理能力较弱的系统），如果遇到并发量大的系统，那么就更为突出了。

   早先有想过通过锁来保证请求不会全部放过去（失效时就一个请求过去更新，其他请求等待），一来是针对内容作锁，对锁的需求量很大（当业务数据很多时），二来如果采用其他请求阻塞（对于系统来说压力也很大），这点后来谈起可以直接返回老数据而不等待。但总体看起来消耗依然很大。

   因此给了下图：

  

   

 

      首先开始的时候会有部分数据被推送到本地缓存（当然也可以是客户端主动获取全部数据），也可以全部采用lazy加载，推送来的数据缓存在本地，并且设置失效时间，为每一个key还会有一份失效时间Map用于检查是否失效。应用发起get的请求，先从本地拿，如果有数据且有效，就直接返回。如果没有命中，则去远端获取资源，并缓存在本地，最后返回给应用（这里如果要防攻击可以采用布隆算法建立白名单）。如果发现本地数据失效，则将失效事件放入到一个本地的EventMap中，key为当前请求数据的key，然后设置这个key的时间为当前时间+有效间隔时间（不做并发控制，多次放入EventMap会被覆盖，多次设置时间有效期还是当前时间+间隔时间），后续请求就会认为这个数据是有效的不会连续请求更新，然后返回老数据。后台分发线程检查消息Map，将事件分发到后台线程池异步执行，最后更新结果并设置有效时间。

     最后还有一个后台清理线程将过老的数据从缓存中移除，在map满或者到了清理间隔的时候去执行。

 

     这种设计有一定的复杂度，但是还算是松耦合，在并发高的情况下，牺牲数据较小的即时性换取对后端的保护。不过如果没有必要，做的简单粗暴一点即可，不需要那么复杂。