5. 分片策略（Sharding Strategies）

最近看了獵魔女團，不得不說《Soda Pop》真的是一首很洗腦的歌，而且根據我以前操作客戶品牌的經驗(我曾經在奧美擔任實習生一段時間，在學期間)，這是一個非常聰明且敏略的策略，透過動畫這個載體來擴張新的客群。

我們先忘掉伺服器和資料庫，現在我們是一家大型娛樂公司（比如 HYBE 或 JYP）的首席製作人。

想像一下，如果我們的公司只經營一個、也是唯一一個超級偶像團體。就算這個團體有 20 個成員，能駕馭所有風格，他們也無法滿足全球所有粉絲的喜好，也無法同時在美洲、歐洲和亞洲舉辦巡迴演唱會。

這時，我們會意識到且不得不面對一個根本問題：沒有任何單一團體可以 無限擴張 (Scale-Up) 以佔領所有市場。

所以我們勢必放棄「打造一個能迎合所有人的超級天團」的幻想，轉而採納「 針對不同市場和粉絲群，推出多個風格差異化的獨立團體 」的策略。

喜歡年輕且具有活力的會是一種客群、喜歡成熟且具有深沉故事性的又會是一種客群，同時，喜歡看到非真人的又會是一種客群。

看到了嗎? 在這個過程中，我們已經不知不覺的進行分片 / 分組策略了 - 這甚至是行銷學的學理!

分片 (Sharding) 的核心哲學，就是 放棄 「打造一個萬能許願機/工具」的幻想，轉而採納「 針對不同需求與背景 ，推出多個風格差異化的解決方案」的策略。這就是「分而治之」，也就是水平擴展 (Scale-Out)。

從粉絲的角度來看，他們可能追的是「HYBE」或「JYP」這個廠牌下的音樂和藝人（單一的邏輯實體）。粉絲只想說：「我要聽最新的 K-Pop」，而不太關心這首歌具體是哪個團體唱的（除非他們是特定團體的粉絲）。

當一個潛在的粉絲（請求）出現時：

1. 粉絲在 YouTube 或 Spotify（應用程式）上接觸到公司的音樂。
2. 公司的企劃中心（路由層）通過演算法和市場分析，根據粉絲的聽歌偏好、年齡、地區（分片鍵 Shard Key），精準地判斷出這位粉絲最可能喜歡哪個團體（Shard）。
3. 系統會優先向這位粉絲推薦該團體的音樂和內容。

因此，整個娛樂帝國在品牌上是統一的，但在音樂產品和粉絲運營上，是由許多個獨立、自治的團體組成的。

graph TD
    A[潛在粉絲] --> B[娛樂公司企劃中心 (Routing Layer)<br/>Shard Key: 音樂品味/用戶畫像]
    B -- 偏好: Hip-hop, 強烈風格 --> C[分片 1 (Shard 1)<br/>團體 A (e.g., BTS)]
    B -- 偏好: 清新, 流行舞曲 --> D[分片 2 (Shard 2)<br/>團體 B (e.g., NewJeans)]
    B -- 偏好: 搖滾, 樂團風格 --> E[分片 3 (Shard 3)<br/>團體 C (e.g., DAY6)]

其終極目標不是為了讓單一團體變得更「快」地出新歌，而是為了讓整個公司的影響力版圖變得無比「大」。是為了讓公司的總粉絲數和收入，可以隨著成功團體（伺服器）的增加而線性地增長，從而突破單一團體的市場極限。

所以我們可以整理出 分片策略（Sharding Strategies） 最核心的哲學概念 : 透過需求、特性與情境的區分化，以換取規模的線性擴展

既然我們把粉絲市場切割給不同團體，那麼設計一個好策略的最高指導原則就是：讓絕大多數的粉絲互動，都能在單一團體的生態系內完成，並極力避免需要粉絲同時關注好幾個團體才能獲得完整體驗。

就像我們在上述所提到說根據曲風、團員形象魅力以及團體形象(奶狗/帥氣/魔鬼)，我們會有一個基礎的需求( Domain requirement )並希望在這個環境中盡可能快速且完整的滿足我的需求，可能會是有收藏專輯與海報、粉絲互動與牽手會乃至於想要看到偶像團體參加綜藝節目會擔任電影演員。

這引導出三個關鍵的設計原則：

1. 選擇高內聚的分片鍵 (Shard Key)：

• 這是分片策略的成敗關鍵。分片鍵就是你用來決定「這位粉絲該歸哪個團體經營」的規則。
• 原則：選擇的鍵（團體的音樂風格、概念、成員魅力）必須能將粉絲的忠誠度高度聚合在同一個分片內。一個團體的「概念」就是最好的分片鍵。一旦粉絲成為某個團體（如 SEVENTEEN）的死忠粉絲（CARAT），他們的所有消費、互動、討論都會圍繞這個團體展開。這使得粉絲管理和商業變現的效率極高。如果團體風格頻繁變動，粉絲就可能流失到其他團體，造成災難。

2. 追求市場的均勻分佈 (Even Distribution)：

• 你不能把所有頂級資源（最好的詞曲作者、MV 導演）都只給一個團體，導致這個團體紅得發紫（「熱點 Hotspot」），而其他團體卻無人問津，最終導致公司整體發展不均。
• 原則：公司的資源分配和企劃策略，必須能讓粉絲流量和商業收入均勻地分佈到各個有潛力的團體上，避免產生單點依賴。一個團體過熱，當他們需要休息或入伍時，會對公司造成巨大衝擊。

3. 為跨分片活動做好預期管理 (Plan for Scatter-Gather)：

• 總有些活動是需要跨團的，例如「公司家族演唱會」或「年末特別合作舞台」。
• 原則：
  • 識別它：在企劃之初就要識別出哪些是必然的跨團合作。
  • 隔離它：家族演唱會的籌備和售票是一個獨立的大型專案，它的複雜度遠高於單一團體的巡演，不會影響各個團體自身的日常活動。
  • 接受它：粉絲和公司都接受，家族演唱會的準備時間更長、成本更高，而且通常一年只有一次，不可能每個月都辦。這就像跨分片查詢，成本高昂且不應頻繁進行。

恭喜，現在我們是一名具有領域(Domain)分片策略能力的首席製作人了，未來我們不做軟體工程師，也可以去當一個社交工程師

結束了我們短暫且精彩的的首席製作人生涯，回過頭來看看用資料庫設計的概念怎麼說:

核心的哲學概念 : 透過需求、特性與情境的區分化，以換取規模的線性擴展

關鍵設計三原則 :

1. 選擇高內聚的分片鍵 (Shard Key)

• 選擇的鍵必須能將高度關聯的資料聚合在同一個分片內。
• 選擇的鍵必須具有高度唯一性與識別性

2. 追求數據的均勻分佈 (Even Distribution)

• 一個分片過載崩潰，會拖垮整個系統的效能。
• 分片鍵的選擇和分片演算法（如雜湊分片）必須能讓資料和請求負載均勻地分佈到所有領域(domain)分片上。
• 不要為了追求均勻分布，而 汙染 分片需求領域意涵

3. 為跨分片查詢做好預期管理 (Plan for Scatter-Gather)

• 總有些操作是無法避免跨分片的，例如我們的資料需求描述中有 Total 、 Sum 、 All
• 原則 :
  • 識別它：在設計之初就要識別出哪些是必然的跨分片查詢。
  • 隔離它：核心業務與次級業務需求必須要切分，例如 : 股票線上交易。為了避免 I/O 搶資源，寫入作為核心會放較多資源，而讀取通常會將其導向一個專門的分析系統（這就和 CQRS、冷熱分離的思想連接起來了）。
  • 接受它：接受這類查詢的延遲會更高，且通常只能提供「最終一致性」的結果。

水平分片思維脈絡： 業務<=>特性<=>資料生命週期

依據業務邏輯分片：

• 地理分片：亞洲區、美洲區、歐洲區
• 時間分片：2023 年、2024 年、2025 年
• 客戶分片：企業客戶、個人客戶

依據資料特性分片：

• 熱度分片：熱門商品 vs 冷門商品
• 頻率分片：高頻交易 vs 低頻交易
• 大小分片：大額訂單 vs 小額訂單

分片路由設計：

• 一致性雜湊：確保資料分佈均勻
• 範圍分片：依據業務邏輯劃分
• 目錄服務：集中管理分片映射

AWS 特化實作：在新加坡交易華爾街市場

這是一個以股票交易來說非常常見的情形，我們必須想盡辦法去克服遙遠的距離、氣急敗壞的交易員與咬信號線的鯊魚來完成我們的股票交易。以下是去脈絡化之後所產生的 4 個核心挑戰，也是依循了 業務需求 > 特性 > 資料生命週期的邏輯思考脈絡。

核心挑戰：

1. 地理延遲 (Latency)：新加坡到紐約的光纖物理距離導致了數百毫秒的延遲，這在金融交易中是致命的。
2. 資料洪流 (High Velocity)：市場行情（Ticks）瞬息萬變，交易指令要求極速響應。
3. 讀寫不對稱 (Read/Write Asymmetry)：交易員讀取市場行情的頻率遠高於他們下單（寫入）的頻率。
4. 一致性要求 (Consistency)：交易指令的寫入必須是強一致的，不能出錯。

以上是我們面對這個需求時，在長期的開會溝通後所釐清出來的客觀核心需求式樣。但依舊有人所不能及的限制，接下來我們來逐步解析挑戰該如何解決。

核心矛盾：物理定律 vs. 金融需求

1. 物理定律 (延遲)：光纖從新加坡到紐約來回一次，物理延遲就在 200-300 毫秒左右。這對於高頻交易來說是無法接受的。
2. 金融需求 (一致性)：一筆股票交易的「下單」和「成交」是絕對的「事實」，必須被強一致地記錄在離交易所最近的地方（紐約），不容許任何模糊或延遲。
3. 用戶體驗 (即時性)：新加坡的用戶下單後，希望「立即」看到自己的投資組合更新，也希望「立即」看到最新的市場報價。

首先，為了解決物理問題，我們可以採用的措施是同樣用物理來解決 - 在事件密集發生地直接設立交易服務。我們將最關鍵的寫入延遲降到最低。從撮合引擎到資料庫的寫入必須在微秒或毫秒內完成。

我們可以將所有交易指令的「最終目的地」——寫入主分片，且必須部署在離交易所（如 NYSE, NASDAQ）最近的資料中心，例如 AWS 的 us-east-1（北維吉尼亞），並使用具備 ACID 事務能力的資料庫，如 Amazon RDS (PostgreSQL)，確保每一筆交易的原子性和持久性。

這樣架構有沒有很熟悉? 核心功能應用在寫入 看到這個關鍵字的時候我們就必須立刻聯想到 CQRS 讀寫分離策略， 這樣子就能盡可能避免因為延遲錯過交易時機，在紐約的寫入主分片完成交易或接收到市場新行情後，會立即將這些「事件」發布到一個高速數據流服務中（如 Amazon Kinesis）。

然後我們立即將完成的交易成果送回到新加坡交易所

假如這樣做，我們就會立刻吃到延遲的高昂成本了。要注意，我們在讀取的時候，實際上的需求其實是：想要 「立即」 看到具有業務邏輯意涵的 「數據」 。所有的一切我們都必須站在 需求端(Domain) 去進行解析與重構。所以對於這個架構解來說，最好的方式其實是延續 在本地端執行 的概念邏輯，盡可能減少交易完成與後續的業務化數據的執行處理成本，然後將成本段放在相對需求較少的購買策略寫入與交易成果讀取。在新加坡的資料庫架構中，我只需要留存 下單命令 與 交易成效 的資料庫即可。

這個架構的核心哲學是：將 「改變事實的行為（交易）」 與 「詮釋事實結果的業務邏輯（分析與呈現）」 在 地理上 和 系統上 徹底分離。

graph TD
    subgraph "新加坡區域 (ap-southeast-1)"
        A[用戶瀏覽器/App<br/><b>AWS Amplify</b>] --> B[<b>Amazon API Gateway</b><br/>(Edge-optimized)]
        B --> |讀取請求 (GET)| L[查詢服務<br/><b>AWS Lambda</b>]
        L --> M[<b>Amazon Aurora Global DB (Read Replica)</b><br/>唯讀副本]
        M --> L --> B --> A

        B -- |寫入請求 (POST)| C
    end

    subgraph "AWS 全球骨幹網路"
        C[<b>AWS Global Accelerator</b><br/>優化路由，降低跨洋延遲] --> D
    end

    subgraph "紐約/北維吉尼亞區域 (us-east-1)"
        D[<b>Amazon API Gateway</b><br/>(Regional Endpoint)] --> E[命令處理服務<br/><b>AWS Lambda / AWS Fargate</b>]
        E --> F[<b>Amazon Aurora Global DB (Primary)</b><br/>寫入主庫]

        F -- 觸發 (CDC) --> G[<b>Amazon Kinesis Data Streams</b><br/>原始交易事件流]
        G --> H[事件增值服務<br/><b>AWS Lambda</b>]
        H --> I[<b>Amazon EventBridge</b><br/>高階業務事件總線]
    end

    subgraph "跨區域數據同步"
        I -- EventBridge 跨區域規則 --> J[<b>Amazon EventBridge (新加坡)</b>]
        F -- Aurora Global DB 物理複製 (<1s) --> M
    end

    subgraph "新加坡區域 (ap-southeast-1) - 狀態更新"
        J --> K[<b>Amazon SQS</b><br/>緩衝與解耦]
        K --> L_update[查詢模型更新服務<br/><b>AWS Lambda</b>]
        L_update --> M
    end

    style M fill:#e8f5e8,stroke:#388e3c,stroke-width:2px
    style F fill:#e3f2fd,stroke:#1976d2,stroke-width:2px

流程詳解

1. 命令發送（新加坡 → 紐約）

• 新加坡的用戶發出一個「買入 10 股 AAPL」的交易指令。
• 這個指令（Command）被封裝後，通過 AWS Global Accelerator 這樣的優化網路，以最低延遲發送到部署在紐約的 「交易執行服務」。這是你設計的關鍵：唯一的遠端寫入入口。

2. 事實記錄（在紐約內部）

• 紐約的服務接收到命令，執行必要的驗證。
• 它與 「交易資料庫」（例如 Amazon RDS）進行交互，以一個強一致性的事務（Transaction）記錄下這筆交易。這是系統中唯一的、不可變的「事實」。

3. 原始事件產生（在紐約內部）

• 交易成功寫入資料庫後，立即產生一個 原始的、低階的事件，例如 TradeExecutedV1，內容可能只包含 trade_id, user_id, symbol, quantity, price。
• 這個原始事件被發布到 Amazon Kinesis 數據流中。Kinesis 非常適合處理這種高吞吐量、有序的原始數據流。

4. 業務邏輯增值（在紐約內部）

• 這一步是設計的精髓。一個或多個 「交易濃縮/增值服務」（通常是 Lambda 函數）會訂閱 Kinesis 流。

• 當它收到 TradeExecutedV1 事件後，它會執行你所說的「業務邏輯處理」。例如：

  • 查詢用戶的持倉成本，計算本次交易的已實現/未實現損益。
  • 更新該用戶投資組合的總價值和風險敞口。
  • 檢查是否觸發了某個風控規則或止損線。

• 處理完成後，它不會直接回傳數據，而是產生一個或多個 全新的、具有豐富業務意涵的高階事件，例如 PortfolioValueUpdated、TradeProfitCalculated 或 RiskThresholdBreached。 5.高階事件分發與回傳（紐約 → 新加坡）

• 這些高階事件被發布到 Amazon EventBridge。EventBridge 擅長基於內容的智能路由。

• 我們在 EventBridge 上設定一條「跨區域規則」，將所有來自紐約的這些高階事件，轉發到新加坡區域的 EventBridge 總線上。 6.本地狀態更新（在新加坡內部）

• 新加坡的 EventBridge 接收到事件後，觸發本地的 「查詢模型更新服務」。

• 該服務解析事件內容，並更新專門為新加坡用戶優化的 「本地讀取資料庫」。這個資料庫可能是 Aurora 的讀取副本，或是 DynamoDB 表。它的結構是反正規化的，完全為了快速查詢而設計。

設計的優勢總結

• 職責清晰：紐約端專注於 執行與記錄，確保交易的原子性和速度。新加坡端專注於 分析與呈現，確保用戶體驗的流暢性。
• 數據精煉：跨越太平洋傳輸的不再是原始的、需要客戶端再加工的數據，而是已經被紐約端服務「消化」和「提煉」過的、具有直接業務價值的 「資訊」。這極大地降低了新加坡端的處理複雜性。
• 彈性與可擴展性：如果未來需要增加新的業務分析（例如，增加一個反洗錢監控），你只需要在紐約增加一個新的 Lambda 來消費 Kinesis 的原始事件流，並產生新的高階事件，而無需改動任何現有流程。
• 解決延遲：用戶在新加坡的所有讀取操作（查看報表、刷新持倉）都是訪問本地資料庫，響應極快。唯一的延遲體現在「下單」到「在新加坡的儀表板上看到更新」的這段時間，而這個時間因為非同步事件驅動的設計，已經被優化到極致

總結來說，分片策略是一門關於 「切割」 與 「權衡」 的藝術。它的核心是為了應對「規模」這個 終極挑戰 ，其手段是將一個大問題拆解成無數個小問題，並通過精巧的設計，讓絕大多數請求都變成簡單的小問題來解決。