asp.net - Web API缓存-如何使用分布式缓存实现无效

Question

我有一个目前不使用任何缓存的API。我确实有一个正在使用的中间件，可以生成高速缓存头(Cache-Control，Expires，ETag，Last-Modified-使用https://github.com/KevinDockx/HttpCacheHeaders库)。它不存储任何内容，因为它仅生成 header 。

当If-None-Match header 传递到API请求时，中间件检查传入的Etag值与当前生成的值之间的关系，如果匹配，则发送未修改的304作为响应(httpContext.Response.StatusCode = StatusCodes.Status304NotModified;)

我正在使用Redis缓存，但不确定如何实现缓存失效。我在项目中使用了Microsoft.Extensions.Caching.Redis包。我在本地安装Redis，并在 Controller 中使用它，如下所示:

[AllowAnonymous]
[ProducesResponseType(200)]
[Produces("application/json", "application/xml")]
public async Task<IActionResult> GetEvents([FromQuery] ParameterModel model)
        {
            var cachedEvents = await _cache.GetStringAsync("events");
            IEnumerable<Event> events = null;

            if (!string.IsNullOrEmpty(cachedEvents))
            {
                events = JsonConvert.DeserializeObject<IEnumerable<Event>>(cachedEvents);
            }
            else
            {
                events = await _eventRepository.GetEventsAsync(model);
                string item = JsonConvert.SerializeObject(events, new JsonSerializerSettings()
                {
                    ReferenceLoopHandling = ReferenceLoopHandling.Ignore
                });
                await _cache.SetStringAsync("events", item);
            }

            var eventsToReturn = _mapper.Map<IEnumerable<EventViewDto>>(events);
            return Ok(eventsToReturn);
        }

请注意，此处的_cache使用的是IDistributedCache。这是请求第二次访问缓存时的工作。但是，当修改我要获取的Events时，不会考虑修改后的值。它无需进行任何验证即可提供相同的值。

我的中间件设置为:
缓存头中间件-> MVC。因此，缓存头管道首先将比较客户端发送的Etag值，然后决定将请求转发到MVC或使用304未经修改的响应将其短路。

我的计划是在缓存头中间添加一个中间件(即，我的中间件->缓存头中间件-> MVC)，然后等待来自缓存头中间件的响应，并检查响应是否为304。如果304 ，转到缓存并检索响应。否则，更新缓存中的响应。

这是进行缓存失效的理想方法吗？有更好的方法吗？使用上述方法，我将必须检查每个304响应，确定路由，并具有某种逻辑来验证要使用的缓存键。不知道这是否是最好的方法。

如果您可以提供一些有关缓存失效的指南和文档/教程，那将非常有帮助。

Answer 1

这是基于我支持的服务如何在CQRS系统上使用缓存失效的指南。

命令系统从客户端接收创建，更新，删除请求。该请求将应用于Origin。该请求将广播到侦听器。

存在一个单独的失效服务，并订阅更改列表。收到命令事件后，将检查事件中该项的配置的分布式缓存。根据特定系统采取了几种不同的措施。

第一个选项是Invalidation服务从分布式缓存中删除项目。随后，共享分布式缓存的服务的使用者最终将遇到缓存未命中，从存储中检索项目并将项目的最新版本添加到分布式缓存的情况。在这种情况下，服务中所有谨慎的机器之间都存在争用情况，并且Origin可能会在一个短窗口中收到对同一物品的多个请求。如果物品价格昂贵，这可能会使原产地紧张。但是Invalidation场景非常简单。

第二个选项是Invalidation服务使用相同的分布式缓存向其中一个服务发出请求，并要求该服务忽略缓存并从Origin获取该项目的最新版本。这解决了多个称为Origin的谨慎机器的潜在峰值。但这意味着Invalidation服务与其他相关服务之间的联系更加紧密。现在，该服务具有一个API，该API允许调用者绕过其缓存策略。仅需要对Invalidation服务和其他授权调用者进行对未缓存API的访问的保护。

在任何一种情况下，所有使用相同redis数据库的谨慎机器也都订阅命令更改列表。任何一台单独的计算机都只是通过从其本地缓存中删除项目来在本地处理更改。如果该项目不存在，则没有错误。在下一个请求时，将从redis或Origin刷新该项目。对于热物料，这意味着仍然可以从任何已删除热物料且redis尚未更新的计算机上收到对Origin的多个请求。对于谨慎的计算机来说，本地的“缓存”和“正在检索的项目”任务可能是有益的，因为所有后续请求都可以等待而不是调用Origin。

除了谨慎的机器和共享的Redis外，Invalidation逻辑还扩展到Akamai和类似的内容分发网络。一旦Redis缓存已失效，则Invalidation例程将使用CDN API刷新项目。 Akamai的行为举止相当好，如果配置正确，则对更新项的Origin调用会相对较少。理想情况下，该服务已检索到该项目，并且副本在分立机器本地缓存和共享Redis中都存在。如果无法正确预期和设计，则CDN无效可能是请求峰值的另一个来源。

在redis中，从谨慎的机器共享它，使用redis指示某项正在刷新的设计还可以保护源免受同一项目的多次请求。一个简单的计数器，其密钥基于物料ID和四舍五入到最接近的分钟，30秒等的当前时间间隔，可以使用redis INCR命令，获得计数1的计算机访问Origin，而其他所有机器都在等待。

最后，对于热门商品，将“刷新时间”值附加到该商品会很有帮助。如果所有有效负载均具有类似于以下内容的包装器，则当检索到某个项目且其刷新时间已过时，被调用程序将对该项目执行后台刷新。对于热门商品，这意味着它们将在过期之前从缓存中刷新。对于读取量大，写入量少的系统，将项目缓存一小时，而刷新时间少于一小时，这意味着热门项目通常会停留在Redis中。

这是缓存项目的样本包装。在所有情况下，都假定 call 者基于所请求的项目密钥知道类型T。假定写入redis的实际有效负载是已序列化的字节数组，并且可能是gzip-ed。 SchemaVersion提供了有关如何创建redis字符串的提示。

interface CacheItem<T> {
  String Key {get; }
  DateTimeOffset ExpirationTime {get; }
  DateTimeOffset TimeToRefresh {get; }
  Int SchemaVersion {get;}
  T Item {get; }
}

存放时
var redisString = Gzip.Compress(NetDataContractSerializer.Serialize(cacheItem))

检索时，将通过补充的解压缩和反序列化方法重新创建该项目。