多级缓存架构当中每一层的意义
ngx_lua 属于 nginx 的一部分，它的执行指令都包含在 nginx 的 11 个步骤之中了，相应的处理阶段可以做插入式处理，即可插拔式架构，不过 ngx_lua 并不是所有阶段都会运行的；另外指令可以在 http 、 server 、 server if 、 location 、 location if 几个范围进行配置：
1、nginx本地缓存
nginx 本地缓存，抗的是热数据的高并发访问，根据场景设置缓存时间商品的购买总是有热点的，比如每天购买 iphone 、 nike 、海尔等知名品牌的东西的人，总是比较多的这些热数据，利用nginx 本地缓存，由于经常被访问，所以可以被锁定在 nginx 的本地缓存内大量的热数据的访问，就是经常会访问的那些数据，就会被保留在nginx本地缓存内，那么对这些热数据的大量访问，就直接走 nginx 就可以了，不需要走后续的各种网络开销了
2、redis分布式缓存
如果 nginx 本地缓存不命中，则 nginx 会访问 redis 集群服务， redis 集群服务，抗的是很高的离散访问，因为 redis 的性能问题，能够支撑海量的数据，高并发的访问，提供高可用的服务nginx本地内存有限，也就能 cache 住部分热数据，除了热点数据，其他相对不那么热的数据，可能流量会经常走到 redis 那里 利用 redis cluster 的多 master 写入，横向扩容，1T+ 以上海量数据支持，几十万的读写并发， 99.99% 高可用性，那么就可以抗住大量的离散访问请求
3、多级缓存架构设计需要解决的问题
这里列了一些，也就是结合我们所学的知识带大家解决生产环境当中要解决的问题
1 、数据库 + 缓存双写一致性解决方案
面临难题：高并发场景下，如何解决数据库与缓存双写的时候数据不一致的情况？
2 、缓存维度化拆分解决方案
面临难题：如何解决大 value 缓存的全量更新效率低下问题？
3 、缓存命中率提升解决方案
面临难题：如何将缓存命中率
4 、缓存并发重建冲突解决方案
面临难题：如何解决高并发场景下，缓存重建时的分布式并发重建的冲突问题？
5 、缓存预热解决方案
面临难题：如何解决高并发场景下，缓存冷启动导致 MySQL 负载过高，甚至瞬间被打死的问题？
6 、缓存雪崩解决方案
面临难题：如何解决恐怖的缓存雪崩问题？避免给公司带来巨大的经济损失？
7 、缓存穿透解决方案
面临难题：如何解决高并发场景下的缓存穿透问题？避免给 MySQL 带来过大的压力？
8 、缓存失效解决方案
面临难题：如何解决高并发场景下的缓存失效问题？避免给 redis 集群带来过大的压力？
集群划分
redis 集群
容器名称 | 容器IP地址 | 映射端口号 | 服务器运行模式 |
redis-matser1 | 172.18.0.2 | 6380->6379 16380->16379 | Master |
redis-matser2 | 172.18.0.3 | 6381->6379 16381->16379 | Master |
redis-matser3 | 172.18.0.4 | 6382->6379 16382->16379 | Master |
redis-slave1 | 172.18.0.5 | 6383->6379 16383->16379 | Slave |
redis-slave2 | 172.18.0.6 | 6384->6379 16384->16379 | Slave |
redis-slave3 | 172.18.0.7 | 6385->6379 16385->16379 | Slave |
Ngnix集群
容器名称 | 容器IP地址 | 映射端口号 | 服务器运行模式 |
Nginx | 172.18.0.8 | 8001->80 | Nginx分发层 |
Nginx-lua1 | 172.18.0.9 | 8002->80 | Nginx分发层 |
Nginx-lua2 | 172.18.0.10 | 8003->80 | Nginx分发层 |
PHP与mysql
容器名称 | 容器IP地址 | 映射端口号 | 服务器运行模式 |
php-fpm | 172.18.0.11 | 9002->9000 | php应用层 |
mysql | 172.18.0.12 | 3307->3306 | mysql应用层 |
具体操作步骤如下
1、目录结构
2、构建镜像
#构建nginx镜像
cd /docker/cache/docker/nginx
docker build -t nginx . --no-cache(如果以前有构建过则加上--no-cache)
#构建php镜像
cd /docker/cache/docker/php
docker build -t php-fpm . --no-cache
#构建redis镜像
cd /docker/cache/docker/redis
docker build -t redis . --no-cache
3、利用docker-compose构建容器，最终结果如下图
4、配置文件以及lua脚本编写
搭建过程中遇到的问题以及解决方法：
[error] 1507#0: *22 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.0.0.1, server: www.wordpress.com, request: "GET /info.p
问题：nginx能解析静态文件但是不能解析php动态文件，返回404文件未发现错误
原始nginx配置：（这里只给出抛给php程序的配置）
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}解决方案：
location ~ \.php/?.* {
root /var/www/html;#php-fpm容器中的路径，不是nginx路径
fastcgi_pass 127.0.0.1:9002;#对应容器的端口，此处ip地址应写外网访问地址
fastcgi_index index.php;
#为php-fpm指定的根目录
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; #加了这一项
#定义变量$path_info,存放pathinfo信息
set $path_info "";
if ($fastcgi_script_name ~ "^(.+?\.php)(/.+)$") {
#将文件地址赋值给变量 $real_script_name
set $real_script_name $1;
#将文件地址后的参数赋值给变量 $path_info
set $path_info $2;
}
#配置fastcgi的一些参数
fastcgi_param SCRIPT_NAME $real_script_name;
fastcgi_param PATH_INFO $path_info;
#fastcgi_params所在目录
include /usr/local/openresty/nginx/conf/fastcgi_params;
}
原因：
在fastcgi_params文件（和nginx.conf文件在同一个目录下）里定义了许多与fastcgi程序相关的变量，当nginx通过fastcgi接口发送请求时它要去定义好的地方去解析相应的变量值，然后交给php去处理，很显然，如果fastcgi获取不了相应的值，那么他就无法把相应请求转发给php程序，自然无法解析。
这个问题的关键在于"Primary script unknown”主脚本未知，也就是fastcgi程序无法找到定义的要执行的脚本，默认的配置文件fastcgi_params定义的变量中并没有$fastcgi_script_name这个变量，但是在fastcgi.conf里定义了。所以我们要么包含这个fastcgi.conf文件，要么把fastcgi_params里的SCRIPT_FILENAME 构建成和fastcgi.conf里的值一样，加上$document_root参数(这个参数的值就代表站点目录root那一行的值)。
最终浏览器访问结果如下：
