解读

国内互联网面试中，这道题表面问“技术选型”，实则考察候选人能否把“业务场景、性能指标、研发成本、运维复杂度”四维因素量化后做权衡。PHP 生态里同步指“请求=>FPM进程=>即时返回”，队列事件驱动指“请求=>写入消息=>消费进程异步处理”。面试官想听的不是“哪个更好”，而是“什么场景选哪个、为什么、怎么落地、风险在哪”。

知识点

1. 同步模型：PHP-FPM 同步阻塞，RTT≈网络+SQL+CPU，适合读多写少、P99<200 ms、可接受重试在客户端的场景。
2. 队列事件模型：利用 Redis/RabbitMQ/NSQ 把耗时逻辑异步化，削峰填谷，提高吞吐量，但引入消息丢失、重复消费、顺序性、幂等、监控、死信队列等复杂度。
3. 国内常用组件：
   • 队列：Laravel Queue + Horizon、Hyperf AMQP、EasySwoole Queue、阿里云 MNS/ONS、腾讯云 CMQ。
   • 事件总线：Hyperf Event Dispatcher、Laravel Event+Listener、Swoole Table+自定义事件。
4. 量化指标：
   • 接口耗时>500 ms 或下游吞吐<峰值QPS 的30 %，必须异步；
   • 业务允许最终一致性（订单状态、积分、短信），可队列；
   • 需要强一致性且耗时短（库存扣减、支付回调），同步+数据库事务+乐观锁，或同步+分布式事务（Seata、TCC）。
5. 成本维度：
   • 同步：FPM 水平扩容即可，云主机成本低，但突发流量瞬间打满 CPU，可能触发 502。
   • 队列：需额外维护消费进程、Supervisor、K8s HPA、消息积压告警，人力+云资源成本上升 20 %～40 %。
6. 失败策略：
   • 同步：立刻返回 4xx/5xx，客户端重试，用户体验差。
   • 队列：失败写入重试队列，按 2^n 退避，达到最大重试进死信，人工兜底。
7. 数据一致性补偿：
   • 本地消息表（MySQL 事务内写业务表+消息表，后台定时扫表重新投递）是 PHP 侧最落地的最终一致性方案，避免分布式事务对 GC 不友好问题。

答案

选型四步法：
第一步，看耗时。压测显示 P99>500 ms 或下游接口（如第三方短信、物流）RT 不可控，立即走队列；否则同步。
第二步，看一致性。若用户需“操作完立刻可见”且不能容忍延迟，如秒杀库存扣减，采用同步+悲观锁/乐观锁+短事务；若可接受秒级延迟，如发券、积分，用队列+幂等消费。
第三步，看流量。峰值 QPS 是日常 5 倍以上且持续<3 分钟，用队列削峰，避免 FPM 频繁扩容导致冷启动延时；若流量平稳，同步+OPcache+Redis 缓存更省成本。
第四步，看成本与团队。团队无 DevOps、无专职运维，优先同步+水平扩容；若已有 K8s、Prometheus、Laravel Horizon 经验，可引入队列，并配套监控告警：队列长度>5000 持续 2 分钟即短信告警，消费失败率>1 % 自动拉群。

落地示例：电商下单接口。

1. 同步部分：创建订单、扣库存写在同一事务，返回订单号，保证强一致。
2. 异步部分：事务内写本地消息表，事件“OrderCreated”由队列消费，异步发短信、更新搜索索引；消费逻辑加唯一索引防重复，失败重试 3 次后进死信，人工脚本每日处理。
3. 灰度开关：配置中心增加“async_event_enable”，一旦队列异常，秒级切回同步，降级发短信为“延迟 5 分钟批量任务”，保证核心下单链路基线可用。

拓展思考

1. 双写一致性：如果业务已用 Canal 监听 MySQL binlog，可对比“本地消息表”与“binlog 事件”做对账，发现漏消息后自动补推，实现 0 人工干预。
2. 队列选型与云厂商绑定：国内上云大势下，Redis Stream 与阿里云 Tair 兼容，但出云迁移成本高；面试可提“抽象队列驱动接口，业务只依赖 PSR-14，底层 Redis/RabbitMQ/ONS 可插拔”，体现可迁移意识。
3. Swoole 协程能否替代队列：协程可把 IO 等待让出 CPU，实现“同步编程、异步执行”，但 CPU 密集任务仍会阻塞协程，需结合 TaskWorker；高并发场景下仍建议业务层解耦队列，避免长连接内存泄漏。
4. Serverless 趋势：腾讯云 SCF 已支持 PHP 8.x，事件源为 API 网关时，同步冷启动 600 ms；若搭配 CMQ 触发器，可让消费逻辑也 Serverless，实现“同步+异步”全链路无服务器，面试提到此点可展示技术前瞻性。