使用 muduo 實作 memcached 協定伺服器：事件驅動網路程式設計實戰

耗時兩天，使用 muduo 網路庫部分實作了 memcached 伺服器協定，程式碼位於 examples/memcached/server，可通過 memcached 大部分測試案例（incr/decr 尚未實作）。這不是 memcached 的替代品（未實作 LRU、過期機制、二進位協定、自主記憶體管理），而是一個網路程式設計教學範例（僅 1000 行，遠小於 memcached），展示 muduo 風格的事件驅動程式設計，並作為未來效能優化的實驗基礎。

架構對比：muduo vs memcached

讀過 memcached 原始碼者可對比兩種程式設計風格：

• memcached： read/write 操作穿插在正常邏輯處理中
• muduo： 網路資料收發由庫完成，應用層只關心訊息收發

目前兩者基本 get/set 操作效能相當。muduo 內建 inspector 整合 gperftools 遠端分析功能，memcached-debug 範例展示其用法。

為什麼不必優化 set 操作效能？

1. 操作比例考量

memcache 典型 get:set 比例極高（10:1 甚至更高），優化重心應在 get。假設 100k QPS、全為 set、串列執行，每次 set CPU 時間不超過 10μs；實測僅 2-3μs，無優化必要。

2. 網路頻寬限制

假設 set 封包 1KB，千兆網路 TCP 有效載荷 110MB/s，傳輸 1KB 需 9μs（慣性延遲），而 set 處理僅 2-3μs，網路傳輸才是瓶頸。

3. 系統整體成本

產生「需更新資料」的成本（如寫資料庫）遠大於 memcached set 開銷，優化 set 對整體系統效能提升無意義。

程式碼結構亮點

• 事件驅動模型：TcpConnection 回呼處理訊息收發
• 協定解析：文字協定解析器處理 get/set/add/replace/append/prepend/cas
• 記憶體管理：使用 std::unordered_map 儲存鍵值對
• 並發控制：單執行緒事件迴圈，無鎖設計
• 效能分析：整合 gperftools CPU/heap 分析

完整程式碼可參考 muduo 原始碼倉庫 examples/memcached/server 目錄。