ThinkPHP本身不提供高可用或高并发能力，必须依赖外部架构：负载均衡+健康检查、Redis集群托管session/cache、MySQL主从+读写分离配置、runtime目录只读及外迁日志缓存、Nginx静态化与异步队列卸载非核心逻辑。
ThinkPHP 本身是单实例 MVC 框架，不自带高可用或高并发能力；它的缓存集成和并发应对效果，完全取决于你如何配置底层依赖、剥离状态、控制资源争用。MVC 分层只是组织代码的方式，真正扛住流量的是缓存选型、无状态设计、异步分流和外部架构协同。
缓存必须脱离文件驱动，强制走 Redis
默认的文件缓存（type => 'file'）在多实例下会因文件锁和路径隔离导致请求排队甚至缓存错乱。高并发场景下，所有缓存操作必须统一到共享存储：
- 在
config/cache.php中设'type' => 'redis'，并配好集群地址或哨兵节点，禁用单点 Redis - Session 同理：改
config/session.php的'type' => 'redis'，避免用户登录态在不同服务器间丢失 - 缓存 key 要带业务前缀和版本号，例如
product:detail:v3:10086，结构变更时可自然隔离旧数据 - 空值缓存必须设短过期（如 60 秒），防止缓存穿透；高频写场景慎用
Cache::set()循环，改用Redis::handler()->mset()批量写入
数据库不是瓶颈起点，而是放大器
TP 没有连接池，PDO 长连接复用需手动开启，但更关键的是减少无效连接和阻塞：
- 关闭调试模式：
app_debug = false，否则 trace 日志会严重拖慢响应 - 数据库配置中启用
PDO::ATTR_PERSISTENT => true，同时调大 MySQL 的wait_timeout - 避免全量开启读写分离，部署简单时设
'deploy' => 0更稳；真要分离，用中间件按路由或方法控制，而非全局开关 - 事务尽量短，
Db::transaction()内别做 HTTP 请求或 sleep；查前加Db::connect()->query('SELECT 1')探活，防断连残留
高并发 ≠ 全部压给 PHP，得靠分层卸载
ThinkPHP 是同步阻塞模型，100 并发就需 100 个 PHP-FPM worker。硬扛不现实，必须把非核心逻辑移出主流程：
立即学习“PHP免费学习笔记（深入）”；
- 日志写入改异步：用
think\log\driver\Socket或推到 Kafka/Redis List，避免磁盘 I/O 阻塞 - 邮件、短信、生成报表等任务扔进队列：配置
queue.php使用 Redis 驱动，用Queue::push()投递，独立消费者进程处理 - Nginx 层加静态化：对商品详情、文章页等低频更新内容，用
fastcgi_cache缓存整个响应体，绕过 PHP 解析 - 上传文件不能存
public/uploads/，必须走对象存储（如 OSS/COS），否则 LB 分发后图片 404
高可用不是配置项，是架构组合拳
单台服务器跑 TP，永远没有高可用。必须由外部组件补足缺失能力：
- Nginx upstream 必须配健康检查，比如
health_check interval=3 rise=2 fall=3，只看端口通不通等于没检查 - runtime 目录禁止写本地磁盘，设为只读；日志、缓存、session 全部外迁，确保任意实例宕机不影响其他节点
- MySQL 必须主从+自动故障转移（如 MHA 或 ProxySQL），TP 侧仅配
'hostname' => 'proxy.db.cluster'，不写死 IP - 所有实例共用同一套配置中心（如 Consul + Envoy），环境变量和运行时参数动态下发，避免配置漂移
