Question

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

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

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

[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中。

这里是缓存项目的样本包装。在所有情况下，都假定呼叫者基于所请求的项目密钥知道类型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））

检索时，将通过互补的uncompress和反序列化方法重新创建项目。

Web API缓存-如何使用分布式缓存来实现失效

1 个答案: