import { Context, Next } from 'koa';

// 默认的 cache key 计算规则：直接取 query string
const defaultCacheKeyFn =  <T  extends Context>(ctx: T) =>  ctx.querystring;

// 默认的缓存获取策略
const defaultGetCacheFn = async <T  extends Context> (cacheKey: string, ctx: T, next: Next) => {
  // 根据 cache key 获取 cache value
  // getWithCache: 封装本地和 redis 缓存获取
  const cacheVal = await getWithCache(cacheKey);
  // 缓存优先，缓存命中触发异步更新
  if (cacheVal) {
    // 异步执行 next 获取新鲜的 值
    next().then(() => {
      // 通过 ctx.body 获取新值，更新到缓存
      setWithCache(cacheKey, JSON.stringify(ctx.body));
    });
    ctx.body = JSON.parse(cacheVal);
    return;
  }

  // 没有缓存，直接执行
  await next();
  // 新建缓存
  setWithCache(cacheKey, JSON.stringify(ctx.body));
};

// 获取缓存中间件
export const getCacheMiddleware = <T  extends Context>(cacheKeyFn = defaultCacheKeyFn, getCacheFn = defaultGetCacheFn) => async (ctx: T, next: Next) => {
  try {
    // 为这次请求计算一个 cache key
    const cacheKey = cacheKeyFn<T>(ctx);
    // 封装缓存策略
    await getCacheFn<T>(cacheKey, ctx, next);
  } catch (e) {
    console.error('缓存中间件出错', e);
    throw e;
    // 不能降级，有可能 next 已经执行了
    // await next();
  }
};

缓存异步更新如何做的呢？

 

调用了 next，但是没有 await，ctx.body 附上缓存的旧值，直接 return 了。

 

写到这里，当时想了很久：新值的读取，也是从 ctx.body，这是在赌：新值的赋值一定在旧值赋值之后，没问题吗？

 

next 里把 ctx.body 赋为新值，一般在一次 网络IO 后，如果这样，就赌赢了；

如果在 controller 前还有其他中间件，那么也没问题，新值赋值至少在 micro task 里执行，所以也一定在同步任务（旧值赋值）之后。

如果 controller 里直接同步运算了一个值放到 ctx.body 呢？那么新值就在旧值之前被赋到 ctx.body。这种情况，缓存永远无法得到更新。

但是第三种情况，在实际应用中几乎不存在，因为：没有 controller 不依赖外部服务（存储服务、RPC 服务等）就能直接返回。

 

如果真有这样的 controller，就要质疑下它存在的必要性了：

 

如果没有任何依赖，端上就能运算了，为啥还要跑到服务器运算呢？

 

当缓存中间件出错，为什么直接 throw 呢？

 

缓存中间件出错，可能出错在 next 执行后（回忆下缓存更新策略），如果再执行 next，根据 koa 机制，重复执行 next 会导致异常。

 

除非细分了缓存中间件里不同类型的 error，否则不要直接重试 next。

 

下面看看如果封装 getWithCache 和 setWithCache 来屏蔽本地缓存和 redis 缓存。

2. 实现 getWithCache 和 setWithCache

const localCacheExp = 10 * 60; // 10min
// 获取缓存值：先本地，后 redis
export const getWithCache = async (key: string) => {
  // 先计算一个内部 key
  const localCacheKey = `_redis_key_${key}`;
  // 本地缓存如果有，直接返回
  if (defaultLocalCache.exists(localCacheKey)) return defaultLocalCache.get(localCacheKey);

  // 否则，到 redis 里取
  // redis 里不管存在与否，都作为最终结果返回
  const result = await defaultRedisClient.get(key);
  if (result) defaultLocalCache.setex(localCacheKey, localCacheExp, result);

  return result;
};

// 设置缓存值，先 redis，后本地
export const setWithCache = async (key: string, value: string | number) => {
  // 30min 失效
  await defaultRedisClient.setex(key, 30 * 60, value);
  const localCacheKey = `_redis_key_${key}`;
  defaultLocalCache.setex(localCacheKey, localCacheExp, value);
};

下面看看 defaultLocalCache，如何实现类 redis 的接口，并具备缓存失效机制。

3. 实现 defaultLocalCache

// 本地缓存类
export class LocalCache {
    private cache: Record<string, any>
    constructor() {
      this.cache = {};
    }

    // 类似 redis setex
    setex(key: string, seconds: number, value: any) {
      this.cache[key] = value;
      // 缓存定时失效
      setTimeout(() => {
        delete this.cache[key];
      }, seconds * 1000);
    }

    get(key: string) {
      return this.cache[key];
    }

    exists(key: string) {
      return Object.prototype.hasOwnProperty.call(this.cache, key);
    }
}

// 使用单例 plain object
export const defaultLocalCache = new LocalCache();

4. router 中使用

前面三步，已经实现了缓存中间件，最后一步，看看怎么使用。

import Router from 'koa-router';
// 使用默认的 cache key 计算以及缓存策略
const cacheMiddleware = getCacheMiddleware();
export const router = new Router();
// 在特定 API 应用
router.get('/article/detail', cacheMiddleware, detailController);

总结