为什么redis适合操作小数据，memcache适合操作大数据

首先转载一下本文的启发来源

来源：《Is memcached a dinosaur in comparison to Redis?》(相比Redis，Memcached真的过时了吗？)

You should not care too much about performances. Redis is faster per core with small values, but memcached is able to use multiple cores with a single executable and TCP port without help from the client. Also memcached is faster with big values in the order of 100k. Redis recently improved a lot about big values (unstable branch) but still memcached is faster in this use case. The point here is: nor one or the other will likely going to be your bottleneck for the query-per-second they can deliver.

没 有必要过多的关心性能，因为二者的性能都已经足够高了。由于Redis只使用单核，而Memcached可以使用多核，所以在比较上，平均每一个核上 Redis在存储小数据时Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储 大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。说了这么多，结论是，无论你使用哪一个，每秒处理请求的次数都不会成为瓶颈。（比如 瓶颈可能会在网卡）

You should care about memory usage. For simple key-value pairs memcached is more memory efficient. If you use Redis hashes, Redis is more memory efficient. Depends on the use case.

如果要说内存使用效率，使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。当然，这和你的应用场景和数据特性有关。

You should care about persistence and replication, two features only available in Redis. Even if your goal is to build a cache it helps that after an upgrade or a reboot your data are still there.

如果你对数据持久化和数据同步有所要求，那么推荐你选择Redis，因为这两个特性Memcached都不具备。即使你只是希望在升级或者重启系统后缓存数据不会丢失，选择Redis也是明智的。

You should care about the kind of operations you need. In Redis there are a lot of complex operations, even just considering the caching use case, you often can do a lot more in a single operation, without requiring data to be processed client side (a lot of I/O is sometimes needed). This operations are often as fast as plain GET and SET. So if you don't need just GET/SET but more complex things Redis can help a lot (think at timeline caching).

当 然，最后还得说到你的具体应用需求。Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里， 你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的 GET/SET一样高效。所以，如果你需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。

现在来描述一下本文的思考主题

那么到底为什么说redis适合于操作小块类型的数据，memcache操作大块类型的数据性能更高

我的理解

小块数据的操作特点是命令密集而短小，大块数据的特点是单个命令可能引起的io耗时更长

redis是单核单线程，在操作过程上避免了线程切换的耗时，而且不需要考虑线程安全，无需获取锁、释放锁等操作。另外自己写了一套ae_event的异步IO处理机制，避免依赖于通用的libevent库，专门针对linux，只实现了redis需要的功能，代码更精悍短小。但缺点也是无法利用多核CPU的并行优势，在大量IO的处理上还是有缺陷。

memcache是多线程模型，能完全使用到多核，底层依赖的是通用的libevent库。为了保证线程安全，内部有大量的锁的代码。

所以综上所述，在高并发小数据操作场景下，memcache的指令执行次数多，线程切换次数多耗时也多，需要获取锁、释放锁的次数更多，如果锁冲突的机率高，线程等待时间变多，等于变相减小多线程处理能力，而且由于基于libevent，底层要做的通用操作可能更多一些。总之就是memcache中每个指令执行时的额外损耗较多，所以在相同的服务器环境下，memcache的指令执行密度要小于redis。

redis单线程，无法用多核并行处理，如果遇到IO量大的操作，出现等待IO的情况会增多，即使redis底层用的是异步非阻塞，IO的事件句柄也是要占用资源的。而且redis有落盘机制，数据请求会不断持久化到磁盘上，如果数据请求的IO量大，持久化占用的时间也就多，在持久化过程中redis会阻塞主线程的IO处理，那么阻塞的耗时也就多了。总结就是，redis的优势有单线程的功劳，但是弱点也是由于单线程，在大IO场景下，是天生的弱。

最终总结，memcache是由于单个指令无谓损耗较多而在指令执行效率上较差，redis是由于单核特性而在IO并行上有缺陷。