一、Redis 到底在你的站点里缓存了什么
很多人对 Redis 的印象是「一个快的数据库」，但它在 WordPress 和 Laravel 里的真实作用要具体得多。 说清楚它缓存的是什么，才能判断你的站需不需要它。
在 WordPress 生态里，Redis 承担两个角色。
第一个角色是对象缓存（Object Cache）。 WordPress 的对象缓存是它所有「缓存类」功能的地基：文章数据、用户数据、菜单、术语（category 和 tag）、站点选项（wp_options 里的各种设置）默认都存在 wp_options 表里，每次页面渲染都要查数据库。
具体一次页面加载会触发多少次数据库查询？ 一个装了几个插件的 WordPress 站点，页面加载的查询数在 20 到 60 次之间。这几十次查询里，很多是重复的——比如每篇文章都要读一次站点标题、每条评论都要读一次作者信息、菜单项在同一个页面的各个位置被反复读取。
没有对象缓存时，这些查询每次都打到 MySQL。有对象缓存时，同一个键在 TTL 期间只查一次数据库，其余直接从内存拿。
第二个角色是 Session 存储。 WordPress 的用户登录状态默认存在 PHP session 里，而 PHP session 默认存在文件里（/var/lib/php/sessions）。文件 session 在高并发下有个 notorious 的问题：PHP session 文件是带锁的，同一个用户的并发请求会互相阻塞。 换成 Redis 之后这个问题消失。
在 Laravel 里，Redis 的角色更多：
一是缓存（Cache Facade）。 任何你 Cache::remember() 包裹的东西。
二是队列后端（Queue Driver）。 发送邮件、生成 PDF、调用第三方 API 这些耗时操作都应该丢进队列，而队列后端就用 Redis。 这是 Laravel 应用最常见的 Redis 用途。
三是会话（Session Driver）。 Laravel 默认用 file session，改成 Redis 后同样能解决文件锁问题。
四是 Rate Limiter（限流）。 Laravel 自带的限流中间件默认就支持 Redis 驱动。
五是缓存标签和原子锁。 Laravel 的 Cache::tags()（一组键一起失效）只在 Redis 和 Memcached 上支持，file 驱动不支持。
所以「需不需要 Redis」的真正问题不是「你的站点访问量多少」，而是「你有没有上面这些场景」。 一个日均 500 PV 的博客，如果后台没有队列任务、没有用户登录、插件也没装几个，那 Redis 对你的收益接近零；而一个日均 5000 PV 的 Laravel 商城，如果订单要发邮件、支付要回调，那 Redis 几乎是必需品。
二、一个 1GB 机器装 Redis 会占多少内存
这是最实际的问题：小内存 VPS 上，Redis 要吃掉的内存会不会把 PHP 挤死。
先给结论：Redis 的内存占用取决于你往里放了什么，而不是它自己有多重。 空 Redis 的常驻内存只有几 MB，但每个键的存储开销大约是键名长度加上值长度再加 50 到 100 字节的元数据。 所以「Redis 吃内存」实际上是「你缓存的数据吃内存」。
算一下典型的 WordPress 场景。 一个装了 20 篇文章、10 个页面、5 个分类、50 个用户的站点，完整缓存下来的对象缓存大约是 2000 到 5000 个键。如果每个键平均 200 字节（键名加序列化后的值），5000 个键就是 1MB 左右。 这个量级几乎可以忽略不计。
真正吃内存的是下面这几种情况：
第一种是缓存了大型对象。 比如把整个商品列表、整份配置数组、或者一个大的查询结果集整个塞进一个键。这种用法会让 Redis 变成一个「更慢的数据库」——因为你把所有数据都读出来再反序列化一遍。 正确做法是拆成小键，按条目缓存。
第二种是 session 存储。 如果每个用户的 session 有 20KB，一个日活 1000 人的站就是 20MB。这个量级还是可接受的，但要记得 session 有过期时间，Redis 会自动清理。
第三种是队列积压。 队列任务是 Redis 里最占内存的东西——每个待处理任务都带着完整的 payload。如果你的任务里带了文件内容或者大数组，一个任务就能吃掉几 MB。 队列积压到几万个任务时，Redis 内存会涨到几百 MB。 这是最常见的「Redis 突然吃满内存」的原因。
第四种是没有设置 TTL，数据永不失效。 这是最危险的情况。任何缓存系统的内存泄漏，本质上都是「数据只进不出」。
所以第一条配置铁律是：给 Redis 配内存上限。
# /etc/redis/redis.conf
maxmemory 256mb
maxmemory-policy allkeys-lrumaxmemory 256mb 是硬上限，2GB 机器建议 128mb 到 256mb，1GB 机器建议 64mb 到 128mb。
maxmemory-policy allkeys-lru 的意思是：内存满了就淘汰最近最少使用的键，不管它设没设 TTL。 这个策略的好处是它保证 Redis 永远不会因为写满而拒绝服务，代价是在极端情况下会丢掉你可能还需要的数据。
其他可选策略的适用场景：
| 策略 | 行为 | 适合什么情况 |
|---|---|---|
allkeys-lru |
淘汰所有键里最久未用的 | 通用推荐，能保证服务不挂 |
allkeys-lfu |
按访问频率淘汰 | 键的访问频率差异大时更准 |
volatile-lru |
只淘汰设了 TTL 的键 | 全部键都有 TTL 时用 |
noeviction |
不淘汰，写满就报错 | 你绝对不能丢缓存数据时用 |
对绝大多数 WordPress 和 Laravel 站点，allkeys-lru 是正确的默认选择。 理由很直接：缓存数据丢了只是性能下降，不会导致功能故障； 而 noeviction 在写满时会让你的站点直接报错。
改完配置要重启并确认：
sudo systemctl restart redis-server
redis-cli config get maxmemory
redis-cli config get maxmemory-policy
redis-cli info memory | grep used_memory_humanused_memory_human 就是 Redis 当前的真实占用。 这个值应该长期稳定在 maxmemory 的 50% 以下，如果长期贴着上限，说明两件事之一：要么缓存策略不对（没设 TTL），要么数据量确实超了。
还有一条命令值得知道：
redis-cli --bigkeys它会找出内存占用最大的键。 跑一次就知道是不是有某个键异常大，这比猜测高效得多。
三、不装 Redis 还有什么替代方案
在决定装 Redis 之前，你应该知道有哪些更轻的替代方案。 有些场景根本不需要额外进程。
替代方案一：MySQL 的查询缓存（8.0 已移除）。 MySQL 5.7 有 query_cache，8.0 彻底删掉了。这个方案在 8.0 上已经不存在，不用考虑。 而且就算在 5.7 上，查询缓存在表结构变更时会全部失效，命中率通常不高。
替代方案二：PHP 的 OPcache。 这是最容易被忽略但最有效的替代方案。 OPcache 缓存的是 PHP 字节码，不是数据，但它消除了「每次请求都要重新解析和编译 PHP 文件」的开销。
对 WordPress 这种文件极多的应用，OPcache 的收益经常大于 Redis。 配置方法：
; /etc/php/8.3/fpm/conf.d/99-opcache.ini
opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 60opcache.max_accelerated_files = 20000 这行对小站点尤其重要——WordPress 加上几个插件轻松就有两三千个文件，默认的 10000 有可能不够。
判断 OPcache 有没有正常工作：
php -r 'print_r(opcache_get_status(false));'看 opcache_enabled 是不是 true，看 cached_scripts 是不是大于 0。
替代方案三：WordPress 内置的 transient 缓存。 WordPress 默认就用数据库做 transient 存储，即使没有 Redis 插件，缓存也是生效的——只是存在 MySQL 里而不是内存里。
用插件看效果。 装一个缓存统计插件，能看到「对象缓存命中次数」和「数据库查询总数」两个数字。这个插件的价值不只是看数字——它还能告诉你哪些查询是重复的，为「要不要上 Redis」提供直接证据。
替代方案四：页面缓存插件。 整页缓存是最有效的优化：把整个页面渲染结果存下来，下次直接返回。对内容型站点（博客、新闻、企业站），整页缓存能让数据库查询数从几十次降到零。
这一条经常被低估：很多站点在「装 Redis 调对象缓存」上花时间，但真正该做的是加整页缓存。 因为对访客来说，页面里 80% 的内容（页头、页脚、侧栏）根本不变。
替代方案五：更激进的静态化。 用静态站点生成器把 WordPress 编译成纯 HTML。这一档完全不需要数据库、不需要 PHP、不需要 Redis，而且性能天花板最高。
替代方案六：APCu（本地进程缓存）。 如果你的数据不需要跨请求共享（同一台机器上的 PHP 进程共享），APCu 能在内存里缓存，完全不需要额外的 Redis 进程：
apc.enabled = 1
apc.shm_size = 128M
apc.entries = 10000APCu 和 Redis 的关键区别是数据不跨机器。 单机部署的站点用 APCu 比 Redis 更省资源——没有网络往返、没有额外进程、没有序列化开销。
但 Laravel 的队列和分布式限流这些场景必须用 Redis，因为它们需要跨进程甚至跨机器共享状态。
把选择逻辑整理成一张表：
| 你的情况 | 首选方案 | 理由 |
|---|---|---|
| 纯内容站，无登录无队列 | 整页缓存 + OPcache | 数据查询次数能降到接近零 |
| WordPress，有登录用户 | Redis 对象缓存 + 整页缓存 | 两者收益不重叠 |
| Laravel，需要队列 | Redis（队列和缓存都要） | file 驱动的队列不可靠 |
| Laravel，纯展示 | OPcache + APCu | 省一个常驻进程 |
| 读多写少，数据可重新生成 | Redis allkeys-lru |
淘汰策略保证不挂 |
四、什么时候该上 Redis：三个可验证的信号
「该不该上」不能靠感觉，要靠信号。这三个信号是可测量的。
信号一：慢查询日志里有大量重复的同一条查询。
打开慢查询日志（配置见前文），跑几天，然后统计重复度：
sudo awk '{print $NF}' /var/log/mysql/slow.log | sort | uniq -c | sort -rn | head -20如果前 20 条里有好几条是同一个查询被反复执行，那它就是典型的缓存候选。
但要注意一个陷阱：慢查询日志的最后一列不一定是查询语句本身（取决于你的日志格式）。更可靠的做法是用 MySQL 8.0 的 sys schema：
SELECT query, count_star, avg_timer_wait/1000000000 AS avg_ms,
sum_rows_examined AS total_examined
FROM sys.statements_with_full_table_scans
WHERE query NOT LIKE 'SHOW%'
ORDER BY count_star DESC
LIMIT 10;看 count_star 和 total_examined 的组合：查询次数多、扫描行数也多的，是最值得缓存的。
信号二：缓存插件显示对象缓存命中率很低。
装 WordPress 的缓存统计插件，跑一周，看「对象缓存命中率」。 低于 50% 说明缓存没起作用——要么是缓存键每次都变（比如带了随机数），要么是页面上的用户相关内容太多导致几乎没东西能被缓存。
这一条比第一条更直接，因为它直接回答「缓存有没有用」。
信号三：MySQL 的 QPS 在业务低峰期也不下降。
看监控里的 QPS 曲线。 一个内容站的 QPS 应该跟着访问量波动，低峰期应该掉到峰值的 20% 以下。 如果低峰期 QPS 仍然很高，说明有大量请求在反复读同样的数据——这就是缓存的用武之地。
反过来，有三种情况信号是「不需要 Redis」：
一是 QPS 曲线和访问量曲线完全同步。 说明每个请求查的都是不同数据，缓存不了。
二是站点是纯 API 服务且每次请求都写数据。 写多读少的场景，缓存收益很低。
三是你的瓶颈明明在别处。 这一条最重要——先定位瓶颈再选方案。 如果慢是因为数据库连接建立慢、或者磁盘 IO 满、或者 PHP 本身慢，加 Redis 不会解决任何问题，你只是多了一个进程。
定位瓶颈的标准顺序：
# 1) CPU 满了没有？——满了说明是计算瓶颈
top
# 2) 内存够不够？
free -m
# 3) 磁盘 IO 呢？
iostat -x 1 3
# 4) MySQL 自己在干什么？
mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Questions';"如果 CPU 使用率长期低于 30%、内存有富余、IO 不满，但 QPS 上不去， 那瓶颈大概率在数据库的锁等待或者网络往返，这时候缓存确实是对症下药。
五、上 Redis 的完整步骤
如果你决定装，这是从零到可用的完整流程。
第一步，装 Redis。
sudo apt update
sudo apt install redis-server装完确认版本和服务状态：
redis-server --version
systemctl status redis-server第二步，改配置。 关键的四项：
# /etc/redis/redis.conf
maxmemory 256mb
maxmemory-policy allkeys-lru
save 900 1
save 300 10
appendonly no关于 save 和 appendonly 这两个持久化选项，要理解它们在小内存机器上的取舍：
save 900 1 表示每 900 秒如果有 1 个键被修改就存一次 RDB 快照。 这个快照会 fork 一个子进程，在 1GB 内存的机器上，fork 的一瞬间会短暂地翻倍内存占用——如果 Redis 用到了 256MB，fork 瞬间可能要 512MB。 这就是小内存机器上 Redis 最大的风险点。
appendonly no 表示关闭 AOF 持久化。 AOF 会把每个写操作追加到文件，好处是数据不会丢，坏处是磁盘 IO 持续有压力。
对小站来说我的建议是：保留 RDB 但把间隔放宽，关闭 AOF。
save 900 1
save 300 10理由是：Redis 里放的是缓存，不是数据源。 真的重启了 Redis，缓存丢失后从 MySQL 重建即可，为可重建的数据付持久化的 IO 代价不划算。 但如果你用 Redis 存队列任务或者 session（这些丢了会有业务影响），那就要开 AOF。
第三步，加密码。 Redis 默认不带密码，任何能连上这台机器的人都能读写。在公网机器上这是必须项。
redis-cli CONFIG SET requirepass "你的强密码"
redis-cli CONFIG GET requirepass注意 CONFIG SET 是临时的，重启后失效，必须写进 redis.conf 才持久。
第四步，限制监听地址。 默认 bind 127.0.0.1 -::1 只听本机，这是对的，保持它。如果你要让应用从另一台机器连 Redis，才改成内网 IP，并且一定要有密码。
第五步，确认生效并测一下性能：
redis-cli -a 你的密码 INFO memory | grep used_memory_human
redis-cli -a 你的密码 INFO stats | grep instantaneous_ops_per_sec
redis-cli -a 你的密码 PINGinstantaneous_ops_per_sec 是每秒操作数，小站一般几百到几千。
第六步，接入 WordPress。 用 Redis Object Cache 插件，装好后启用并填写 Redis 主机、端口、密码。验证插件是否真的连上了：
redis-cli -a 你的密码 KEYS "wp:*" | head -5
redis-cli -a 你的密码 DBSIZEDBSIZE 的数字会随着访问增加，说明缓存真的在写入。
第七步，接入 Laravel。 改 .env：
CACHE_DRIVER=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redis
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=你的密码
REDIS_PORT=6379然后清一次缓存让配置生效：php artisan config:clear && php artisan cache:clear。
第八步，重启 PHP-FPM 让它加载新的 Redis 连接。 sudo systemctl restart php8.3-fpm（版本号按你实际的改）。
验收的标准是三个数字：页面加载时间下降、MySQL 的 QPS 下降、Redis 的 used_memory_human 稳定在 128MB 以内。 三个数字里有两个改善，就说明这钱花得值。
六、Redis 常见的坑和报错原文
装 Redis 之后可能遇到的错误，按原文对照处理。
RedisException: Connection refused —— 最常见的一种。 原因有三个可能：Redis 服务没启动（systemctl status redis-server 查）、应用连的地址不对（容器里要注意不能用 127.0.0.1，要用容器服务名或者宿主机 IP）、或者端口被防火墙拦了。在容器场景里这是最典型的坑——127.0.0.1 指的是容器自己，不是宿主机。
RedisException: NOAUTH Authentication required. —— 连上了但没带密码。密码必须写在配置里，不能指望它自动带上。
RedisException: WRONGPASS invalid username-password pair —— 密码错了。 注意 Redis 6.0 之后支持 ACL，requirepass 设置的是默认用户。如果你的应用报这个错，检查密码里的特殊字符有没有被 shell 转义掉。
OOM command not allowed when used memory > 'maxmemory' —— 写满了。如果你用的是 noeviction 策略，这就是它拒绝写入的表现。 改成 allkeys-lru 就能自动淘汰。
LOADING Redis is loading the dataset in memory —— 正在从 RDB 恢复，这时候不接受任何命令。 出现在 Redis 重启后。解决办法有两个：等它加载完，或者把 RDB 文件删掉让它以空数据集启动（缓存数据丢了会从 MySQL 重建，所以删 RDB 通常是安全的）。
Can't connect to Redis server（WordPress 插件的报错） —— 连接问题，但原因通常是PHP 缺少 Redis 扩展。检查：
php -m | grep -i redis没有输出就说明没装扩展。 Debian 系装 php8.3-redis（版本号按你的 PHP 版本改），然后 sudo systemctl restart php8.3-fpm。
phpredis vs predis 的选择： 两个都是 PHP 客户端。phpredis 是 C 扩展，性能更好但需要装扩展；predis 是纯 PHP 实现，不需要扩展但慢一些。 小内存机器上如果为了装扩展出问题，用 predis 更省事——它只需要 Composer 装一个包：
composer require predis/predis还有一个不报错但很坑的问题：WordPress 的对象缓存和 transient 不一样。 对象缓存是全局的（存在 Redis 里，所有用户共享），transient 默认也是对象缓存的，但如果插件配置不当，transient 可能仍然写在 wp_options 表里。 判断方法是在 Redis 里查键：
redis-cli -a 你的密码 KEYS "wp:*transient*" | head有输出说明 transient 进了 Redis，没有输出说明还在数据库里。
七、上 Redis 之后要盯哪几个指标
Redis 最容易出问题的不是连不上，是「悄悄变慢」和「悄悄变满」。 这几个指标能提前发现。
指标一：内存使用率。
redis-cli -a 你的密码 INFO memory | grep -E "used_memory_human|maxmemory_human"判断标准：长期稳定在 maxmemory 的 50% 以下最好。 超过 80% 就该查了。
更精确的命中率指标是 evicted_keys：
redis-cli -a 你的密码 INFO stats | grep evicted_keys这个数字在增长说明有键在被淘汰。 淘汰本身不是坏事（这是 LRU 的正常行为），但如果增长很快，说明你的 maxmemory 给小了，或者缓存里混进了不该缓存的大对象。
指标二：命中率。
redis-cli -a 你的密码 INFO stats | grep -E "keyspace_hits|keyspace_misses"命中率的算法是 keyspace_hits / (keyspace_hits + keyspace_misses)。 低于 80% 说明缓存策略或键设计有问题——常见原因有三个：TTL 太短导致频繁失效、键名带了随机数导致每次都 miss、缓存的数据大部分是一次性的（根本不该缓存）。
指标三：连接数。
redis-cli -a 你的密码 INFO clients | grep connected_clients这个数字持续增长不回落，说明有连接泄漏。 常见原因是用完不关闭、或者持久连接开太多。
指标四：慢查询。 Redis 内置的慢日志：
redis-cli -a 你的密码 CONFIG SET slowlog-log-slower-than 10000
redis-cli -a 你的密码 SLOWLOG GET 10这个阈值是 10000 微秒，也就是 10 毫秒。 Redis 的正常命令都是微秒级的，超过 10 毫秒的命令在调查。 如果你用 Redis 存了很大的 value，GET 一个几百 KB 的键就会触发这个告警——这是另一个「别把大对象塞进 Redis」的证据。
指标五：内存碎片率。
redis-cli -a 你的密码 INFO memory | grep mem_fragmentation_ratio这个值大于 1.5 说明有内存碎片。 碎片是 Redis 分配内存后释放但没还给系统造成的。在 1GB 机器上碎片很致命——你以为释放了 100MB，实际系统看到的可用内存并没有增加那么多。 碎片率高于 1.5 时可以重启 Redis 释放（缓存会重建）。
把这些指标做成一个监控脚本：
#!/bin/bash
# /usr/local/bin/redis-monitor.sh
PASS="你的密码"
HIT=$(redis-cli -a $PASS INFO stats | grep -E "^keyspace_hits" | cut -d: -f2)
MISS=$(redis-cli -a $PASS INFO stats | grep -E "^keyspace_misses" | cut -d: -f2)
MEM=$(redis-cli -a $PASS INFO memory | grep used_memory_human | cut -d: -f2)
CONN=$(redis-cli -a $PASS INFO clients | grep connected_clients | cut -d: -f2)
echo "$(date +'%F %T') mem=$MEM conn=$CONN hits=$HIT misses=$MISS"同样配一个 cron 每分钟采集。
八、Redis 到底吃掉了你多少资源
这一节回到算账：装 Redis 在你的机器上到底是什么成本。
先看 Redis 本身的固定开销。 一个空的 Redis 实例常驻内存大约 3MB 到 10MB（取决于版本和配置），CPU 占用在空闲时接近零。这个开销可以忽略。
真正的成本是数据本身。 按前面的估算，WordPress 站点的对象缓存通常在 1MB 到 20MB 之间；Laravel 的队列加缓存通常在 10MB 到 100MB 之间（取决于队列积压）。
内存成本换算成钱。 按公开商品参数库（快照 2026-11-11）的真实报价，各内存档位的价格是：
| 机型 | 内存 | 折合月价 | 每 GB 内存成本 |
|---|---|---|---|
| RosCloud-01 | 1GB | 19.99 美元 | 19.99 美元 |
| RosCloud-02 | 2GB | 29.99 美元 | 14.99 美元 |
| RosCloud-03 | 4GB | 39.99 美元 | 10.00 美元 |
| RosCloud-04 | 8GB | 49.99 美元 | 6.25 美元 |
| LAX-STARTER | 2GB | 16.67 美元 | 8.33 美元 |
| LAX-MICRO | 4GB | 33.33 美元 | 8.33 美元 |
| LAX-MEDIUM | 8GB | 66.67 美元 | 8.33 美元 |
所以「为了给 Redis 腾内存而加一档」这个动作的真实成本是：2GB 到 4GB 是 16.66 美元/月（LAX-MICRO 对 LAX-STARTER）或 10 美元/月（RosCloud-03 对 RosCloud-02）。
关键问题是：这个 16.66 美元换来的性能提升值不值？
用一个可算的公式判断：
值 = 每月节省的响应时间 × 每次访问的价值 × 月访问量
换算成更直观的判断标准——如果你的 MySQL QPS 超过 500 且慢查询占比超过 1%，那装 Redis 大概率值； 如果 QPS 低于 100 且没有登录用户，那不值，多花的 16.66 美元不如直接加内存给 PHP 用。
再看 Redis 带来的额外风险成本。 这一节前面提过的 fork 内存翻倍问题，在 1GB 机器上是真实风险。量化一下：
Redis 用 256MB 时，RDB fork 瞬间需要额外 256MB， 加上 Redis 自己的 256MB，一共 512MB。在 1GB 机器上，PHP-FPM 加上操作系统再挤 400MB，就已经在崩溃边缘了。
规避办法有三个，按推荐顺序：
第一，把 maxmemory 降到 128MB。 这样 fork 峰值是 256MB，安全。
第二，关掉 RDB 持久化（save ""）。 缓存数据丢了能重建，不值得为它付 fork 的风险。 唯一例外是队列和 session。
第三，换有内存余量的机器。 这是最彻底的办法——按上面的表，2GB 起步比 1GB 稳得多。
顺便说一下流量和 Redis 的关系。 按商品库标注的月流量，一个 2GB 内存的 LAX-STARTER 配 5000GB 流量，按每个 PV 100KB 计算，可支撑约 5243 万 PV/月。 而 Redis 的内存消耗和流量无关，和请求数有关。 这两个量级不在一个维度上，所以「流量够不够」和「Redis 够不够」要分开判断——前者看带宽账单，后者看内存。
九、按访问量分档：明确的结论
直接给结论，不用再纠结。
日均 PV 在 500 以下，个人博客或小企业站。 不要装 Redis。 这个量级下 MySQL 的 QPS 也就几十，数据库根本不是瓶颈。 把精力放在三件事上：开 OPcache（配置见第三节）、装一个整页缓存插件、把图片放到 CDN 或者对象存储。如果实在想用缓存，WordPress 的数据库 transient 就够了，它默认就在工作。 机器选 RosCloud-01（19.99 美元/月）或 LAX-STARTER（16.67 美元/月）就够。
日均 PV 在 500 到 5000，有用户登录的 WordPress 站，或者用了 WooCommerce。 可以装 Redis，但优先级排在整页缓存之后。 理由是 WooCommerce 的购物车和 session 是缓存在 session 里的，用户一多，文件 session 的锁竞争就会显现。 这个阶段的具体顺序是：先整页缓存，再 OPcache，最后 Redis 对象缓存。 机器至少 2GB——LAX-STARTER 16.67 美元/月或者 Residential-STARTER 21.67 美元/月（同配置，住宅 IP）。
日均 PV 在 5000 到 5 万，业务系统、Laravel 应用、有队列任务。 该装 Redis 了，而且队列后端也应该用 Redis。 理由是这个量级下 file 驱动的队列会有真实的可靠性问题（进程被 OOM 杀掉时任务状态丢失），而 Redis 队列加锁更可靠。 机器至少 4GB——LAX-MICRO 33.33 美元/月（每 GB 内存 8.33 美元）或者 RosCloud-03 39.99 美元/月。注意 4GB 机器上 Redis 的 maxmemory 设 256MB，PHP-FPM 的 worker 数要按剩下的内存算，两边不能都按满配。
日均 PV 在 5 万以上。 装 Redis 是必选项，同时要重新审视整个架构。 这个量级下，单机四件事都要做：Redis 做缓存和队列、OPcache 开着、MySQL 单独调优（buffer pool 至少 1G）、前面挂 CDN 扛静态资源。机器至少 8GB——LAX-MEDIUM 66.67 美元/月（10000Mbps 带宽，20000GB 流量）或者 RosCloud-04 49.99 美元/月。到了这个量级，你要优化的已经不是「装不装 Redis」，而是「数据库要不要读写分离」「静态资源要不要上 CDN」「要不要上独立的队列机器」。
还有一个特殊情况要单独说：如果你已经有一台 4GB 的机器在跑 PHP 和 MySQL，只想把缓存挪出去。 这时候 Redis 单独开一台小机器反而是更好的方案——按商品库的价格，2GB 内存的机型 16.67 美元/月起，用 LAX-STARTER 或者 Residential-STARTER 这类 2GB 机型跑纯缓存完全够，主机的内存就不用被 Redis 挤占了。这个方案的额外成本是网络往返延迟，如果你的主站和 Redis 在不同地区，内网往返超过 1 毫秒就会吃掉一部分缓存收益，所以 Redis 尽量和主站放在同一个机房。
按你的情况，下一步该看哪家
上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：
- 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
- 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 racknerd 当前机型与价格
- 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 cloudcone 当前机型与价格
价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。
十、上 Redis 的完整检查清单
把全文压缩成一个能照着走的清单。
第 1 步：先确认瓶颈在哪。 跑 top、free -m、iostat -x 1 3。CPU 长期低于 30%、内存有富余、IO 不满，才说明瓶颈可能在数据库。 这一步做错，后面全白搭。
第 2 步：量化重复查询。 装缓存统计插件跑一周，看对象缓存命中率；或者用 sys.statements_with_full_table_scans 看查询次数和扫描行数。命中率低于 50% 且查询高度重复，才值得上 Redis。
第 3 步：确认整页缓存已经做了。 这一步经常被跳过，但它对内容站的收益比 Redis 大。 整页缓存能让数据库查询数直接归零，在整页缓存到位之前上 Redis，是本末倒置。
第 4 步：算内存账。 决定 maxmemory（2GB 机器给 128mb 到 256mb），算 PHP-FPM 的 worker 数上限，两边加起来不能超过物理内存的 85%。
第 5 步：装并配置。 四个必改项：maxmemory、maxmemory-policy allkeys-lru、Redis 密码、bind 127.0.0.1 保持只听本机。持久化按第四节说的取舍。
第 6 步：接入应用。 WordPress 用 Redis Object Cache 插件（或者 predis 避免装扩展）；Laravel 改 .env 的 CACHE_DRIVER、SESSION_DRIVER、QUEUE_CONNECTION 三个值。
第 7 步：验收三个数字。 页面加载时间下降、MySQL 的 QPS 下降、Redis 内存稳定在 maxmemory 的 50% 以下。 三个里有两个改善就算成功。
第 8 步：加监控。 内存使用率、命中率、连接数、evicted_keys 的增长趋势。evicted_keys 持续增长是唯一的红色警报，说明缓存空间不够或者键设计有问题。
最后再强调一次本文的核心判断：小站不需要 Redis，大站离不开 Redis，而中间那一档的真正决定因素不是访问量，是「你有没有重复查询」和「你有没有队列任务」。 先量再装，不要因为「听说 Redis 能加速」就往一台 1GB 的机器上塞——那台机器上 PHP 和 MySQL 抢内存已经够呛了，再加第三个常驻进程，是把问题放大而不是解决。
喜欢 
高兴
鬼脸
呵呵
无聊
伤心
