从各方面的反馈来看redis的性能都在memcached等其它nosql工具之上，且提供了相当不错的功能，比买memcached支持的指令还多，所以必须出手分析一下了。

    自从linux 2.6.9后linux提供了驱动级的系统函数splice。它的作用是在文件描述符直接转发数据，直接对内核内存块做引用标记而不需要借用用户内存复制数据。这样就大大节省了分配内存，再read和write的性能消耗。
    自己用了一下这个函数发现总是返回EINVAL，于是去阅读HAProxy的源代码，总算弄明白了一些使用条件，理解了这个函数的设计思路。
    可以说splice本来就是用于select/poll/epoll等异步机制或者跨进程的通信，所以要求输入和输出必须至少有一个描述符是管道。于是我们可以看到以下清晰的流程：有数据读取时将来源fd的数据splice到pipe_in，然后异步请求写事件；写事件到来时从pipe_out再splice到目标fd。
    这样的流程处理常见的fd数据复制是够了，但是问题又来了，当处理网络socket描述符的时候，如果并发量很大，难道我们要为每个fd创建一对管道，那对系统是一个巨大的消耗。
    让我们看看HAProxy是怎么处理这个问题的：它用了一个pipe池，每当要做splice的时候就从里面取，不用的时候就放回去，而这个不用的时机很重要，也就是管道里的数据全部复制过去之后，这样管道只会在异步等待写出的短时间里被使用，同时的使用量就没有那么大，系统消耗就大大减小。
    以上就是一点点个人心得，希望对底层开发的程序员们有所帮助。

    写了这么多年代码，也看了这么多年别人的代码，越来越发现程序员是一个悲剧而矛盾的职业。
    至少在我写代码的时候就充满这样那样的矛盾，比如我喜欢追求运行效率，又喜欢比较优美的代码风格，却不喜欢写注释！
    而最令我苦恼的矛盾就是每个程序员会碰到但不一定会去思考的问题：自己实现，还是用现成库？
    对于懒人来说当然是直接现成的上，对天生自信喜欢一切掌握的人来说当然是自己实现。
    我在一个项目开始的时候也是倾向于自己实现的，毕竟我是个很懒的人。但项目进行到一半的时候我又往往喜欢直接抛弃第三方的库转而用自己写的，原因很简单：我对于不是自己写的东西抱有一定的戒惧之心，觉得万一出问题调试起来比较困难，自己不一定能迅速定位错误（所以我不用boost,ACE之类源代码比较绕的第三方库）。
    这大概就是多疑吧，当然也是对自己做的东西要求比较严格，做事情力求完成即完美的性格在作怪。
    暂时是没什么药可救了，期待自己能慢慢摆正开发心态咯。