> [!NOTE]
> Tài liệu này là **Architecture Heritage** (Di sản kiến trúc). 
> Nó phản ánh quá trình thiết kế và ra quyết định. Để sử dụng API thực tế, hãy xem [API Reference](../01_Specs/THEUS_API_REFERENCE.md).

---

# 🛡️ Phân Tích Phản Biện: Optimistic Locking (Global CAS)

**Đối tượng thẩm định:** Cơ chế "Ai đến trước thắng trước" (Global CAS) trong `V3_ZeroCopy_Strategy.md`
**Skill:** Critical Analyzer (Phase 2 & 3)

---

## 1. 🔍 PHASE 2: PHÂN TÍCH ĐỘ PHỨC TẠP & CÁC KỊCH BẢN (COMPLEXITY & CASE ANALYSIS)

### A. Kịch bản Tiêu chuẩn (Model Case - Tranh chấp thấp)
*   **Mô tả:** 4 Workers chạy song song, cập nhật 4 key khác nhau (ví dụ: `camera`, `audio`, `lidar`, `status`) lệch thời gian.
*   **Kết quả:** Hoạt động hoàn hảo. `CAS(expected=v100)` thành công 99%. Hệ thống đạt tốc độ tối đa, không tốn tài nguyên cho Lock.

### B. Kịch bản Liên quan (Related Case - Tranh chấp vừa)
*   **Mô tả:** 2 Workers cập nhật cùng lúc. Worker A commit v101 thành công. Worker B fail, phải retry trên v101 -> commit v102.
*   **Kết quả:** Chấp nhận được. Worker B bị trễ vài mili-giây (latency), nhưng throughput tổng thể vẫn cao.

### C. Kịch bản Biên (Edge Case: Starvation - Đói tài nguyên)
*   **Mô tả:** Worker X (xử lý ảnh to, chậm 500ms) bắt đầu tính toán trên `v100`. Trong 500ms đó, các Worker nhỏ (nhanh) đã commit liên tục làm version nhảy lên `v150`.
*   **Hậu quả:** Worker X commit -> Fail -> Retry trên `v150`. Lại tính toán 500ms -> Version đã lên `v200`.
*   **Kết luận:** Worker X **KHÔNG BAO GIỜ** commit được (Livelock). Cơ chế này "ngây thơ" vì nó trừng phạt tác vụ chậm.

### D. Kịch bản Xung đột (Conflict Case: Thundering Herd - Hiệu ứng đám đông)
*   **Mô tả:** 100 Workers cùng đọc `v100` để xử lý.
*   **Hậu quả:** 1 người thắng (lên `v101`). 99 người còn lại **ĐỒNG LOẠT** thất bại. 99 người này cùng retry ngay lập tức. CPU tăng vọt (Spike) nhưng công việc hữu ích (Useful Work) gần như bằng 0.

---

## 2. 🛡️ PHASE 3: ĐÁNH GIÁ GIẢI PHÁP ĐỀ XUẤT (PROPOSED SOLUTIONS)

**Giải pháp Tổng thể:** Key-Level CAS + Exponential Backoff + Priority Ticket.

### 1. Giải pháp Cốt lõi (Core Resolution)
*   **Câu hỏi:** Giải pháp này có giải quyết dứt điểm vấn đề tranh chấp không? **Và quan trọng hơn, nó có làm hỏng hiệu năng song song (Parallelism Performance) không?**
*   **Phân tích Chi phí Hiệu năng (Runtime Cost Analysis):**
    *   **Overhead:** Việc chuyển từ check 1 biến `Global Int` sang check `HashMap<Key, Version>` tốn thêm khoảng **10-50ns** (nano giây) cho mỗi transaction. Đây là con số không đáng kể.
    *   **Parallelism Gain:** Nhờ chia nhỏ Lock theo Key (Fine-grained), Worker A (sửa `camera`) không bao giờ bị chặn bởi Worker B (sửa `audio`). Mức độ song song thực tế **TĂNG LÊN** gấp nhiều lần so với Global Lock.
*   **Kết luận:** Giải pháp **BẢO TOÀN** hiệu năng song song. Chi phí quản lý (Overhead) < 1% nhưng lợi ích giảm tranh chấp là 90%.

### 2. Khả năng Thích ứng (Adaptability)
*   **Kịch bản:** Tải dao động thất thường (lúc vắng, lúc đông).
*   **Cơ chế:** **Exponential Backoff** (`sleep(base * 2^retries)`).
*   **Đánh giá:** Khi hệ thống rảnh, Backoff = 0 -> Tốc độ tối đa. Khi hệ thống kẹt, Backoff tăng lên -> Tự động giảm tải để tránh sập. Hệ thống tự điều tiết như lò xo, rất linh hoạt.

### 3. Sự Bền bỉ (Resilience - Chống Starvation)
*   **Rủi ro:** Worker chậm vẫn bị đói.
*   **Cơ chế:** **Priority Escalation**. Nếu Worker fail quá 5 lần, nó được cấp "Vé VIP". Hệ thống sẽ tạm dừng (Block) các request mới trong 1ms để Worker VIP ưu tiên commit.
*   **Đánh giá:** Chấp nhận hy sinh throughput trong 1ms (ngắn hạn) để cứu Worker chậm (lợi ích dài hạn). Đảm bảo tính công bằng (Fairness).

### 4. Kế hoạch Dự phòng (Fallback - Chống Sập)
*   **Rủi ro:** Tranh chấp cực độ (1000 workers cùng ghi 1 key).
*   **Cơ chế:** Chuyển từ **Parallel Write** sang **Serialized Queue (Actor Model)**. Tất cả request ghi được đẩy vào hàng đợi và xử lý tuần tự bởi 1 Thread.
*   **Đánh giá:** "Chậm mà chắc". Khi quá tải, xử lý tuần tự (Serial) thực ra nhanh hơn xử lý song song mà toàn Fail (Livelock). Đây là van an toàn cuối cùng.
