最近花了两天时间用 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 对提升系统整体性能没意义。