PHP怎么配置缓存_PHP各种缓存配置教程

php的缓存配置，本质上是为了让你的应用跑得更快，更稳定。它不是一个单一的技术，而是一套组合拳，涵盖了从PHP代码本身到数据存储的多个层面。核心观点在于，通过减少重复计算、重复查询或重复加载，来节省资源和时间。常见的手段包括利用操作码缓存（如OpCache）加速脚本执行，以及使用数据缓存（如redis、memcached）存储频繁访问的数据。

解决方案

要让PHP应用性能飞起来，缓存是绕不过去的一环。我个人在实践中，通常会从以下几个核心方面着手配置和优化：

首先是OpCache，这是PHP官方自带的操作码缓存。它的原理很简单：PHP脚本在执行前需要被编译成操作码（opcode），OpCache就是把这些编译好的操作码存起来，下次再请求同一个脚本时，就直接执行已编译好的操作码，省去了重复编译的开销。对于任何PHP应用来说，这几乎是一个“必开”的选项。

配置OpCache，主要在你的

php.ini

文件中进行：

立即学习“PHP免费学习笔记（深入）”；

; 启用OpCache opcache.enable=1 ; 启用CLI模式下的OpCache，对composer等工具很有用 opcache.enable_cli=1 ; 分配给OpCache的内存大小，单位MB，根据你的项目文件数量和大小调整 opcache.memory_consumption=128 ; 可以缓存的最大文件数量，大型项目需要调大 opcache.max_accelerated_files=10000 ; 检查文件更新的频率（秒）。0表示每次请求都检查，生产环境可以设为60或更高 opcache.revalidate_freq=60 ; 如果设置为0，当opcache.revalidate_freq为非0时，OpCache会使用文件时间戳来判断文件是否更新。 ; 如果设置为1，OpCache会使用inode和文件大小来判断。通常0即可。 opcache.revalidate_path=0 ; 是否缓存注释，如果你的框架大量使用注释进行路由或ORM映射，可以开启 opcache.save_comments=1 ; 当缓存区满了，回收旧的缓存文件。 opcache.interned_strings_buffer=8

这些参数的调整，直接关系到OpCache的效率。我通常会根据项目的实际情况，比如代码量、更新频率来微调。

接着是数据缓存，这才是真正的“大头”，因为它能解决数据库压力大、API请求慢等应用层面的性能瓶颈。这里最常用的就是Redis和memcached。

Redis 是一个高性能的键值存储系统，它支持多种数据结构（字符串、哈希、列表、集合、有序集合），而且可以将数据持久化到磁盘，这在某些场景下非常有用。

配置Redis通常需要安装PHP的

redis

扩展：

pecl install redis

然后在

php.ini

中添加：

extension=redis.so

在PHP代码中，使用Redis大致是这样的：

$redis = new Redis(); // 连接Redis服务器，通常是本地或指定的IP端口 $redis->connect('127.0.0.1', 6379);  // 设置键值对，并设置过期时间（秒） $redis->set('my_data_key', 'some_value', 3600);  // 获取数据 $data = $redis->get('my_data_key'); // 复杂数据结构的操作 $redis->lPush('my_list', 'item1'); $redis->lPush('my_list', 'item2');

我喜欢用Redis，因为它功能强大，除了缓存还能做消息队列、排行榜等。

Memcached 则相对简单，它是一个纯内存的键值存储系统，不支持持久化，数据掉电即失。它以其极致的简单和速度著称，适合存储那些不那么重要，或者可以从源头重建的数据。

配置Memcached需要安装PHP的

memcached

或

memcache

扩展（推荐

memcached

，功能更丰富）：

pecl install memcached

然后在

php.ini

中添加：

extension=memcached.so

PHP中使用Memcached：

$memcached = new Memcached(); // 添加Memcached服务器 $memcached->addServer('127.0.0.1', 11211);  // 设置键值对，并设置过期时间（秒），0表示永不过期 $memcached->set('another_data_key', 'another_value', 3600);  // 获取数据 $data = $memcached->get('another_data_key');

在我看来，Memcached的优势在于它的简洁和高速，对于纯粹的KV缓存场景，它表现出色。

如何选择适合我的PHP缓存方案？

选择合适的PHP缓存方案，这真不是一刀切的问题，得根据你项目的具体情况来。我通常会从几个维度去思考：

Melodio

Melodio是全球首款个性化AI流媒体音乐平台，能够根据用户场景或心情生成定制化音乐。

59

查看详情

首先是你的项目规模和流量预期。如果只是一个访问量不大的个人博客或小型企业站，可能OpCache加上简单的文件缓存就能满足大部分需求了。OpCache是基石，这个几乎是无脑开。但如果你的应用是高并发、数据密集型的，比如电商平台、社交应用，那Redis或Memcached就成了标配，甚至是多层缓存的组合。

其次是你缓存的数据类型和对持久性的要求。如果你只是想缓存一些数据库查询结果、API响应或者用户会话数据，而且这些数据即使丢失了也能从源头重建，那么Memcached凭借其极致的读写速度会是一个不错的选择。它就像一个临时的、超快的内存池。但如果你的数据有持久化需求，比如需要做一些原子操作、计数器，或者希望服务器重启后数据依然存在，那Redis的优势就非常明显了。Redis支持多种数据结构，还能做数据持久化，甚至可以集群化部署，功能上远超Memcached。我个人在需要复杂数据结构或持久化时，更倾向于Redis。

再者，团队的技术栈和运维能力也得考虑。如果你的团队已经熟悉Redis的运维和开发，那自然是首选。如果对Memcached更了解，或者追求极致的简单，Memcached也未尝不可。别忘了，引入新的技术栈意味着学习成本和潜在的运维挑战。

最后，预算和资源也是一个实际问题。虽然自建Redis/Memcached服务成本不高，但如果你想用云服务商提供的托管缓存服务，那费用就会成为一个考量因素。通常来说，Redis的功能更丰富，资源占用也可能相对高一些，但其带来的价值往往是值得的。

我的经验是，对于大多数现代PHP应用，OpCache + Redis的组合是一个非常稳妥且强大的方案。OpCache负责加速PHP脚本本身，Redis则负责应用层的数据缓存，两者协同工作，能显著提升整体性能。

PHP缓存配置中常见的坑和优化技巧有哪些？

在PHP缓存的配置和使用过程中，我踩过不少坑，也总结了一些优化技巧。这就像开车，知道怎么启动是基础，但怎么开得又快又稳，才是真本事。

OpCache方面：

• 最常见的坑：忘记重启PHP-FPM。 你改了

  php.ini

  ，但PHP-FPM进程没重启，OpCache的配置根本没生效，然后你还在纳闷为什么性能没提升。部署脚本里加上

  sudo service php-fpm restart

  （或

  systemctl restart php-fpm

  ）是基本操作。

• 缓存失效策略不当：

  opcache.revalidate_freq

  设置不合理。 生产环境如果设为0，每次请求都检查文件更新，OpCache的优势就大打折扣了。我一般会设成60秒或更高，配合部署脚本在代码更新后手动清空OpCache（

  opcache_reset()

  函数或者重启PHP-FPM）。

• 内存分配不足：

  opcache.memory_consumption

  太小。 如果你的项目代码量很大，这个值设置太小会导致OpCache频繁回收，降低效率。监控OpCache状态（可以通过

  opcache_get_status()

  函数或一些OpCache GUI工具）可以发现这个问题。

• 缓存文件数量限制：

  opcache.max_accelerated_files

  不够。 大项目文件数量多，这个值也需要相应调大，否则部分文件无法被缓存。

Redis/Memcached数据缓存方面：

• 缓存雪崩：大量缓存同时失效。 比如你把所有商品的库存缓存都设成同一时间过期，那到期那一刻，所有请求都会打到数据库上，直接把数据库冲垮。解决办法是给缓存过期时间加上一个随机的小偏移量，让它们错峰过期。
• 缓存穿透：查询不存在的数据。 恶意请求或业务逻辑bug导致频繁查询一个不存在的键，每次都穿透到数据库。我的做法是，对于查询结果为空的数据，也将其缓存起来，设置一个较短的过期时间，避免下次再穿透。
• 缓存击穿：热点数据失效。 某个非常热门的数据（比如爆款商品）缓存过期了，瞬间涌入的大量请求都会去查询数据库。可以考虑对这类热点数据设置“永不过期”，或者在查询时加上分布式锁，确保只有一个请求去数据库查询，其他请求等待缓存更新。
• 键名设计不合理。 缓存键名要清晰、唯一，并且能够反映数据内容。避免过长或过于复杂的键名，会影响效率。
• 序列化/反序列化性能问题。 PHP默认的

  serialize()

  /

  unserialize()

  在处理大对象时性能不佳。可以考虑使用

  JSon_encode()

  /

  json_decode()

  ，或者更高效的

  igbinary

  、

  msgpack

  等扩展。

通用优化技巧：

• 监控是王道。 无论是OpCache命中率、内存使用，还是Redis/Memcached的命中率、连接数、内存占用，都应该有监控。发现问题才能解决问题。
• 缓存预热。 在应用上线或更新后，通过脚本提前将一些核心数据加载到缓存中，避免用户首次访问时的冷启动问题。
• 合理设置缓存粒度。 是缓存整个页面，还是页面片段，还是只缓存数据库查询结果？根据实际情况选择最合适的粒度。
• 使用连接池。 对于高并发应用，频繁创建和关闭Redis/Memcached连接会消耗资源，使用连接池可以复用连接，提高效率。

除了OpCache、Redis和Memcached，还有哪些值得关注的PHP缓存技术？

当然有，缓存的世界远比我们想象的要广阔和多层次。在我看来，除了那些主流的OpCache、Redis和Memcached，还有一些非常值得关注的缓存技术，它们在不同的场景下发挥着独特的作用：

1. APCu (APC User Cache)： APCu是APC（Alternative PHP Cache）的用户数据缓存部分，APC本身已经包含了OpCache功能，但随着php7的发布，OpCache被内置到PHP核心，APCu就专门用于提供用户层面的键值对缓存。它是一个纯内存的缓存，可以用来存储PHP应用内部的变量、对象或配置数据，而无需通过网络请求外部服务（如Redis）。 我个人觉得，如果你有一些应用内共享的、生命周期与请求相关的、不需要持久化的小块数据，APCu是一个非常轻量且高效的选择。它比Redis/Memcached更接近应用层，省去了网络通信的开销。

2. 文件缓存： 虽然听起来有点“土”，但文件缓存依然有它的用武之地。它指的是将数据直接序列化后存储到服务器的本地文件系统中。 在一些小型项目，或者对性能要求不是极致，但又想避免频繁数据库查询的场景，文件缓存是个简单易行的方案。比如，缓存一些不常变动的配置信息、生成静态html片段、或者作为一种简单的二级缓存。它的缺点也很明显：IO开销大、并发性能差、不适合大量小文件。但在某些特定场景下，比如生成静态化页面，它还是非常有效的。

3. 数据库查询缓存（及ORM二级缓存）： 很多数据库本身就提供了查询缓存功能（比如mysql 5.7及以前版本有查询缓存，但在8.0版本中已移除，因为它的局限性）。虽然MySQL的查询缓存现在不推荐使用，但其理念是相通的：缓存SQL查询的结果。 在ORM（对象关系映射）框架中，通常也会有二级缓存的概念。比如Doctrine ORM就支持将查询结果或实体对象缓存到Redis、Memcached甚至APCu中。这能有效减少对数据库的查询次数，提高ORM的性能。这是一种更贴近业务逻辑的缓存，我通常会在数据库层面压力大时，考虑结合ORM的二级缓存来进一步优化。

4. 反向代理缓存 (如Varnish, nginx FastCGI Cache)： 这严格来说不是PHP层面的缓存，但它们在整个Web应用架构中扮演着至关重要的角色，并且与PHP缓存协同工作。

• Varnish Cache 是一个高性能的http加速器，它可以缓存整个HTTP响应（即整个页面或静态资源）。当用户请求一个被Varnish缓存的页面时，Varnish会直接返回缓存内容，甚至不需要PHP应用介入，大大减轻了后端服务器的压力。
• Nginx FastCGI Cache 则是Nginx自带的一种缓存机制，它可以缓存PHP-FPM处理后的响应。它比Varnish更接近应用层，可以根据URL、请求参数等条件进行缓存。

我个人在构建高并发系统时，通常会把Varnish或Nginx FastCGI Cache放在最前端，作为第一道防线。它们能处理大部分静态或半静态的请求，只有那些真正需要动态生成内容的请求才会穿透到PHP应用层，然后再由OpCache和Redis/Memcached进行内部优化。这种多层缓存的策略，能构建出非常健壮和高效的系统。

以上就是PHP怎么配置缓存_PHP各种缓存配置教程的详细内容，更多请关注php环境搭建 mysql php redis html js 前端 json node composer php7 php sql mysql nginx 架构 分布式 html 数据类型 字符串 数据结构 栈 并发 对象 redis memcached memcache 数据库 http bug