nginx实现全站缓存

一、背景

网站在高峰期时段会出现访问失败等情况，数据库负载过大，后端程序处理完成时间远大于60s。而数据库实例目前无扩容规划。针对该情况只能考虑使用缓存来降低数据库负载。

二、架构设计

计划使用nginx进行内容缓存，但面临两个问题1；如何区别不同用户，通过token或者cookie区分还是其他方式？2；TTL缓存时间，含失效。最终设计仅对普通游客进行页面缓存(带有cookie的请求报文直接转发至后端)，同时缓存时间仅设置1分钟。

三、Nginx配置

        if (http_cookie ~* "AK"){
            setcachehost "off";
        }
        if (http_cookie !~* "AK"){
            setcachehost "cache_one";
        }
        proxy_cache cachehost;
        proxy_set_header nginxLanguage '0';
        add_header locallanguage '0';
        proxy_set_header    Hosthost;
        proxy_set_header    X-Real-IP                   remote_addr;
        proxy_set_header    X-Forwarded-Forproxy_add_x_forwarded_for;
        proxy_set_header    HTTP_X_FORWARDED_FOR        $remote_addr;
        proxy_pass http://web;
        }

#备注：nginx部分配置

四、问题

• 缓存实际上是用来提升网站性能而非用来解决故障的，只是该站点项目因容量规划不足而使用缓存来解决实际问题。会员用户没有缓存功能。-

• 扩展性差，可能还有某些问题只是目前我没有发现而已

五、可替代方案探讨

缓存策略上线后也发现了一系列问题，例如这种缓存实际没有什么扩展性且无法应对各种复杂的需求，仅缓存1分钟时间也足以说明此方案的局限性。由此引发了自己对于动态内容分发的研究。大致思路为在微服务Gateway网关层做一层动态内容缓存。这里要解决的点有1；缓存我想缓存的内容2；内容失效的设置3；能否通过token或者cookie区别同一个url的缓存

5.1常规微服务架构

5.2新增缓存模块

5.3通过cloudfront配置内容分发

cloudfront的缓存机制可以对字符串和cookie分别进行缓存，所以在缓存策略和请求策略设置中分别启用字符串和cookie的全部缓存功能

5.4cloudfront配置行为

通过配置行为项仅缓存想的内容

5.5缓存失效设置

这个需要基于api调用对缓存进行失效配置，对此我没有做过多的研究。

六、写在最后

写了两种缓存思路，第一总扩展性不强，但是缓存的内容不会很多，可以解决部分问题，对于网站性能的提升帮助不会太大(仅对游客进行了缓存，网站的会员用户没法进行缓存)。第二种缓存思路扩展性更强，定制化更强，感觉把扩容数据库的钱用在cdn内容分发上应该还算合算。两种缓存思路到底行不行需要交给时间去验证。