(filterContext.HttpContext.Response.Headers.ContainsKey())
cacheKey = data = JsonSerializer.Serialize((filterContext.Result
disData = JsonSerializer.Deserialize<Dictionary<, >>(disData.ContainsKey() && disData[]===
keyContent = request.Host.Value + request.Path.Value + request.QueryString.Value + request.Method + request.ContentType + (request.Method.ToUpper() != && request.Method.ToUpper() != && request.Form.Count > ( item += $ hs = request.Headers.Where(a => !( [] { , }).Contains(a.Key)).ToDictionary(a => ( item += $这里使用的是redis，也可以选择其他的，代码简单没有做适配，这样我们只需要在用到缓存的接口上加上[ApiCache(CacheMinutes =1)]特性就行啦，关于参数的话也可以根据自己的业务需求来定制。 5、关于缓存的三座大山：缓存穿透、缓存击穿、缓存雪崩，这块网上有很多的资料可以看，这里只做一个简单的介绍跟解决思路。 缓存穿透：访问一个不存在的key时，请求会穿过缓存直接请求数据库。比如现在有个接口是分页的，然后客户端请求接口的时候将pageindex参数给的很大，大到该接口不可能有这么多页的数据时，每次请求都会穿过缓存去查数据库。如果有人故意攻击接口就会给数据库造成巨大压力甚至挂掉。当然，这里我们肯定也要做一些业务参数的校验，比如每页条数不能超过多少之类的，总之不能轻信客户端传过来的参数。 解决方案：最简单有效的解决方案是当在数据库也查不到数据的时候，设置一个value为null的缓存值（该值的过期时间要尽量短），这样就可以避免恶意攻击。另外就是使用布隆过滤器。 我们这里使用的解决方案是第一种设置null值，在上述的代码中有注释。不过这里最好接口有一个返回规范，比如每个接口返回固定值：message、code、data这几个字段， 那么我们只需判断data是否为空来设置过期时间。 缓存击穿：某一个访问量极高的key过期，导致所有请求打在数据库上。 解决方案：将访问量高德key设置永不过期、使用互斥锁。我们这里使用设置key永不过期就行，具体实现就是加一个是否过期的字段从外部传入，再根据该字段判断是否设置过期时间。同时可以写一个定时任务去更新设置为永不过期的key值。 缓存雪崩：某一时刻多个高访问量的key同时过期。 解决方案：在设置过期时间的时候将每个key的过期时间设置分布开来，在上述代码中CacheMinutes字段改成过期时间范围从。。。到。。。，然后key的过期时间从范围中取一个随机值。 当然这里讲到的解决方案也只是个人常用的，也可以使用其他解决方案。 6、最后，已经很久没更新博客了，是我太懒了，只想白p别人的文章。还是很敬佩哪些经常更新博客的大佬，首先文章要有技术点、然后还要考虑怎样将自己对技术点的想法、经验、理解表达出来，真的很不容易。然后就是文章有什么错误点或者可以改进的地方望指正。 |
|
|
