PHP本地缓存与分布式缓存

本文目录导读：

1. 概念阐述
2. 常见实现方式
3. 核心对比 (优缺点分析)
4. 在实际项目中的应用场景
5. 常见的架构模式与痛点
6. 结论与建议

我们详细来聊聊PHP中的本地缓存与分布式缓存,并从概念、实现、优缺点到应用场景进行全面的对比。

---

概念阐述

本地缓存 (Local Cache)

• 定义： 缓存数据存储在当前应用服务器的内存中（或极少数情况下的本地硬盘），它是与PHP进程（或一个PHP-FPM worker）绑定的。
• 核心特点：
  • 速度快： 直接读取内存，没有网络I/O开销，是性能最高的缓存方式。
  • 作用域小： 仅在当前进程/服务器内有效，同一台服务器上的其他PHP进程，或者集群中的其他服务器，都无法感知该缓存。
  • 生命周期短： 数据随进程存活，PHP-FPM进程处理完请求后，生命周期结束，内存释放（除非使用常驻内存扩展如Swoole）。

分布式缓存 (Distributed Cache)

• 定义： 缓存数据存储在独立的外部服务器（或集群）上，PHP应用通过网络协议（如TCP/IP）去读写。
• 核心特点：
  • 共享性： 所有应用服务器、所有PHP进程可以访问同一份缓存数据，实现全局共享。
  • 网络开销： 每次读写都需要通过局域网（或云内网）进行网络请求，性能和本地内存相比有一定差距。
  • 独立扩展： 缓存服务和应用服务分开，缓存容量和性能都可以独立横向扩展。
  • 数据持久性： 通常有数据持久化或主从备份机制，重启应用服务器不影响缓存数据。

---

常见实现方式

类型	PHP实现方式	典型工具/库	说明
本地缓存	APCu (Alternative PHP Cache)	apcu_store() / apcu_fetch()	OPcache的姊妹扩展，专用于用户数据缓存，纯内存操作，速度极快。
	内存数组	PHP变量	仅限单次请求内，如函数内静态变量或单例模式，生命周期极短，但实现最简单。
	Swoole / Workerman 进程内共享	Swoole\Table	在常驻内存环境中，通过共享内存方式在多个协程/Worker间共享数据，属于应用层本地缓存。
分布式缓存	Redis	Predis / PhpRedis 扩展	功能最强大，支持持久化、集群、多种数据结构（String、Hash、List、Set等），现代PHP应用的首选。
	Memcached	Memcached (libmemcached) / Memcache (旧)	纯内存KV存储，性能极佳，但功能较为单一（仅支持String），适合简单数据缓存。
	数据库缓存表	PDO	不推荐，性能最低，但可以作为一种兜底方案。

---

核心对比 (优缺点分析)

维度	本地缓存	分布式缓存
性能	极高（微秒级，几乎是纯内存寻址）	较慢（毫秒级，存在网络传输和序列化开销）
扩展性	差，L2缓存只存在于单台机器，无法水平扩展。	极佳，可以任意增加Redis节点或集群容量。
一致性	难以同步，多台服务器间的缓存数据可能不一致（脏数据）。	全局一致，所有服务器读取同一个数据源。
故障处理	无风险，缓存丢失，应用仍然还能跑（只是慢一点）。	有风险，如果Redis挂掉，可能引发缓存穿透，导致大量请求直接打到数据库，引发雪崩。
存储容量	受限，受限于单台服务器的物理内存大小。	巨大，可以横向扩展来获得数GB甚至TB级的内存。
网络依赖	无，不消耗网络带宽。	有，需要占用网络I/O，通常是内网。
数据生命周期	短，随进程消亡。	长，独立于应用服务器。

---

在实际项目中的应用场景

在实际项目中,这两种缓存通常是结合使用的，形成两级缓存架构。

场景1：高并发页面/热点数据（如首页大流量）

• 问题： 首页数据量虽小，但QPS（每秒查询数）极高，如果每次都去Redis查询，虽然很快，但也会消耗大量内网带宽和Redis连接数。
• 解决方案： L1（本地缓存） + L2（分布式缓存）。
  • 请求进来,先查L1（APCu/Swoole Table）。
  • 如果L1命中，直接返回，毫秒级甚至微秒级响应。
  • 如果L1未命中，再去查L2（Redis），查到了就先把数据写入L1，再返回。
  • 如果L2也未命中,最后查数据库，并回填L1和L2。

场景2：共享登录状态 / Session

• 问题： 用户登录后，Session信息需要被多台负载均衡后的应用服务器共享。
• 解决方案： 必须使用分布式缓存（Redis）。

  不能使用本地缓存,因为不知道用户的下一次请求会落到哪台服务器上，否则用户需要反复登录。

场景3：非共享业务的临时数据（如用户特定列表）

• 问题： 某个用户请求自己的消息通知列表，这个数据对其他用户没有意义，且不常更新。
• 解决方案： 倾向于使用本地缓存（APCu）。

  如果服务多台,这个列表是用户私有的，每台服务器存一点也没关系，因为再次请求这个用户时，如果请求落到了别的机器上，顶多就是重新去数据库查一下并生成，由于数据是私有的，不会产生跨机器的数据不一致问题，用L1成本更低。

---

常见的架构模式与痛点

两级缓存（L1 + L2）的一致性问题

• 痛点： 更新数据时，必须同时更新L1和L2，否则L1的数据就会是脏数据，但L1存在于多台服务器上，无法主动清除。
• 解决策略：
  • 短TTL（过期时间）：L1的TTL通常设置得非常短（如3-5秒），L2可以设置长一些（如30分钟），牺牲短暂的一致性，换取极高的吞吐量。
  • 消息队列广播：更新数据库后，发一条消息，各进程收到消息后主动清空自己的L1缓存，这增加了系统复杂度，一般用于核心强一致场景。

缓存穿透问题

• 痛点： 大量请求查询一个不存在的Key（如一个大V的ID被猜测遍历）。
• 解决方法：
  • 空值缓存：在Redis中缓存一个空的占位符，设置极短的TTL。
  • 布隆过滤器：在缓存之前加一个布隆过滤器，快速判断数据是否一定不存在。

缓存雪崩问题

• 痛点： Redis服务本身宕机，或者大量Key在同一时间过期，导致请求全部打到数据库，数据库瞬间崩溃。
• 解决方法：
  • 本地缓存（L1）在这里起到了兜底作用，即使Redis挂了，L1还能顶住一部分流量。
  • 设置缓存Key的过期时间随机化（防止大面积同时失效）。
  • Redis搭建主从 + 哨兵/集群，保证可用性。

---

结论与建议

1. 永远优先选择分布式缓存（Redis）： 这是PHP应用的基础设施，它可以保证全局一致性，支持复杂数据结构，并且易于维护。
2. 在热点数据上叠加本地缓存： 当发现Redis的压力比较大，或者某个具体的数据查询频率极高时，引入APCu作为L1，能大幅提升性能，减少内网开销。
3. 不要滥用本地缓存： 如果你的应用是单体架构，单机部署，用本地缓存没问题，但如果是微服务或分布式集群，纯本地缓存会导致数据不一致，排查问题会非常痛苦。
4. 注意PHP-FPM的生命周期： 普通PHP-FPM环境下，千万不要尝试用静态变量做长期缓存（它会随请求结束而释放），如果想要有效使用本地缓存，请务必安装APCu扩展，或者使用Swoole/Workerman常驻内存模式。

核心总结： 本地缓存是“快钱”（快但不稳定），分布式缓存是“金库”（稳定但有点门槛），高并发系统，金库”存长时间热点数据，“快钱”兜底极短的瞬时高并发。