memcached为何物?

第一次听出 memcached是在 JavaEye上。好多人在讨论通过memcached保存一些信息，减少对数据库的操作。从其他网站上了解了一些关于它的说明：
memcached是一个高性能的分布式的内存对象缓存系统，通过在内存里维护一个统一的巨大的hash表，它能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。

memcached的代码非常少，只有6个标准C文件，代码行也不多，估计花一天时间就可以研究透彻。

首先了解memcached的中心思想，就如上面所说的，是一个巨大的hash表，就key，value对。客户端通过socket设置、获得、替换、删除key以及对应的value。这么说来还是比较简单的。

memcached.c为程序的主代码，包含了入口main、处理socket协议等功能。它使用了libevent处理协议，在Linux下是epoll方式。

slabs.c内存管理模块，就是存储客户端需要设置的key和value。slabs事先创建一系列不同字节数的数组，比如默认情况下创建8K个128字节数组，4K个256字节数组，2K个512字节数组等，依次类推，当然字节数不同，相应的数组大小也是不同的，这里的128、256等数值对应的1，2等称为clsid，clsid最大为200，最大字节数为1M（所以上面描述能够保存图片和视频是不可能的）。memcached武断地认为字节数越大，出现的几率越小，数组大小也越小。难道实际情况就是这样的吗？

items.c主要功能是处理key、value，当然远没有这么简单。它使用了链表保存不同的item。其中不同长度的key+value对应的item放到最接近clsid的数组中，比如长度为200的就放到256对应的数组中，呵呵，还挺浪费的。这里有两个链表，一个是clsid相同的item组成一个链表，这个链表是双向的，它们的clsid都相同；另外一个就是key的hash值相同的链表，这个链表是单向的，主要解决hash冲突的，它们的hash值都相同。这也是查找key的最快方法，为什么不用红黑树呢？

assoc.c就比较简单了，就是一个大数组，以item中key的hash值为数组的下标，数组的值就是一个item值，由于item是链表，所以后面就有一组相同hash值的item链表。

daemon.c是精灵程序代码，纳闷为什么只fork了一次，按照经典的做法是要fork两次的。

thread.c是处理多线程的代码，由于memcached是非阻塞的方式处理socket的（使用libevent特性），理论上讲多线程不会提升性能，除非有多个CPU，一个CPU对应一个线程。

整个代码中，自己感觉“池子”很多，这可能是从性能上考虑的吧。比如slabs、thread中都使用到了内存池，thread中使用了线程池（比较简单而已）。

memcached代码写得比较简洁，实现很巧妙，性能也非常高。