最近花了兩天時間用 muduo 部分實現了 memcached 服務器協議，代碼位于 examples/memcached/server，能通過 memcached 的大部分測試用例（incr/decr 還沒有實現）。
這不是 memcached 的替代品（它沒有實現LRU和超時功能，也沒有實現二進制協議，更沒有自己管理內存），而是一個網絡編程的示例（代碼只有 1000 行，比 memcached 小很多），展示 muduo 風格的事件驅動編程，以及將來性能優化的試驗品（換句話說，現在這個版本完全沒有在性能上做出任何努力）。讀過 memcached 代碼的人可以對比這兩種編程風格的區別，memcached 的 read/write 操作穿插于正常邏輯處理，而 muduo 的網絡數據讀寫是由庫完成，應用程序只關心消息收發，目前二者的基本 get/set 操作的性能相當。
現在 muduo 的 inspector 內置了 gperftools 的遠程 profiling 功能，memcached-debug 展示了其用法。
為什么不必優化 set 操作（含 set/add/update/append/prepend/cas 等）的性能？
1. 比例。既然是 memcache，那么 get:set 的比例很高，10:1 甚至更高，因此優化的重心應該是 get 而非 set。
假設 memcached 能處理 100k QPS，再假設這些操作都是 set（其實應該不到 10% 是 set），再假設所有的 set 都是串行執行的（沒有并發），那么每次 set 的 CPU 時間不應該超過 10 us（含服務器本地的網絡代碼運行時間，但不含網絡延遲）。而實際上一次 set 的 CPU 時間最多是 2~3 us （用 memcached-footprint 程序測得），根本不值得優化。
2. 網絡帶寬。假設一次 set 操作的 key + value 的長度是 1k bytes，TCP 的有效載荷帶寬按110MB/s估算，那么1kB數據在千兆網上的慣性延遲是 9us（傳輸延遲是幾十上百微秒，與此無關），也就是說服務器的網卡收到這 1kB 數據需要花 9us 時間（從第一個字節到達到服務器到收完最后一個字節），那么在 set 耗時 2~3 us 的情況下再去優化它是做無用功。
3. 產生“需要更新的數據”的成本遠大于 memcached set 的開銷。memcached 需要更新，往往是將已寫入數據庫的新數據放到 memcached 中，那么寫數據庫的開銷遠遠大于 memcached set 的開銷，優化 set 對提升系統整體性能沒意義。