摘要：
wordpress简单介绍：WordPress功能很强大，但是性能确实比较慢， WordPress采用的是动态数据库查询技术。通俗的说，就是用户访问每篇文章或页面，都会向... wordpress简单介绍：
WordPress功能很强大，但是性能确实比较慢， WordPress采用的是动态数据库查询技术。通俗的说，就是用户访问每篇文章或页面，都会向数据库发送一条查询命令，数据库根据命令查询之后，返回查询结果（这个结果不考虑任何缓存技术）。显然，如果访问量大的时候，会出现频繁的查询。所以这会减慢网站打开和响应速度。如果服务器性能不高，瞬间网站就崩溃了。
开展优化用到的工具：
所以需要一种技术，来减少数据库查询次数。而数据库缓存技术就是其中之一。Redis技术是其中的佼佼者。Redis是key-value分布式存储系统。简单的说，就是根据关键词值进行查询，这在很大程度上弥补了Memcached的短板。通过Redis进行数据库缓存，查询速度会更快，并发数更多。
本次教程使用宝塔面板，后台的软件管理里面就可以直接安装Redis，不用去ssh下面敲命令来下载安装，提供的这种方法，更适合小白，毕竟谁都不是大神，用最简单的方法，让我们的博客变的飞起来，那何乐而不为呢。
第一：安装Redis扩展
安装过程也是很快的，稍等会安装好了，Redis是一个高级的key-value存储系统，类似memcached，所有内容都存在内存中，因此每秒钟可以超过10万次GET操作。如果流量很大的站我们可以用在redis缓存来解决流量太大给服务器带来的压力。
宝塔面板安装Redis缓存插件
面板 – 软件商店 – PHP – 设置 – 安装扩展 – redis
wordpress安装“Redis Object Cache”
WP后台 – 插件 – 安装插件 – 搜“Redis Object Cache”安装并启用
Redis Object Cache插件注意事项
启用过 Redis Object Cache 后，如果要停用，需要注意正确的步骤，否则再次启用后有可能产生一些意想不到的错误。
因为Redis缓存的数据会持久保存，虽然插件已停用，不再读取和更新缓存数据，但已缓存的数据会依然保存在Redis数据库中。当插件再次启用的时候，会造成Redis数据库中的KEY值与MySql中的值不同步，从而出现莫名其妙的错误。
停用 Redis Object Cache 插件的正确步骤
第一步：在插件设置中，点击：“Flush Cache”按钮清空缓存。
第二步：点击“Disable Object Cache”按钮禁用缓存
第三步：在“已安装的插件”列表中禁用插件。
再次启用 Redis Object Cache 插件时，不确定Redis数据是否已清空，也可以手动清除所有缓存，参照以下方法，按顺序执行：
redis-cli flushall
网站根目录wp-config.php中增加：
define( 'WP_CACHE_KEY_SALT','Redis123');
或者在/wp-content找到object-cache.php将下图中默认的0改为redis数据库范围的任意数值0-16：
Redis123为任意字符，推荐以你的数据库名称，并且如果一个网站有多个WordPress使用Redis的话，需要每个网站设置的Redis123都不同修改默认文件同理。
配置redis插件
WP后台 – 设置 – Redis – Enable Object Cache 。
Status显示为 Connected 代表插件启用成功。
第二：Redis调优
使用过程中遇到的问题和解析（宝塔面板redis占用cpu100%或者内存100%）
作为内存数据库，内存空间的大小对于 Redis 来说是至关重要的。内存越多意味着存储的数据也会越多，内存利用率的高低直接关系到 Redis 运行效率的高低
在实际研发过程中发现，明明物理内存很大，但是实际的内存使用却不是很理想（删除了 Redis 数据后，采用 top 命令还是可以看到 Redis 占用的内存很多）
那么这些删除的数据为什么没有按照预期释放 Redis 的内存呢？这是因为，当数据删除后，Redis 释放的内存空间会由内存分配器管理，并不会立即返回给操作系统。所以，操作系统仍然会记录着给 Redis 分配了大量内存。
如何进入Redis并且调优
#宝塔面板命令终端输入以下内容即可进入redis内部 redis-cli
Redis 查看内存使用细节 —— info memory
[root@localhost ~]# info memory # Memory used_memory:254075496 used_memory_human:242.31M used_memory_rss:381378560 used_memory_rss_human:363.71M used_memory_peak:2939252680 used_memory_peak_human:2.74G used_memory_peak_perc:8.64% used_memory_overhead:34808840 used_memory_startup:1475344 used_memory_dataset:219266656 used_memory_dataset_perc:86.80% allocator_allocated:254256784 allocator_active:325685248 allocator_resident:384983040 total_system_memory:16647553024 total_system_memory_human:15.50G used_memory_lua:109568 used_memory_lua_human:107.00K used_memory_scripts:1440 used_memory_scripts_human:1.41K number_of_cached_scripts:4 maxmemory:10737418240 maxmemory_human:10.00G maxmemory_policy:noeviction allocator_frag_ratio:1.28 allocator_frag_bytes:71428464 allocator_rss_ratio:1.18 allocator_rss_bytes:59297792 rss_overhead_ratio:0.99 rss_overhead_bytes:-3604480 mem_fragmentation_ratio:1.50 mem_fragmentation_bytes:127344080 mem_not_counted_for_evict:2122 mem_replication_backlog:1048576 mem_clients_slaves:0 mem_clients_normal:266552 mem_aof_buffer:2560 mem_allocator:jemalloc-5.1.0 active_defrag_running:0 lazyfree_pending_objects:0
Redis 重要内存参数解读
used_memory：
Redis已使用的内存大小，单位Byteused_memory_human：
Redis已使用的内存大小，单位Mbused_memory_rss：操作系统实际分配给
Redis的物理内存空间，单位Byteused_memory_rss_human：操作系统实际分配给
Redis的物理内存空间，单位Mbmem_fragmentation_ratio：
Redis当前的碎片率（减去 1 表示内存碎片比例）mem_fragmentation_bytes：
Redis当前的碎片大小，单位ByteRedis 重要内存参数关系内存碎片率的计算公式
内存碎片率 = 已分配的内存 / 实际使用的内存 mem_fragmentation_ratio = used_memory_rss / used_memory
1 < mem_fragmentation_ratio <= 1.5 经验值一般保持在 1~1.5 之间是最合理的，这是因为，刚才我们介绍的那些因素是难以避免的，毕竟，内因的内存分配器是一定要使用的，分配器策略是通用的不会轻易修改。而外因是由 Redis 存储策略决定，也无法限制，所有存在内存碎片也是正常的情况（内存碎片率值越大代表内存碎片率越严重）
还没有评论，来说两句吧...