CASE 01 ／大型遊戲文字客服系統

CASE 01主導開發

大型遊戲
文字客服系統

客訴分散、人力消化不及 → 高併發即時派案，多節點服務水平擴展。

SignalRRedis BackplaneAI 應用客服業績統計

我的角色｜主導開發：後端架構設計、即時通訊與派案機制實作、AI 推薦回覆整合，並帶領團隊持續改善這套上線中的系統。

SCROLL

01 ／問題與情境

THE PROBLEM ／問題與情境

尖峰時段客訴湧入，單機 WebSocket 撐不住，而客服無法專職服務。

>3款遊戲

多款遊戲、多個進線管道各有各的規則，卻共用同一套客服後台。

1台

連線與案件狀態全在單機記憶體：加機器、重啟、部署都等於斷線重連。

輪流派

只能依在手案件數輪流，VIP、熟客、語系分不出來。

0報表

誰接了多少、平均多久結案，全靠人工翻紀錄，主管無從調度人力。

02 ／解決方案

THE SOLUTION ／解決方案

把連線狀態搬出應用程式，機器就能無痛加。

01 進線

統一案件模型

三個管道收斂成同一組 API 與案件模型，各平台差異只留在設定檔。

02 連線

SignalR Hub

玩家與客服雙向即時訊息，以群組推播取代逐一維護連線。

03 關鍵

狀態外部化到 Redis

連線、案件與客服負載全搬進 Redis，節點退化成可隨時汰換的無狀態程序。

04 派案

多層優先階梯

VIP、熟客、語系、最低負載逐階往下試，全數滿載才進等待佇列。

業績統計

每小時預聚合彙總成日統計自然語言查詢AI輔助客服業績統計，讓看報表不再困難。

03 ／系統架構

ARCHITECTURE ／系統架構

訊息從進線到落地，經過哪些節點。

1／5 進線層・多款遊戲

桌面應用程式SDK

App應用程式Game Server拋轉

WEBHTTPS

2／5 接入層

API GatewayJWT驗證・每個平台做隔離

派案服務多層派案判斷，發給合適的客服

等待佇列VIP／一般玩家雙佇列

業績統計服務讀預聚合結果・不掃原始事件

3／5 即時通訊層・可水平擴展

Hub #1

Hub #2

Hub #3

Redis Backplane

連線狀態外部化・跨節點廣播
分散式鎖・案件與客服負載計數

4／5 資料與外部服務

gRPC 資料服務資料傳輸・用戶端負載平衡

Elasticsearch／檢索訊息、事件統計數據

LLM產生推薦回覆推薦內容僅供客服參考，不直接傳送

5／5 橫切機制・REDIS協調程序進行

背景排程定時進行統計預聚合・分散式鎖確保多機器不互搶

連線健康檢查驗證最後收包時間

日誌與告警結構化日誌・警告層級分類・推播嚴重異常事件

※Desktop 版可展示 Data Flow 🖥️

進線層・多款遊戲

桌面應用程式
SDK

App應用程式
Game Server拋轉

WEB
HTTPS

›

接入層

API Gateway
JWT驗證・每個平台做隔離

派案服務
多層派案判斷，發給合適的客服

等待佇列
VIP／一般玩家雙佇列

業績統計服務
讀預聚合結果・不掃原始事件

›

即時通訊層・可水平擴展

Hub #1

Hub #2

Hub #3

Redis Backplane

連線狀態外部化・跨節點廣播
分散式鎖・案件與客服負載計數

›

資料與外部服務

gRPC 資料服務
資料傳輸・用戶端負載平衡

Elasticsearch／檢索
訊息、事件統計數據

LLM產生推薦回覆
推薦內容僅供客服參考，不直接傳送

橫切機制・REDIS協調程序進行

背景排程
定時進行統計預聚合・分散式鎖確保多機器不互搶

連線健康檢查
驗證最後收包時間

日誌與告警
結構化日誌・警告層級分類・推播嚴重異常事件

━ 青色＝水平擴展關鍵路徑┄ 虛線框＝橫跨所有節點的橫切機制去識別化示意，非實際部署拓樸

04 ／互動演示

INTERACTIVE DEMO ／互動演示

動手桌機可操作可互動

互動區：送一條事件進來，看派發給哪層級客服？

VIP 專屬客服

24 小時內服務過的客服

語系專屬客服

命中

一般客服

排入等待佇列

組一條案件並進行派案，流程會由左往右逐層嘗試。若當下無適合的客服，事件會進入等待佇列。

※Desktop 版可操作這段演示 🖥️

本頁為去識別化模擬，不含專案原始碼或資料；互動演示的派案邏輯在瀏覽器端執行，資料皆為合成。

VIP專屬客服

24小時內服務客服

語系專屬客服

一般客服

排入等待佇列

組一條案件並進行派案，流程會由左往右逐層嘗試。若當下無適合的客服，事件會進入等待佇列。

新進線／合成資料

玩家等級

玩家語系

同樣的條件再派一次，就當作同一位玩家回頭問，24 小時服務紀錄會自動生效。

在線客服

待機中

客服 AVIP0 / 2

客服 BEN1 / 3

客服 C0 / 2

等待佇列0 人

本頁為去識別化模擬，不含專案原始碼或資料；互動演示的派案邏輯在瀏覽器端執行，資料皆為合成。

05 ／技術選型與設計決策

TECHNOLOGY & DESIGN DECISIONS ／技術選型與設計決策

每個技術都對應一個要解的問題。

ASP.NET CoreWeb API、Hub 承載與案件領域邏輯架構

SignalR玩家／客服雙向即時訊息與群組推播

Redis案件與客服狀態外部化、分散式鎖、等待佇列、負載計數與統計預聚合

gRPC案件與訊息落地的資料服務通訊，用戶端負載平衡掛多節點

Elasticsearch案件資訊與統計查詢

LLM API帶對話歷程給AI產生推薦回覆，供客服人員參考

ALTERNATIVE CONSIDERED

為何不用 Sticky Session，而選 Redis Backplane？

單一節點故障時該批連線一起中斷，流量也無法平均，尖峰時段仍會壓垮同一台。改為 Redis Backplane 多付一份維運成本，換到任意節點可接手，臨時加機器、單節點故障不影響服務。

06 ／挑戰與成果

CHALLENGES & RESULTS ／挑戰與成果

上線後最難的不是流量，是狀態不能說謊。

挑戰 01

SDK 說連線正常，實際早已收不到封包

改以最後收包時間為準判定連線，分警告與強制重連兩級閾值，並依各遊戲流量差異各自設定，異常同步推播給值班群組。

挑戰 02

多節點下客服負載計數會漂移

以 Redis 計數器為單一真相，節點記憶體僅作快取；派案前對帳、不一致就記錄，並在指派前複查上限，避免秒差造成超派。

擴展

單機常駐，重啟即斷線

→ 加節點不中斷服務

派案

傳統按服務量分配

→ 階梯自動指派，專職服務特定玩家

績效檢視

人工翻紀錄估算

→ 聚合報表＋自然語言查詢

推薦回覆

客服從零打字

→ AI產生回覆草稿，只需確認

下一個案例・ 02 企業內部文件檢索機器人 →