用muduo實現memcached協議的例子

最近花了兩天時間用 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 對提高系統總體性能沒意義。