wp请求响应过程
wordpress响应请求大致分为如下几个过程：
Nginx接收请求 -> php-fpm进程运行指定php脚本 -> php在mysql内查询相应数据 -> 处理返回给Nginx -> Nginx响应用户请求
因为不存在缓存的过程，所以每次处理请求都要重新查询数据库，所以wp有很多流行的静态缓存方案；
wp缓存方式
1.文件缓存
初次请求 -> Nginx接收请求 -> php-fpm进程运行指定php脚本 -> php在mysql内查询相应数据 -> 缓存本次请求产生的页面数据到文件A -> 处理返回给Nginx -> Nginx响应用户请求
缓存之后的请求过程如下：
缓存之后的所有请求 -> Nginx接收请求 -> php-fpm进程运行指定php脚本 -> 判断是否存在缓存文件 -> 输出缓存文件的内容给Nginx -> Nginx响应本次请求
相较于没有缓存的情况，大大的减少了Mysql的查询次数，所有文件缓存是比较流行的一种方式，但是这种方式在数据量很大的时候，能起到的作用还是比较有限的。
2.内存持久化缓存
初次请求 -> Nginx接收请求 -> php-fpm进程运行指定php脚本 -> php在mysql内查询相应数据 -> 缓存本次请求产生的页面数据到Redis -> 处理返回给Nginx -> Nginx响应用户请求
内存持久化缓存最常见的是将页面缓存到Redis，缓存之后的每次请求直接从Redis获取数据；因为每次查询都是操作内存，所以速度非常快，响应过程大致如下：
缓存之后的所有请求 -> Nginx接收请求 -> php-fpm进程运行指定php脚本 -> 判断Redis是否存在缓存 -> 输出缓存文件的内容给Nginx -> Nginx响应本次请求
缺点就是数据量大的时候，占用的内存比较多，所以这种方式相较于文件缓存，使用的比较少。
Nginx 文件缓存
Nginx响应静态文件请求出了名的快，所以我们可以将响应请求的方式调整成如下过程：
缓存之后的所有请求 -> Nginx接收请求 -> Nginx判断当前请求是否有缓存文件 -> 直接响应本次请求的缓存文件
页面生成缓存之后，响应请求不再经过PHP和Mysql等以外的程序，直接通过Nginx完成所有事情。实现方式如下：
1.针对初次请求生成缓存文件
本次只是简要的说明可行性方案，有示例代码，无插件；编辑根目录的index.php，在define( 'WP_USE_THEMES', true );后加入如下代码：
代码语言：javascript复制/* 如果访问的不是后台 */
if(strpos($_SERVER['REQUEST_URI'],"wp-admin") === false){
ob_start( function ( $html ) {
/* 判断文章密码 */
if(is_single()){
$post = get_post();
if ( !empty( $post->post_password ) ) {
return $html;
}
}
/* 小程序 */
$location = $_SERVER['REQUEST_URI']; //路径
/* 去除参数 */
$match = preg_replace( '/(?.*)/', "", $location );
$query = $_SERVER['QUERY_STRING']; //查询的参数
/*
* 纯目录和html文件
* */
if ( ( strpos( $match, '.' ) === false ) || ( strpos( $match, '.html' ) !== false ) ) {
$dir = WP_ROOT_PATH . "/cache" . $match . '_' . $query;
$file = WP_ROOT_PATH . "/cache" . $match . '_' . $query . '/index.html';
if ( ! file_exists( $dir ) ) {
mkdir( $dir, 0777, true );
}
if ( ! file_exists( $file ) && ! empty( $html ) ) {
file_put_contents( $file, $html, LOCK_EX );
}
}
return $html;
});
}2.修改Nginx伪静态匹配规则
代码语言：javascript复制location / {
if ($request_method ~ ^(POST)$){
rewrite / /index.php?$args last;
}
try_files $uri $uri/ /cache/$uri /cache/${uri}_${args}/index.html /index.php?$args;
}修改之后的匹配规则变为，首先判断请求的文件在不在，然后判断cached目录下面又没有这个文件，然后判断有没有这个目录（目录内有没有index文件），最后将请求重定向到wordpress入口文件index.php。
如果缓存文件存在，将会在cached目录内匹配到请求的目录，然后直接响应用户请求。
3.最后总结
还有很多细节需要完善，比如如何处理缓存更新，比如有些主题移动端、PC端页面代码不一致时如何处理等等。
但是总得来说，通过这种方式加速后，访问速度能快一个量级。
