缓存策略优化

标签：style   blog   http   io   ar   color   os   使用   sp   

作者：zhanhailiang 日期：2014-12-12

需求背景

通常，缓存逻辑是设置一个过期时间，若缓存失效时，就请求后端读取数据并更新缓存。 但是该方案在高qps的场景下会出现问题——在[缓存失效，请求后端读取数并更新缓存)时间段内，所有的请求都会全部透传到后端，该场景对后端将会产生大量请求。所以我们的目标是希望减少这部分请求数。

实现方案

• 基于概率的实现机制

  • 将cache存储两倍的过期时间 2 * expire，
  • 若请求介在[start，start + expire]，则只读缓存即可；
  • 若请求介在(start + expire，start + 2 * expire)，则只透传一定比例(factor=10，表示比例为10%)的请求后端读取数据并更新缓存，其它请求继续使用当前缓存；
  • 若缓存已失效，则直接请求后端读取数据；

• 基于锁的实现机制

  • 将cache存储两倍的过期时间 2 * expire，
  • 若请求介在[start，start + expire]，则只读缓存即可；
  • 若请求介在(start + expire，start + 2 * expire)，则判断当前是否有请求锁；
    • 若有，则说明已经有请求去后端读取数据，本次请求暂时使用缓存即可；
    • 若无，则设置请求锁，并请求后端读取数据并更新缓存，成功后清除掉请求锁；
  • 若缓存已失效，则直接请求后端读取数据；

代码如下：https://github.com/billfeller/blog.csdn.net-billfeller/blob/master/cache.php

方案评估

• 从最终结果来看，基于锁的实现机制能最大限度减少后端请求。以factor=10为例，理论上基于概率的实现机制可 以减少90%的请求数，但是基于锁的实现机制在任何场景下都能保证只有一次后端请求。
• 从实现上看，基于锁的实现机制需要额外的memcached操作，最坏情况下需要3次额外的memcached操作；

缓存策略优化

标签：style   blog   http   io   ar   color   os   使用   sp   

原文地址：http://blog.csdn.net/billfeller/article/details/41898203