memcache到底有多快？

最近工作原因要将memcached里的某些KEY值找出来并删除掉这些KEY对应的数据，由于工程师只是简单的使用get\set存取数据，没有使用分层索引模型，于是只能遍历cache集群的所有key数据了，一开始挺担心效率问题，因为最早使用memcached的时候就被先辈告知1毫秒只能操作一个数据，而目前的集群里已经有了近300万条数据，这样就至少需要50分钟进行处理，因为这个cache集群里含有不少被多个应用共用的有效数据，还是小担心了一把，但是不处理又不行，于是硬着风险让工程师写了一个程序去遍历处理。

结果。。。。。。。。。。。。。。。。
。。。。。。。。。。。。。。。。
。。。。。。。。。。。。。。。。

结果，嘿嘿，相当乐观，通过测试发现本机处理本地测试用memcached集群,6万3千条数据的遍历完毕才花了3秒时间，百兆局域网内的生产memcached集群近300万条数据处理（有部分数据已经过期无法取出故实际只有240多万条）完毕也就是5分钟的时间，于是乎得出一个实验结论：memcached本机处理每秒2万1K多条，远程方式也能达到近8K条/秒（与网络ping的数据比较后发现本地连接和远程连接网络速度平均值上正好相差接近2.5倍左右），看来应用中如果没有对大型对象处理时的序列化反序列化所消耗的时间，只是查找和删除，memcached的效率还是相当可观的，看来即时在相对高并发量的WEB2.0应用中(一般每秒8K级别以下的并发应用中，日访问量达到7亿以下的)，大可放心采用memcached集群作为高效的用户会话缓存器或全局计数器进行实施，只要在程序上做好设计和避免过多低效的操作语句，基本上不用考虑并发时会产生数据不准或相互覆盖的现象了。

当然，另一个问题又来了，每日超过10亿的超大访问量怎么办？一个立竿见影的办法就是从网络层提高局域网内各服务器间数据传输效率，如果提高到接近本地操作的话，最高可支撑20亿/日的访问量，如果还超过这个数的话，嘿嘿，真到这个时候再说吧，又有多少网站能达到这个级别呢？