thinkphp 6.1 高可用测试核心是验证故障下自动恢复、降级与兜底能力，重点考察失效转移时效性、状态感知准确性、业务逻辑兜底可靠性，并需实测主库宕机熔断、多节点失联承接、网络分区降级、缓存雪崩容错及跨节点数据最终一致性。
测试 ThinkPHP 6.1 分布式集群的高可用能力，核心不是“跑通接口”，而是验证系统在节点故障、网络异常、数据不一致等真实压力场景下能否自动恢复、降级或维持基本服务。重点落在“失效转移是否及时”“状态感知是否准确”“业务逻辑是否兜底”三个层面。
模拟主库宕机，验证读写分离熔断与降级
ThinkPHP 默认不处理主库不可用时的自动切换。需主动触发故障并观察行为：
- 手动停止 MySQL 主库服务（
systemctl stop mysqld），保持从库正常运行 - 持续调用含写操作的接口（如订单创建、用户登录态更新），确认是否在合理超时（如3秒）后抛出可识别异常（如
DbException），而非长时间卡死或静默失败 - 立即发起只读请求（如商品列表、用户资料），验证是否自动路由至从库且响应正常；若从库存在延迟，检查是否启用延迟感知策略（如基于
Seconds_Behind_Master动态剔除滞后 > 500ms 的从库） - 主库恢复后，观察连接池是否自动重建连接、写流量是否平滑切回——不能依赖重启应用
压测多节点服务失联，检验负载均衡与会话一致性
集群高可用不仅看数据库，更要看应用层节点协同能力：
- 使用 Nginx 或 SLB 配置三台 ThinkPHP 应用服务器，启用 sticky session（IP hash 或 cookie 路由）
- 通过 JMeter 或 wrk 对 /api/user/profile 接口施加 2000 QPS，并随机 kill 其中一台节点进程
- 检查剩余节点是否承接全部流量（Nginx access.log 中各节点请求数趋近均等）、用户登录态是否未中断（session 存 Redis Cluster 且配置了
failover模式） - 特别验证文件上传类接口：若禁用本地存储，所有节点应能访问同一对象存储（如 OSS），避免因某节点挂掉导致“上传成功但无法查看”
构造网络分区与缓存雪崩，测试降级与容错链路
分布式系统最脆弱的环节常在外部依赖失效时：
- 用
tc工具对某台应用服务器注入 80% 丢包或 2s 延迟，观察调用 Redis Cluster 或 MySQL 从库的接口是否触发熔断（如 Hystrix 风格 fallback） - 清空 Redis 所有 key 后立刻并发请求首页（依赖缓存渲染），确认页面是否降级为直连数据库（哪怕稍慢），而非返回 500 或空白页
- 检查日志中是否有明确标记降级原因的记录（如
[DEGRADED] cache unavailable, fallback to db query），便于事后归因 - 若使用消息队列（如 RabbitMQ）解耦写操作，停掉 MQ 服务后，确认订单创建等关键流程是否转为本地事务+定时重试，而非直接丢弃
验证跨节点数据最终一致性边界
高可用不等于强一致，但必须清楚“不一致会持续多久、影响哪些操作”：
- 在节点 A 执行用户余额扣减（写主库），立即在节点 B 查询该用户余额（读从库），记录延迟时间；重复 100 次，统计 P95 延迟是否 ≤ 300ms
- 对强一致性要求高的场景（如支付结果查询），验证是否已通过
forceMaster()或 SQL 注释（如/*FORCE_MASTER*/ SELECT ...）强制走主库 - 检查数据库 binlog 复制状态和从库 relay log 是否积压，避免将“理论支持”误判为“线上可用”
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
