CHAPTER 03

代表案例

每個案例:遇到什麼問題、怎麼做、結果如何。

支付與錢包系統

技術負責人・帶領 13 人以上團隊・2024–2026

問題

高併發交易下,回呼重送或網路重試都可能讓同一筆款項被處理兩次;會員餘額與資金流水必須隨時對得上。

做法

  • 支付冪等、分散式鎖與餘額一致性機制,同一筆交易只入帳一次
  • 補償與重試機制處理失敗交易,搭配風控稽核
  • 以 Kafka、Redis、MongoDB 建立事件驅動架構
  • 自動對帳流程,加上交易監控與告警
  • 以重送、併發與補償情境的測試驗證上述機制

成果

冪等與分散式鎖
不重複扣款
補償與稽核流程
自動對帳

公司名稱與營運數據暫不公開。可公開的是測試情境:回呼重送、併發請求與補償,沒有另附線上交易量。

新聞採集與全文搜尋平台

傲創科技・資深工程師・2019–2024

問題

每接一個新聞網站就要寫一套爬蟲,約需 2 天;全文搜尋回應約需 2 秒。

做法

  • 以 Hyperf、Swoole 建立高併發採集服務,RabbitMQ 調度與削峰
  • 可配置式採集框架,規則存在 MongoDB,新站點改用設定接入
  • Elasticsearch 全文搜尋,Canal 將 MySQL 即時同步到索引
  • Redis 與 APCu 多層快取,降低資料庫負載

成果

新站點接入時間
約 2 天 → 半天內
搜尋回應時間
約 2 秒 → 300 毫秒內
每日處理新聞資料
十萬級
尖峰每分鐘採集量
數千篇

搜尋時間比較的是全文搜尋上線前與上線後的回應,不是公開的百分位測試,也沒有留下查詢樣本數。

履歷問答助手

本站・規則工具+只看履歷的模型

問題

訪客會自由提問。模型若編造公司、數字或日期,履歷就不可信;模型逾時或失敗時,頁面也不能沒有答案。

做法

  • 頁面先把已知問題交給履歷工具:公司、技能、技術棧、學歷、證照、帶隊經歷與聯絡方式
  • 對不上的問題交給只看精簡履歷的模型,並附上問題命中的那一段工作內容
  • 模型沒有工具、沒有金鑰。問題最多 300 字,10 秒逾時,並限制來源網域與請求頻率
  • 逾時、非成功回應或空回答時,改回規則答案

成果

已知問題
同一份履歷
其餘問題
只依履歷回答
模型失敗時
回到規則答案

就是本頁的問答助手,可以直接試。沒有另附評分基準。

下一章 · CHAPTER 04 技能