ThinkPHP高并发缓存必须显式调优Redis参数、原子化读写、防护穿透、双删多级缓存并规范键名：timeout设3秒、persistent开启、select指定库、serialize用igbinary；禁用if-get-set三步操作，改用Cache::remember或带EX的set；热点TTL加随机抖动；APCu与Redis需手动双删同步；键名用冒号分层+统一prefix+参数排序md5。
ThinkPHP 在高并发场景下，缓存不是“开了就行”，而是必须用对驱动、配对参数、写对逻辑——否则 Redis 反而成为瓶颈或数据不一致的源头。
Redis 驱动配置必须显式调优，不能只改 default
把 'default' => 'redis' 往 config/cache.php 里一塞就以为搞定，是线上缓存失效、连接超时、CPU 打满的常见起点。关键参数必须逐项确认：
-
timeout必须设为非 0 值（如3），默认0是无限等待，一个慢请求会拖垮整个连接池 -
persistent开启（设为true），否则每次请求都重建 TCP 连接，QPS 上千时 handshake 成最大开销 -
select显式指定库号（如1），避免和 session 或其他业务共用db 0导致误清 -
serialize推荐设为igbinary（需 PHP 已装扩展），比默认serialize内存占用低 30%，反序列化更快
缓存读写必须原子化，禁止三步操作
下面这种写法在并发下极易出错：
if (!$data = Cache::get($key)) {
$data = Db::find($id);
Cache::set($key, $data, 3600);
}
问题在于：中间步骤失败（比如 DB 查询异常）会导致 key 永久空置；set 和 expire 分离，可能留下永不过期的脏缓存。正确做法是：
立即学习“PHP免费学习笔记（深入）”；
- 一律用
Cache::set($key, $value, ['EX' => $ttl])或Cache::remember($key, $ttl, function() { ... })，保证写入+过期原子完成 - 缓存穿透防护：查不到时写入
"__MISS__"并设短 TTL（如60），避免恶意请求反复打穿 DB - 热点 key 的 TTL 必须加随机抖动，例如
$ttl = 3600 + rand(1, 300)，防止整点集体失效引发雪崩
多级缓存要手动同步，TP 不自动维护一致性
启用 APCu + Redis 双层缓存后，TP 不会自动帮你删两级。一旦数据变更，只删 Redis 而漏掉 APCu，后续请求仍从本地内存拿到旧值。
- 更新数据时，必须显式双删：
Cache::store('apcu')->delete($key)+Cache::store('redis')->delete($key) - APCu 适合存静态字典、配置项，设
0永不过期；但千万别用来存用户会话——进程间不共享，且无淘汰策略易 OOM - 读取时优先走 APCu，未命中再穿透到 Redis，不能反着来（否则失去一级缓存意义）
高并发下 Redis 键设计直接影响性能与可维护性
键名不是拼出来就行，混乱命名会导致哈希槽倾斜、批量操作失效、运维排查困难。
- 层级用冒号分隔，如
user:profile:123、seckill:stock_count:1001，禁用user123_profile类无结构命名 - 全局统一
prefix（如tp8:），配置中设'prefix' => 'tp8:'，别靠手拼，避免遗漏 - 带参数的 key（如分页、筛选）必须标准化：URL 参数按 key 字典序排序后再
md5，确保相同语义请求命中同一缓存 - 绝对禁止原始用户输入（如 nickname、email）直接作 key 名，必须
urlencode或sha256清洗，防控制字符注入或 key 冲突
真正卡住高并发的，往往不是 Redis 本身，而是缓存键没隔离、连接没复用、读写没原子、多级没同步——这些细节不抠清楚，加再多机器也扛不住流量洪峰。
