## Case #1: 直接用資料庫 SUM 的滑動時間窗統計（基線做法）

### Problem Statement（問題陳述）
**業務場景**：電商網站每秒產生大量訂單，管理層希望即時查看「過去 60 秒/60 分鐘的成交金額」，並每秒更新。系統已有 WebAPI、Processing、DB 管線，要求在不打擾既有流程的前提下，於 Statistic 模組提供滑動視窗加總結果。
**技術挑戰**：在每秒大量新資料持續寫入時，用 SQL 每秒重新計算過去一段時間的 SUM，會因資料量成長、時間窗放大而導致效能崩潰。
**影響範圍**：DB CPU/IO 飆高、庫表鎖爭用、查詢延遲升高，導致即時指標延遲、其他交易受拖累。
**複雜度評級**：低

### Root Cause Analysis（根因分析）
**直接原因**：
1. 重複全量掃描：每秒對時間窗內資料做 SUM，運算量隨時間窗長度與資料成長線性上升。
2. 資料無封存：orders 表歷史資料持續累積，WHERE 篩選成本上升。
3. 無降階統計：未做預聚合或增量維護，造成重複計算。
**深層原因**：
- 架構層面：將即時計算耦合在交易 DB 上，缺乏分析/查詢與交易分離。
- 技術層面：僅依賴 SQL 聚合，缺少緩存、增量與時間窗資料結構。
- 流程層面：無資料生命週期管理（歸檔/分區），缺少效能基準與壓測流程。

### Solution Design（解決方案設計）
**解決策略**：在現有 DB 上快速落地，於時間欄位建索引，透過單條 SQL 以 BETWEEN 篩選 [now-60s, now]，立即產出統計。用此作為基線/對照組，為後續優化提供實測標杆。

**實施步驟**：
1. 建表與索引
- 實作細節：建立 orders(time, amount) 並對 time 建索引。
- 所需資源：SQL Server/MSSQL LocalDB
- 預估時間：0.5 天

2. 實作 InDatabaseEngine
- 實作細節：CreateOrders 插入資料；StatisticResult 執行 SUM(amount) WHERE time BETWEEN now-60s AND now。
- 所需資源：.NET 6+/Dapper
- 預估時間：0.5 天

3. 功能與負載驗證
- 實作細節：用測試程式每秒灌單、每 200ms 取統計，觀察數值穩定性與吞吐。
- 所需資源：測試主控台
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```sql
-- Schema
CREATE TABLE [dbo].[orders]
(
  [Id] UNIQUEIDENTIFIER NOT NULL PRIMARY KEY DEFAULT newid(), 
  [time] DATETIME NOT NULL DEFAULT getdate(), 
  [amount] MONEY NOT NULL
);
GO
CREATE INDEX [IX_orders_Column] ON [dbo].[orders] ([time]);

-- 查詢滑動窗
SELECT SUM(amount) 
FROM [orders]
WHERE time BETWEEN DATEADD(second, -60, GETDATE()) AND GETDATE();

## Case #2: 以 Queue + Buffer 的 In-Memory 滑動視窗（O(1) 解法）

### Problem Statement（問題陳述）
**業務場景**：需在單機服務中即時給出「最後 60 秒」加總，並承受極高 TPS（單機每秒百萬級事件），同時嚴格控制資源占用。
**技術挑戰**：要同時滿足高吞吐、低延遲、低資源與正確移除窗口外舊資料；傳統 SQL/掃描式方法無法滿足。
**影響範圍**：統計延遲或錯誤將直接影響營運決策與下游報表。
**複雜度評級**：中

### Root Cause Analysis（根因分析）
**直接原因**：
1. 重複掃描：每次查詢都掃描窗口資料，時間複雜度高。
2. 視窗剔除困難：準確移除超時資料難以做到 O(1)。
3. 記憶體與 GC 壓力：若用細粒度明細緩存，會造成高 GC。
**深層原因**：
- 架構層面：缺乏在應用層的預聚合/增量維護。
- 技術層面：未正確選擇資料結構（Queue/FIFO）。
- 流程層面：未設置性能基準與 O(1) 設計目標。

### Solution Design（解決方案設計）
**解決策略**：採用時間分桶（bucket）+ FIFO Queue 保存每個 interval 的聚合值，另以 buffer 累加當前間隔的數值，由背景 worker 週期性把 buffer 交換入隊、更新總和、並逐出過期桶；查詢時回傳 statistic + buffer，達成 O(1) 查詢與更新。

**實施步驟**：
1. 設計 bucket 與 Queue 結構
- 實作細節：每 interval 產生一個 bucket（_interval=0.1s ⇒ 600/分鐘），Queue 保存每個 bucket 的總額與時間。
- 所需資源：.NET/C#
- 預估時間：0.5 天

2. 背景 worker 與原子交換
- 實作細節：定時 Interlocked.Exchange(buffer,0) 取值入隊，累加 statistic，並 while 逐出 time < now-period 的桶。
- 所需資源：.NET Threading
- 預估時間：0.5 天

3. 讀寫 API
- 實作細節：CreateOrders 使用 Interlocked.Add；StatisticResult 回傳 statistic + buffer。
- 所需資源：.NET
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```csharp
public class InMemoryEngine : EngineBase
{
    private readonly TimeSpan _period = TimeSpan.FromMinutes(1);
    private readonly TimeSpan _interval = TimeSpan.FromSeconds(0.1);
    private readonly Queue<QueueItem> _queue = new();
    private int _statistic_result = 0;
    private int _buffer = 0;

    public InMemoryEngine()
    {
        Task.Run(() => {
            while (true) { Task.Delay(_interval).Wait(); _worker(); }
        });
    }

    public override int StatisticResult => _statistic_result + _buffer;
    public override int CreateOrders(int amount) => Interlocked.Add(ref _buffer, amount);

    private void _worker()
    {
        int buf = Interlocked.Exchange(ref _buffer, 0);
        _queue.Enqueue(new QueueItem { _count = buf, _time = DateTime.Now });
        _statistic_result += buf;

        while (true)
        {
            if (_queue.Peek()._time >= DateTime.Now - _period) break;
            var dq = _queue.Dequeue();
            _statistic_result -= dq._count;
        }
    }
    private class QueueItem { public int _count; public DateTime _time; }
}

## Case #3: 用 Interlocked 消除多執行緒統計遺失（3.97% → 0%）

### Problem Statement（問題陳述）
**業務場景**：在高併發入單（多執行緒/多 Task）下，統計引擎要保持精準；未妥善處理臨界區會出現「金額被吃掉」的現象。
**技術挑戰**：CreateOrders 與 worker 會同時存取/修改 buffer 與 statistic，要保證不可分割與順序一致。
**影響範圍**：統計值偏小，報表失真，造成商業決策誤判。
**複雜度評級**：中

### Root Cause Analysis（根因分析）
**直接原因**：
1. 非原子遞增：多執行緒 buffer += amount 產生 lost update。
2. 非原子交換：讀取 buffer 再清零，中間被插入寫入。
3. 無同步策略：未使用 lock/原子操作。
**深層原因**：
- 架構層面：未設計共享狀態的安全存取策略。
- 技術層面：缺乏對原子操作/記憶體模型理解。
- 流程層面：缺少併發場景的自動化驗證。

### Solution Design（解決方案設計）
**解決策略**：以 .NET Interlocked.Add 與 Interlocked.Exchange 保障加總與交換不可分割；以兩版本互驗測出差異，確保 0% 偏差。

**實施步驟**：
1. 導入 Interlocked
- 實作細節：CreateOrders 使用 Interlocked.Add；worker 使用 Interlocked.Exchange 清空 buffer 且取舊值。
- 所需資源：.NET Threading
- 預估時間：0.5 天

2. 雙版本驗證
- 實作細節：建立 use_lock=true/false 兩個 InMemoryEngine，同源灌流，對比結果。
- 所需資源：測試主控台
- 預估時間：0.5 天

3. 壓測與報告
- 實作細節：20 執行緒連續 10 秒灌流，記錄偏差百分比。
- 所需資源：.NET
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```csharp
public override int CreateOrders(int amount)
    => Interlocked.Add(ref _buffer, amount);

int buffer_value = Interlocked.Exchange(ref _buffer, 0); // 取舊值且歸零

## Case #4: 以 Redis 實作分散式滑動視窗（Lists + INCRBY/DECRBY/GETSET）

### Problem Statement（問題陳述）
**業務場景**：要把即時統計從單機擴展為分散式，支援多個應用節點共同寫入，並實現高可用；但仍需維持時間窗剔除與增量維護的 O(1) 優勢。
**技術挑戰**：分散式共享狀態需原子操作；自研分散式鎖複雜且昂貴。
**影響範圍**：統計正確性、可用性與延遲直接影響整體系統 SLA。
**複雜度評級**：高

### Root Cause Analysis（根因分析）
**直接原因**：
1. 多節點共享變數：buffer/statistic/queue 難以一致。
2. 競態與重入：多 worker 容易重複剔除、重複加總。
3. 自研鎖風險高：可靠的分散式鎖實作困難。
**深層原因**：
- 架構層面：缺少共享狀態的外部一致存儲。
- 技術層面：不熟悉存儲層原子指令。
- 流程層面：未規劃單工 worker 與多 producer 協作。

### Solution Design（解決方案設計）
**解決策略**：將 queue/buffer/statistic 狀態遷至 Redis；使用 Lists 當 Queue，StringIncrement/Decrement 做總和，GetSet 做原子交換；僅保留單個 worker 處理搬運與逐出，其餘節點僅做寫入與查詢。

**實施步驟**：
1. 資料結構映射
- 實作細節：queue ⇒ Redis List；buffer/statistic ⇒ String；QueueItem 自行序列化。
- 所需資源：Redis、StackExchange.Redis
- 預估時間：0.5 天

2. 原子操作實作
- 實作細節：INCRBY/DECRBY/GETSET 替代 lock；ListRightPush/LeftPop 管理 FIFO。
- 所需資源：Redis
- 預估時間：0.5 天

3. 單工 worker 佈署
- 實作細節：一個節點啟動 worker，其餘關閉 worker（只生產/查詢）。
- 所需資源：多個應用實例
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```csharp
public class InRedisEngine : EngineBase
{
    private IDatabase redis = ConnectionMultiplexer.Connect("host:6379").GetDatabase();
    private readonly TimeSpan _period = TimeSpan.FromMinutes(1);
    private readonly TimeSpan _interval = TimeSpan.FromSeconds(0.1);

    public InRedisEngine(bool start_worker = true)
    {
        if (start_worker)
            Task.Run(() => { while (true) { Task.Delay(_interval).Wait(); _worker(); } });
    }
    public override int StatisticResult =>
        (int)redis.StringGet("statistic") + (int)redis.StringGet("buffer");
    public override int CreateOrders(int amount) =>
        (int)redis.StringIncrement("buffer", amount);

    private void _worker()
    {
        int buf = (int)redis.StringGetSet("buffer", 0);
        redis.ListRightPush("queue", QueueItem.Encode(new QueueItem{ _count=buf, _time=DateTime.Now }));
        redis.StringIncrement("statistic", buf);

        while (true)
        {
            var head = QueueItem.Decode((string)redis.ListGetByIndex("queue", 0));
            if (head._time >= DateTime.Now - _period) break;
            var dq = QueueItem.Decode((string)redis.ListLeftPop("queue"));
            redis.StringDecrement("statistic", dq._count);
        }
    }
    public class QueueItem
    {
        public int _count; public DateTime _time;
        public static string Encode(QueueItem v) => $"{v._count},{(v._time - DateTime.MinValue).TotalMilliseconds}";
        public static QueueItem Decode(string s){ var a=s.Split(','); return new(){ _count=int.Parse(a[0]), _time=DateTime.MinValue+TimeSpan.FromMilliseconds(double.Parse(a[1]))}; }
    }
}

## Case #5: 單工 Worker 的分散式協作模式（避免重複逐出/加總）

### Problem Statement（問題陳述）
**業務場景**：多個應用實例同時寫入共享 Redis 狀態，若每個實例都啟動 worker，會出現重複逐出或統計錯誤。
**技術挑戰**：如何在無分散式鎖的情況下，保證時間窗逐出只被執行一次。
**影響範圍**：重複扣減或重複入隊導致統計錯誤。
**複雜度評級**：中

### Root Cause Analysis（根因分析）
**直接原因**：
1. 多 worker 並行執行相同逐出邏輯。
2. 操作非冪等：重複執行造成數據錯誤。
3. 無共識/選主：無法指定唯一執行者。
**深層原因**：
- 架構層面：缺乏角色分工（producer/worker）。
- 技術層面：缺失冪等/去重設計。
- 流程層面：佈署策略未定義單工約束。

### Solution Design（解決方案設計）
**解決策略**：應用層配置只有 1 個實例啟動 worker，其餘實例以 producer 身分只負責寫入與讀取；藉此避開分散式鎖，引入最小變動即可正確運行。

**實施步驟**：
1. 啟動參數控制
- 實作細節：InRedisEngine(start_worker=false) 參數化。
- 所需資源：應用程式設定
- 預估時間：0.25 天

2. 佈署策略
- 實作細節：CI/CD/容器排程指定唯一 worker 節點。
- 所需資源：部署平台
- 預估時間：0.5 天

3. 監控與切換
- 實作細節：worker 健康檢查，故障時手動/自動切換。
- 所需資源：監控/告警
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```csharp
// 啟動時注入 start_worker 參數
var engine = new InRedisEngine(start_worker: Environment.Get("ROLE") == "worker");

## Case #6: 時間分桶 + 週期搬運（Buffer→Queue→Evict）工作流程

### Problem Statement（問題陳述）
**業務場景**：連續資料流入無間斷，須以固定粒度將資料匯總入桶，並定時移除超時桶保證視窗正確。
**技術挑戰**：如何在不鎖全域的情況下，持續搬運並保持 O(1) 更新時間。
**影響範圍**：若搬運/逐出錯誤，統計會累積誤差。
**複雜度評級**：中

### Root Cause Analysis（根因分析）
**直接原因**：
1. 未分桶導致資料量巨大難以搬運。
2. 未原子交換導致部分資料丟失。
3. 逐出條件錯誤導致視窗擠壓或膨脹。
**深層原因**：
- 架構層面：無明確 ETL/worker 管線。
- 技術層面：未合理選擇時間粒度。
- 流程層面：缺乏暖機與邊界容錯策略。

### Solution Design（解決方案設計）
**解決策略**：採用固定 _interval 分桶，worker 每 _interval 取出 buffer（原子交換）、入隊、累加總和，並用 while 持續檢查隊首是否超窗，超窗則出隊並扣減。

**實施步驟**：
1. 設計分桶與粒度
- 實作細節：_period=60s，_interval=0.1s ⇒ 600 桶。
- 所需資源：.NET
- 預估時間：0.25 天

2. 原子搬運
- 實作細節：Exchange 讀/清 buffer；入隊並加總；迴圈逐出。
- 所需資源：Threading
- 預估時間：0.25 天

3. 查詢合成
- 實作細節：讀取 statistic + buffer 即為當前視窗值。
- 所需資源：.NET
- 預估時間：0.25 天

**關鍵程式碼/設定**：
```csharp
int buf = Interlocked.Exchange(ref _buffer, 0);
_queue.Enqueue(new QueueItem { _count = buf, _time = DateTime.Now });
_statistic_result += buf;
while (_queue.Peek()._time < DateTime.Now - _period) {
    var dq = _queue.Dequeue();
    _statistic_result -= dq._count;
}

## Case #7: 兩版本互驗（慢版作準 vs 快版受測）抓出一致性問題

### Problem Statement（問題陳述）
**業務場景**：需要一套可重複的驗證方法，確保快版（最佳化）統計在各種併發壓力下正確。
**技術挑戰**：單一實作難以自證正確；需要參考實作作為地面實況（ground truth）。
**影響範圍**：未驗證的最佳化可能帶入隱性誤差。
**複雜度評級**：中

### Root Cause Analysis（根因分析）
**直接原因**：
1. 測試僅看單值（1770）無法覆蓋併發問題。
2. 缺少對照組使誤差難以量化。
3. 無自動化量化誤差比率。
**深層原因**：
- 架構層面：缺少測試口徑與基準。
- 技術層面：未建立可比較的雙實作。
- 流程層面：無長時間/多執行緒壓測制度。

### Solution Design（解決方案設計）
**解決策略**：同時跑兩個引擎（如 InMemory vs InDatabase / InRedis），用同一資料流灌入，定期比對結果差距與誤差率，作為迭代基礎。

**實施步驟**：
1. 建立雙引擎管道
- 實作細節：兩引擎共用產生器（多執行緒灌流）。
- 所需資源：.NET
- 預估時間：0.5 天

2. 收斂誤差
- 實作細節：若誤差>0，定位到原子性/逐出/粒度等原因。
- 所需資源：Profiler/Logging
- 預估時間：1 天

3. 報告化
- 實作細節：輸出誤差百分比、吞吐。
- 所需資源：Console/Report
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```csharp
// 省略細節：雙引擎同源灌流、10 秒後比較
Console.WriteLine($"engine #1: {e1.StatisticResult} ({e1.GetType().Name})");
Console.WriteLine($"engine #2: {e2.StatisticResult} ({e2.GetType().Name})");
Console.WriteLine($"compare: {e1.StatisticResult == e2.StatisticResult}, diff: {diff:P2}");

## Case #8: 效能壓測腳本（LoadTest）與結果解讀

### Problem Statement（問題陳述）
**業務場景**：需要客觀比較三種方案（DB、InMemory、Redis）的吞吐能力，支持架構選型。
**技術挑戰**：建立一致可重複的壓測方法，並避免測試本身成為瓶頸。
**影響範圍**：錯誤結論會導致不當投資與運維成本。
**複雜度評級**：中

### Root Cause Analysis（根因分析）
**直接原因**：
1. 無統一壓測腳本與參數。
2. 無一致硬體/環境基準。
3. 未量化 orders/msec 指標。
**深層原因**：
- 架構層面：缺失性能基線流程。
- 技術層面：測試工具缺乏。
- 流程層面：未將效能測試納入決策。

### Solution Design（解決方案設計）
**解決策略**：以相同程式碼模板（20 執行緒、連續 10 秒灌入 CreateOrders(1)），對單一引擎分別測試，取得 orders/msec 指標，對照硬體環境。

**實施步驟**：
1. 撰寫壓測方法
- 實作細節：固定執行緒數、時間長度、負載型態。
- 所需資源：.NET
- 預估時間：0.5 天

2. 固定環境
- 實作細節：相同硬體/OS/Redis/SQL 版本。
- 所需資源：實驗室主機
- 預估時間：0.5 天

3. 統計輸出
- 實作細節：輸出總筆數與 orders/msec。
- 所需資源：Console
- 預估時間：0.25 天

**關鍵程式碼/設定**：
```csharp
static void LoadTest()
{
    EngineBase e1 = new InRedisEngine(); // 依序換成各引擎
    bool stop = false;
    int thread_count = 20;
    var threads = new List<Thread>();
    for (int i = 0; i < thread_count; i++)
    {
        var t = new Thread(() => { while (!stop) { Thread.Sleep(0); e1.CreateOrders(1); } });
        threads.Add(t); t.Start();
    }
    var duration = TimeSpan.FromSeconds(10);
    Thread.Sleep(duration); stop = true; threads.ForEach(t => t.Join());
    Console.WriteLine($"performance: {e1.StatisticResult / duration.TotalMilliseconds} orders/msec");
}

## Case #9: 從 O(N) 掃描到 O(1) 增量維護（數量級優化）

### Problem Statement（問題陳述）
**業務場景**：即時查詢每秒觸發，交易流量極大，必須讓每次查詢/更新成本固定，否則會被時間窗與資料量拖垮。
**技術挑戰**：避免每次查詢掃描整個時間窗內的所有明細。
**影響範圍**：吞吐與延遲直接取決於時間複雜度。
**複雜度評級**：中

### Root Cause Analysis（根因分析）
**直接原因**：
1. SQL SUM 每次都是 O(K)（K=窗內筆數）。
2. 時間窗越長，掃描越慢。
3. 筆數越高，IO/CPU/鎖競爭加劇。
**深層原因**：
- 架構層面：未將聚合與存取分離。
- 技術層面：未使用 Queue/分桶 O(1) 方案。
- 流程層面：未設定演算法複雜度目標。

### Solution Design（解決方案設計）
**解決策略**：採用 Case #2 的分桶/Queue 與統計總和增量維護，查詢時 O(1) 讀取 statistic + buffer；每個 interval O(1) 搬運一次。

**實施步驟**：
1. 明確複雜度目標
- 實作細節：查詢/更新/逐出皆盡量 O(1)。
- 所需資源：設計評審
- 預估時間：0.25 天

2. 實作分桶增量
- 實作細節：Queue + buffer + statistic。
- 所需資源：.NET
- 預估時間：0.5 天

3. 驗證與對比
- 實作細節：與 SQL 方案壓測對比 orders/msec。
- 所需資源：壓測工具
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```csharp
public override int StatisticResult => _statistic_result + _buffer; // O(1)
public override int CreateOrders(int amount) => Interlocked.Add(ref _buffer, amount); // O(1)

## Case #10: 邊界時間抖動的誤差管理與驗證

### Problem Statement（問題陳述）
**業務場景**：時間窗邊界上，部分事件因時間誤差可能落入或落出視窗，導致瞬時值偶有偏差。
**技術挑戰**：如何驗證與容忍誤差，避免誤判為功能錯誤。
**影響範圍**：監控/自動化測試穩定性。
**複雜度評級**：低

### Root Cause Analysis（根因分析）
**直接原因**：
1. 取樣時刻與事件時間不一致。
2. 系統延遲與 timer 精度限制。
3. 事件時間戳不穩定（寫入延遲）。
**深層原因**：
- 架構層面：未定義時間語義（event time vs processing time）。
- 技術層面：timer 與等待策略不嚴謹。
- 流程層面：測試未設暖機與容忍區間。

### Solution Design（解決方案設計）
**解決策略**：在測試中加入暖機（>1 視窗長度）後再判定；觀察數值落在期望值（1770）附近時視為可接受；將斷言調整為人工/寬容比對。

**實施步驟**：
1. 暖機期
- 實作細節：啟動後等待滿一個視窗長度再開始判定。
- 所需資源：測試調整
- 預估時間：0.25 天

2. 寬容比對
- 實作細節：允許小範圍偏差，不做硬性 assert。
- 所需資源：測試程式
- 預估時間：0.25 天

3. 記錄與觀察
- 實作細節：列印當前/預期，人工核對。
- 所需資源：Console 日誌
- 預估時間：0.25 天

**關鍵程式碼/設定**：
```csharp
// 測試輸出（略）：statistic: {current}, expected: 1770, test: {current == expected}
// 實作上避免硬性 Assert，觀察邊界抖動。

## Case #11: Orders 表設計與時間索引支援區間查詢

### Problem Statement（問題陳述）
**業務場景**：在 DB 方案中，需要讓「時間區間」過濾和 SUM 儘可能高效。
**技術挑戰**：時間序列表會快速長大，掃描與 I/O 成本高。
**影響範圍**：查詢延遲、交易衝擊。
**複雜度評級**：低

### Root Cause Analysis（根因分析）
**直接原因**：
1. 無索引導致全表掃描。
2. 單表累積無封存。
3. 金額型態與聚合成本。
**深層原因**：
- 架構層面：OLTP/OLAP 未分離。
- 技術層面：索引策略缺失。
- 流程層面：未建立歸檔/分區週期。

### Solution Design（解決方案設計）
**解決策略**：在 time 欄位建立索引，保證 WHERE time BETWEEN 的篩選走索引；同時保留此為基線，推導轉向預聚合的必要性。

**實施步驟**：
1. 建立索引
- 實作細節：對 [time] 建非聚集索引。
- 所需資源：SQL Server
- 預估時間：0.25 天

2. 查詢優化
- 實作細節：確保查詢符合索引使用（避免函數包裹 time 欄位）。
- 所需資源：查詢分析器
- 預估時間：0.25 天

3. 建立基準
- 實作細節：跑壓測取得 orders/msec 基線。
- 所需資源：測試腳本
- 預估時間：0.25 天

**關鍵程式碼/設定**：
```sql
CREATE INDEX [IX_orders_Column] ON [dbo].[orders] ([time]);
SELECT SUM(amount) FROM [orders]
WHERE time BETWEEN DATEADD(second, -60, GETDATE()) AND GETDATE();

## Case #12: 以存儲層原子操作取代分散式鎖

### Problem Statement（問題陳述）
**業務場景**：分散式統計需要跨節點一致的遞增/遞減/交換；自建分散式鎖風險大且複雜。
**技術挑戰**：如何確保操作原子性與正確性，同時維持高效能。
**影響範圍**：錯誤的分散式鎖會導致死鎖/資料錯亂。
**複雜度評級**：中

### Root Cause Analysis（根因分析）
**直接原因**：
1. 多步操作不可分割。
2. 自研鎖難以正確處理失敗/超時。
3. Redis/DB 原子能力沒被利用。
**深層原因**：
- 架構層面：未善用基建能力。
- 技術層面：對命令原子性認知不足。
- 流程層面：未評估鎖與原子指令差異。

### Solution Design（解決方案設計）
**解決策略**：用 Redis 的 INCRBY/DECRBY/GETSET/ListPush/Pop，保證操作不可分割；避免引入分散式鎖，降低系統複雜度與風險。

**實施步驟**：
1. 命令選型
- 實作細節：選定 INCRBY/DECRBY/GETSET/List*。
- 所需資源：Redis 文檔
- 預估時間：0.25 天

2. API 封裝
- 實作細節：封裝為 Engine 方法，隔離實作。
- 所需資源：.NET
- 預估時間：0.5 天

3. 正確性驗證
- 實作細節：與 InMemory 作對照，驗證 0% 誤差。
- 所需資源：測試框架
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```csharp
redis.StringIncrement("buffer", amount);    // INCRBY
int buf = (int)redis.StringGetSet("buffer", 0); // GETSET
redis.StringIncrement("statistic", buf);    // INCRBY
redis.ListLeftPop("queue");                 // LPOP

## Case #13: Redis 隊列項目的序列化策略（時間+數值）

### Problem Statement（問題陳述）
**業務場景**：需要把 QueueItem（count + timestamp）存入 Redis List；Redis List 儲存字串，需自定編碼。
**技術挑戰**：序列化/反序列化正確性、時間精度、跨語言互通。
**影響範圍**：解碼錯誤會導致逐出判斷錯誤。
**複雜度評級**：低

### Root Cause Analysis（根因分析）
**直接原因**：
1. List 僅支援字串元素。
2. 時間格式不統一有時區/精度問題。
3. JSON/XML 序列化過重。
**深層原因**：
- 架構層面：無統一序列化規範。
- 技術層面：時間表示選擇不當。
- 流程層面：缺少互通測試。

### Solution Design（解決方案設計）
**解決策略**：採用「count,毫秒值」的簡單字串格式，以 DateTime.MinValue 為原點存 milliseconds，兼顧精度與輕量；Decode 時切割轉回。

**實施步驟**：
1. 格式設計
- 實作細節：「{count},{millisSinceMinValue}」。
- 所需資源：.NET
- 預估時間：0.25 天

2. 編解碼實作
- 實作細節：Encode/Decode 靜態方法。
- 所需資源：.NET
- 預估時間：0.25 天

3. 測試
- 實作細節：不同時區/語系下來回轉換驗證。
- 所需資源：單元測試
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```csharp
public static string Encode(QueueItem v)
  => $"{v._count},{(v._time - DateTime.MinValue).TotalMilliseconds}";

public static QueueItem Decode(string s)
{
    var a = s.Split(',');
    return new QueueItem {
        _count = int.Parse(a[0]),
        _time = DateTime.MinValue + TimeSpan.FromMilliseconds(double.Parse(a[1]))
    };
}

## Case #14: 秒值序列驗證法（0..59 求和=1770）快速驗證滑動窗

### Problem Statement（問題陳述）
**業務場景**：需要快速建立一個可驗證滑動窗邏輯正確的測試資料流。
**技術挑戰**：確保「任何 60 秒視窗」內的總和都一致，便於判斷正確性。
**影響範圍**：縮短迭代週期，快速發現錯誤。
**複雜度評級**：低

### Root Cause Analysis（根因分析）
**直接原因**：
1. 隨機數據難以推導期望值。
2. 邊界漂移難以穩定判定。
3. 單元測試難以覆蓋連續場景。
**深層原因**：
- 架構層面：測試數據設計不足。
- 技術層面：缺少可閉合的數學特性。
- 流程層面：未固化測試法。

### Solution Design（解決方案設計）
**解決策略**：每秒用 DateTime.Now.Second 作為 amount，任何完整的 60 秒窗都應等於 (0+59)*60/2=1770；以此作為期望值對照。

**實施步驟**：
1. 產流器
- 實作細節：每秒 e.CreateOrders(DateTime.Now.Second)。
- 所需資源：.NET
- 預估時間：0.25 天

2. 取樣器
- 實作細節：每 200ms 取一次統計結果。
- 所需資源：.NET
- 預估時間：0.25 天

3. 對照輸出
- 實作細節：輸出 current/expected/test。
- 所需資源：Console
- 預估時間：0.25 天

**關鍵程式碼/設定**：
```csharp
Task.Run(() => {
    while (!stop) { Task.Delay(1000).Wait(); e.CreateOrders(DateTime.Now.Second); }
});
int expected = (0 + 59) * 60 / 2; // 1770
Task.Run(() => {
    while (!stop) { Task.Delay(200).Wait();
        Console.WriteLine($"statistic: {e.StatisticResult}, expected: {expected}, test: {e.StatisticResult == expected}");
    }
});

## Case #15: 架構選型決策：InMemory vs Redis vs Database

### Problem Statement（問題陳述）
**業務場景**：需要在性能、可用性、成本、複雜度間做平衡，選出合宜的統計架構。
**技術挑戰**：不同解法在吞吐、可擴展、可用性與成本上有巨大差異。
**影響範圍**：關乎長期可擴展與維運。
**複雜度評級**：中

### Root Cause Analysis（根因分析）
**直接原因**：
1. DB 方案吞吐低、影響交易。
2. InMemory 方案快但單機、無 HA。
3. Redis 方案分散式但吞吐較低、增加外部依賴。
**深層原因**：
- 架構層面：未定義非功能性需求（SLO/SLA）。
- 技術層面：缺乏量化比較。
- 流程層面：選型未引入壓測數據。

### Solution Design（解決方案設計）
**解決策略**：以統一壓測數據為依據，映射到需求優先級：單機極致吞吐選 InMemory；需分散式與 HA 選 Redis；DB 僅作原型或對照組。

**實施步驟**：
1. 定義需求權重
- 實作細節：吞吐/HA/成本/可維運。
- 所需資源：架構會議
- 預估時間：0.25 天

2. 數據對照
- 實作細節：引入 Case #8 數據。
- 所需資源：報表
- 預估時間：0.25 天

3. 決策與路線圖
- 實作細節：短期/長期雙路徑（先 InMemory，後 Redis）。
- 所需資源：Roadmap
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```text
無（決策與比較說明）

## Case #16: 參數調校：Period/Interval 的精度與資源取捨

### Problem Statement（問題陳述）
**業務場景**：不同場景對精度與資源的要求不同，需調整 period/interval 以平衡精度、延遲與資源使用。
**技術挑戰**：interval 越小，搬運頻率越高；interval 越大，精度與邊界抖動變差。
**影響範圍**：準確性/延遲/CPU 使用率/GC。
**複雜度評級**：中

### Root Cause Analysis（根因分析）
**直接原因**：
1. interval 決定桶數與 worker 開銷。
2. period/interval 比例決定 Queue 長度。
3. 過小 interval 帶來高頻系統呼叫。
**深層原因**：
- 架構層面：未定義精度需求。
- 技術層面：未量化資源/精度曲線。
- 流程層面：缺少調參流程與基準。

### Solution Design（解決方案設計）
**解決策略**：以 O(1) 設計為基礎，公式化評估空間複雜度=O(period/interval)；透過實測不同 interval（如 1s / 0.1s / 0.05s）對邊界抖動與 CPU 的影響，選定平衡點。

**實施步驟**：
1. 目標定義
- 實作細節：設定精度/延遲/CPU 目標。
- 所需資源：SLO
- 預估時間：0.25 天

2. 參數掃描
- 實作細節：在固定 period=60s 下掃描 interval 參數。
- 所需資源：壓測腳本
- 預估時間：0.5 天

3. 曲線擬合
- 實作細節：產出 interval→抖動/CPU 曲線，選擇平衡點。
- 所需資源：數據分析工具
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```csharp
private readonly TimeSpan _period = TimeSpan.FromMinutes(1);
// 嘗試不同 interval
private readonly TimeSpan _interval = TimeSpan.FromSeconds(0.1); // or 1s / 0.05s

## Case #17: 以 Azure Stream Analytics TumblingWindow 實作托管串流分析（加分題）

### Problem Statement（問題陳述）
**業務場景**：團隊希望使用雲端託管服務處理連續資料，簡化維運，並以 SQL 類語法表達時間窗聚合。
**技術挑戰**：快速上雲且維持可觀測性，接入多來源並輸出多目的地。
**影響範圍**：可維運性與可擴展性提升。
**複雜度評級**：中

### Root Cause Analysis（根因分析）
**直接原因**：
1. 自建方案維護成本高。
2. 異質來源/匯出需求多。
3. 需要事件時間窗與內建操作子。
**深層原因**：
- 架構層面：趨向託管化/平台化。
- 技術層面：熟悉流式 SQL 語法。
- 流程層面：佈署/監控/調參平台化。

### Solution Design（解決方案設計）
**解決策略**：採用 Azure Stream Analytics，以 TumblingWindow 寫視窗聚合；前接 Queue/Event Hub/Kafka，後寫 Storage/DB/Power BI；以托管服務承擔擴展與監控。

**實施步驟**：
1. 管線串接
- 實作細節：設定 Input（事件來源）與 Output（存放/可視化）。
- 所需資源：Azure 訂閱
- 預估時間：1 天

2. 查詢編寫
- 實作細節：以 SQL 類語法寫 SUM + TumblingWindow。
- 所需資源：ASA 工作
- 預估時間：0.5 天

3. 監控與擴展
- 實作細節：設定作業單位、scale、警示。
- 所需資源：Azure 監控
- 預估時間：0.5 天

**關鍵程式碼/設定**：
```sql
SELECT
  Make,
  SUM(CAST(Weight AS BIGINT)) AS Weight
FROM
  Input TIMESTAMP BY Time
GROUP BY
  Make,
  TumblingWindow(second, 10);