用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 对提高系统总体性能没意义。