🚀 征服電商高併發面試：PHP + MySQL + AWS 的資深工程師實戰指南

如果你想在高併發、高交易量的電商平台擔任核心職位，面試官關注的不是你是否會寫程式，而是你能否設計並維護一個永不宕機、數據精確、彈性擴展的系統。

以下是針對 PHP + MySQL + AWS 堆疊的電商系統，我整理的終極面試陷阱與理想回答。

🧱 架構與系統設計：從 0 到 1000 TPS

核心問題	架構師的實戰回答與權衡
設計水平擴展的 RESTful API	核心：Stateless (無狀態)。 應用服務層必須是無狀態的，以便 Auto Scaling Group 可以隨意增減實例。Session： 使用 JWT (Token) 或將 Session 存儲到 Redis/Memcached。路由： 透過 ALB/NLB 進行負載平衡，並配置 Cache-Control 減少負載。
處理高併發下的資料一致性	交易系統對一致性要求高，但純粹的強一致性會犧牲性能。策略： 1. 資料庫： 在核心交易（如庫存檢查）使用 SELECT ... FOR UPDATE (悲觀鎖) 鎖定特定行。2. 分散式鎖： 跨服務操作或避免重複提交時，使用 Redis Redlock 確保原子性。3. 權衡： 非核心流程可接受最終一致性 (Eventual Consistency)，如訂單狀態更新。
設計每秒上千筆訂單的交易系統	分流與異步化。 1. 節流/排隊： API Gateway 進行 Rate Limiting；訂單請求先進入 SQS/Kafka 佇列（削峰填谷）。2. 核心交易： 後端 Worker 非同步處理佇列中的請求。3. 擴展： 根據 Sharding Key (如 User ID, Order ID)，對 MySQL 進行垂直/水平分區。4. 去重： 在寫入訂單前，檢查冪等性 Token (Idempotency Key)，防止佇列重試或用戶重複提交。
商品庫存扣減機制 (防超賣)	避免鎖住整個庫存表。 1. 最佳策略： 原子性更新。 使用單條 SQL 語句：UPDATE inventory SET stock = stock - N WHERE product_id = ? AND stock >= N。這依賴 MySQL 的事務隔離級別和行鎖，效率極高。2. 輔助策略： 高併發場景可引入 Redis 作為預扣減層，使用 Lua 腳本確保檢查與扣減的原子性，但最終仍需與 DB 進行異步同步。

---

🧠 資料庫設計與效能優化 (MySQL)

核心問題	實戰回答與權衡
高效能的訂單與庫存資料表設計	1. 庫存表 (Inventory)： 欄位極簡化 (ID, 產品ID, 剩餘數量)，保證高寫入性能；僅在 product_id 上加索引。2. 訂單表 (Orders)： 根據業務需求（如時間、用戶 ID）進行 Partitioning。3. 熱/冷資料分離： 僅保留 90 天內活躍資料在主庫；歷史訂單透過 ETL 流程 歸檔到 RDS Read Replica 或 S3/Redshift。
如何避免慢查詢？	流程化診斷。 1. 監控： 啟用 慢查詢日誌 與 Performance Schema。2. 診斷： 對 Top N 查詢使用 EXPLAIN ANALYZE (MySQL 8+) 分析執行計畫。3. 優化： 優先使用 覆蓋索引 (Covering Index) (索引包含所有查詢所需欄位，無需回表)；重寫複雜 Join 或避免 N+1 查詢。
高寫入量下，如何避免鎖競爭與死鎖？	1. 鎖順序： 嚴格遵循統一的鎖定順序（例如，總是先鎖定 ID 小的行）以預防死鎖。2. 鎖粒度： 盡量使用 行鎖 避免表鎖。3. 短事務： 保持事務極短，在 PHP 應用層儘快提交/回滾。4. 異步： 將非核心寫入轉移到 非同步佇列，減少主庫的即時寫入壓力。
MySQL 的 replication 模式有哪些？如何選擇？	模式選擇： 1. Row-based Replication (RBR)： 業界首選。精確性最高，避免 SBR 的非確定性問題。2. Mixed Replication (MBR)： 預設選項，但複雜度高。同步策略： 半同步複製 (Semi-Sync) 是高可用架構的基礎。它保證至少有一個 Replica 收到 Binlog 後才提交事務，兼顧性能與 RPO (Recovery Point Objective)。

---

⚙️ PHP 實作與效能 (PHP Performance & Best Practices)

核心問題	實戰回答與權衡
如何在 PHP 中實作高效能的 API	1. 優化執行環境： 確保啟用 OPCache；配置 PHP-FPM 的 Worker 數量與閒置策略。2. 架構： 使用 PSR-7/15 標準；利用 Middleware 處理請求生命週期（如身份驗證、Rate Limiting）。3. 進階： 考慮在特定性能瓶頸服務導入 Swoole/RoadRunner 等常駐記憶體模型，以消除 PHP 啟動和框架初始化的成本。
高併發下的 Session 管理	1. 集中式 Session： 必須將 Session 從檔案系統遷移到 Redis (作為 Session Handler)。2. 無狀態： 推薦使用 JWT (JSON Web Tokens)。JWT 存儲於客戶端，無須服務器存儲 Session 狀態，極大地提升了水平擴展性。3. 陷阱： 避免使用 Sticky Session，它限制了負載平衡的效率。
如何在 PHP 中實作 Rate Limiting	演算法與實作： 使用 Redis 實現 計數器算法 (Fixed Window) 或 令牌桶 (Token Bucket) 算法。實作： 使用 Redis 的 INCR 和 EXPIRE 命令，並透過 Lua 腳本 確保檢查與計數的原子性，然後將邏輯包裝成 PSR-15 Middleware 進行集中處理。
如何避免 PHP 中的記憶體洩漏與高記憶體使用	1. 資料流： 處理大數據時使用 Generator (或 DB Cursor) 進行迭代，避免一次性將所有數據載入陣列。2. 結構優化： 對於定長數據，使用 SplFixedArray 代替標準 PHP array (Hash Table)，節省內存。3. 工具： 使用 Blackfire 或 Xdebug Profiler 定期分析並找出記憶體分配熱點。

---

☁️ AWS 雲端部署與可用性 (AWS Cloud & Resilience)

核心問題	實戰回答與權衡
AWS 上的高可用部署	高可用三件套： 1. 計算層 (PHP)： EC2 部署於 Multi-AZ，透過 ALB (Application Load Balancer) 負載平衡。Auto Scaling Group (ASG) 負責彈性擴展。2. 資料庫 (MySQL)： 採用 RDS Multi-AZ (主從同步複製) 確保高可用。3. 緩存 (Redis)： 使用 ElastiCache (Redis Multi-AZ) 確保緩存層也具備高可用。
處理 RDS 的 Failover 與資料一致性	1. Failover： RDS Multi-AZ 自動 Failover 到備用 AZ，DNS Endpoint 不變，但會產生 DNS TTL 延遲。2. 一致性： RDS Multi-AZ 採用同步複製，Failover 後資料一致性得到保證 (RPO $\approx 0$)。3. 讀擴展： 啟用 RDS Read Replica 處理讀取負載，但需處理複製延遲 (Replication Lag) 導致的最終一致性問題。
如何設計可自動擴展的 API 系統	ASG 策略： 設定 Auto Scaling Group (ASG)。指標： 不僅監控 CPU 利用率，更應關注業務相關指標，如 ALB 請求計數 (Request Count)、佇列深度 (SQS Queue Depth)，作為擴展/縮減的依據。部署： 優先使用 ECS/EKS (容器化) 以實現更細粒度的資源控制與更快的部署速度。
使用 AWS 服務處理非同步任務與事件	1. 任務佇列： 使用 SQS 作為標準佇列，後端 Worker (ECS/Lambda) 處理。2. 事件驅動： 使用 SNS 進行扇出廣播（例如：訂單成立事件），或使用 EventBridge 進行服務間的解耦與事件路由。3. 複雜流程： 對於跨多個服務的複雜、長時間運行的 Saga 模式，使用 Step Functions 進行協調。

---

🔐 安全性、穩定性與監控 (Security & Observability)

核心問題	實戰回答與權衡
保護 API 不被濫用或攻擊	多層防禦： 1. 身份驗證： 使用 OAuth2 或 API Key。2. 防 DDoS/SQLi： 啟用 AWS WAF (Web Application Firewall)。3. 流量控制： 在 API Gateway/ALB 或應用層實施 Rate Limiting。4. 最小權限： DB 帳號採用最小權限原則。
保護敏感資料	加密策略： 1. At-rest (靜態)： 啟用 RDS TDE (透明資料加密)，或使用 KMS 加密 EBS 卷。2. In-transit (傳輸)： 強制使用 TLS/SSL 連線。3. 欄位級： 對支付卡號等極敏感數據，在應用層進行欄位加密或令牌化 (Tokenization)，DB 只存儲密文。
如何設計災難復原與備援策略	3-2-1 原則： 1. 備份： RDS 自動快照 + 手動快照，保留至 S3。2. 跨區備援： 在另一個 Region 設置 RDS Cross-Region Read Replica 作為災難復原目標 (DR)。3. 自動化： 基礎設施使用 Terraform/CDK 進行 IaC (Infrastructure as Code)，確保能快速在異地重建整個環境。
監控與追蹤訂單流程	全鏈路可觀察性： 1. 指標： 使用 CloudWatch 監控基礎設施 (CPU, I/O)；導入 Prometheus/Grafana 監控業務指標 (QPS, 佇列深度, 庫存水位)。2. 追蹤： 導入 OpenTelemetry 或 AWS X-Ray，在 PHP 應用層生成 Trace ID，並將其傳遞到 DB、Redis 和佇列，實現全鏈路追蹤 (Distributed Tracing)。3. 日誌： 使用 CloudWatch Logs Insights 進行日誌關聯分析。

---

最終忠告： 永遠不要只給出單一技術方案。資深工程師的價值在於能夠根據 業務 SLA、流量預期和成本 進行技術權衡。