YayJun
LOADING
YayJun
LOADING
客訴分散、人力消化不及 → 高併發即時派案，多節點服務水平擴展。
我的角色｜主導開發：後端架構設計、即時通訊與派案機制實作、AI 推薦回覆整合，並帶領團隊持續改善這套上線中的系統。
THE PROBLEM ／ 問題與情境
3 款遊戲
三款遊戲、多個進線管道各有各的規則，卻共用同一套客服後台。
1 台
連線與案件狀態全在單機記憶體：加機器、重啟、部署都等於斷線重連。
輪流派
只能依在手案件數輪流，VIP、熟客、語系一律分不出來。
0 報表
誰接了多少、平均多久結案，全靠人工翻紀錄，主管無從調度人力。
THE SOLUTION ／ 解決方案
01 進線
統一案件模型
三個管道收斂成同一組 API 與案件模型，各平台差異只留在設定檔。
02 連線
SignalR Hub
玩家與客服雙向即時訊息，以群組推播取代逐一維護連線。
03 關鍵
狀態外部化到 Redis
連線、案件與客服負載全搬進 Redis，節點退化成可隨時汰換的無狀態程序。
04 派案
四階優先階梯
VIP、熟客、語系、最低負載逐階往下試，全數滿載才進等待佇列。
ARCHITECTURE ／ 系統架構
進線層・多款遊戲
接入層
即時通訊層・可水平擴展
Redis Backplane
連線狀態外部化・跨節點廣播
分散式鎖・案件與客服負載計數
資料與外部服務
橫切機制・每個節點都跑，靠 REDIS 協調
INTERACTIVE DEMO ／ 互動演示
可互動VIP 玩家先找專屬組，組內取在手案件最少的，第一階就成立。
不是最低負載，但 24 小時內服務過，續接同一人不必重講一遍。
跳過負載更低但不通英文的客服，國際版語系優先於負載。
玩家提問 ／ 合成資料
派案結果
待機中從左邊選一則提問，派案階梯會由左往右逐階試，停在命中的那一階並產出回覆草稿。
AI 建議回覆 ／ 客服確認後才送出
AI 建議回覆 ／ 客服確認後才送出
AI 建議回覆 ／ 客服確認後才送出
本頁為去識別化整理，不含前雇主原始碼或資料；互動演示皆為前端合成資料。
TECHNOLOGY & DESIGN DECISIONS ／ 技術選型與設計決策
ALTERNATIVE CONSIDERED
為何不用 Sticky Session，而選 Redis Backplane？
Sticky Session 改動最小，但連線與節點綁定：單一節點故障時該批連線一起中斷，流量也無法平均，活動日仍會壓垮同一台。改為 Redis Backplane 多付一份維運成本，換到任意節點可接手、活動前直接加機器、單節點故障不影響服務。
CHALLENGES & RESULTS ／ 挑戰與成果
挑戰 01
SDK 說連線正常，實際早已收不到封包
改以最後收包時間為準判定連線，分警告與強制重連兩級閾值，並依各遊戲流量差異各自設定，異常同步推播值班群組。
挑戰 02
多節點下客服負載計數會漂移
以 Redis 計數器為單一真相，節點記憶體僅作快取；派案前對帳、不一致就記錄，並在指派前複查上限，避免秒差造成超派。
擴展
單機常駐，重啟即斷線
→ 加節點不中斷服務
派案
主管逐案分配
→ 階梯自動指派，只看例外
績效檢視
人工翻紀錄估算
→ 預聚合報表＋自然語言查詢
回覆草稿
客服從零打字
→ AI 草稿，改動幅度可追蹤