本文目录导读：
我们详细来聊聊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搭建主从 + 哨兵/集群，保证可用性。
结论与建议
- 永远优先选择分布式缓存（Redis）： 这是PHP应用的基础设施，它可以保证全局一致性，支持复杂数据结构，并且易于维护。
- 在热点数据上叠加本地缓存： 当发现Redis的压力比较大，或者某个具体的数据查询频率极高时，引入APCu作为L1，能大幅提升性能，减少内网开销。
- 不要滥用本地缓存： 如果你的应用是单体架构，单机部署，用本地缓存没问题，但如果是微服务或分布式集群，纯本地缓存会导致数据不一致，排查问题会非常痛苦。
- 注意PHP-FPM的生命周期： 普通PHP-FPM环境下，千万不要尝试用静态变量做长期缓存（它会随请求结束而释放），如果想要有效使用本地缓存，请务必安装APCu扩展，或者使用Swoole/Workerman常驻内存模式。
核心总结： 本地缓存是“快钱”（快但不稳定），分布式缓存是“金库”（稳定但有点门槛），高并发系统，金库”存长时间热点数据，“快钱”兜底极短的瞬时高并发。
