最近花了兩天時間用 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 展示了其用法。
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 對提公升系統整體效能沒意義。
muduo網路庫學習筆記 5 執行緒池的實現
生產者 消費者問題也被稱為有界緩衝區問題，兩個程序 執行緒共享乙個公共的固定大小的緩衝區。其中乙個是生產者，將資訊放入緩衝區 另乙個是消費者，從緩衝區中取出資訊。問題在於當緩衝區已滿，而此時生產者還想向其中放入乙個新的資料項的情況。其解決方法就是讓生產者休眠，待消費者從緩衝區中取出乙個或多個資料項時...
用棧實現佇列 用佇列實現棧
棧的特點 filo firstinlastout 僅能從棧頂插入，刪除元素。最基本的介面包括push 從棧頂壓入元素 pop 從棧頂彈出元素 佇列的特點 fifo firstinfirstout 僅能從隊頭刪除元素，從隊尾插入元素。最基本的介面包括enque 從隊尾插入元素 deque 從隊頭刪除元...
用棧實現佇列，用佇列實現棧。好玩！！！
因為在資料結構中，棧和佇列長得實在是太像了，將他們拿來比較是不可避免的，棧 後進先出，而佇列 先進先出。同樣是只能在一端進行操作，那麼問題來了，能相互實現？能不能得好好分析一下嘛，如果是用兩個棧來實現佇列，好像這操作可以哦。一下，你就明白！顯然用兩個棧可以實現佇列的功能，就是借助另乙個棧來中轉一下，...