Redis和memcache对比
redis和memcahe都是开发中经常使用的缓存组件，这篇文章对比了这两种组件的特点，以供选型时参考。
memcache
什么时候倾向于memcache？
纯KV，数据量非常大，并发量非常大的业务，使用memcache或许更适合。
内存分配
memcache使用预分配内存池的方式管理内存，能够省去内存分配时间。
redis则是临时申请空间，可能导致碎片。
从这一点上，mc会更快一些。
虚拟内存使用
memcache把所有的数据存储在物理内存里。
redis有自己的VM机制，理论上能够存储比物理内存更多的数据，当数据超量时，会引发swap，把冷数据刷到磁盘上。
从这一点上，数据量大时，mc会更快一些。
网络模型
memcache使用非阻塞IO复用模型，redis也是使用非阻塞IO复用模型。
但由于redis还提供一些非KV存储之外的排序，聚合功能，在执行这些功能时，复杂的CPU计算，会阻塞整个IO调度。
从这一点上，由于redis提供的功能较多，mc会更快一些。
线程模型
memcache使用多线程，主线程监听，worker子线程接受请求，执行读写，这个过程中，可能存在锁冲突。
redis使用单线程，虽无锁冲突，但难以利用多核的特性提升整体吞吐量。
从这一点上，mc会快一些。
Redis
什么时候倾向于选择redis？
当业务有这样一些特点的时候，选择redis会更加适合。
复杂数据结构
value是哈希，列表，集合，有序集合这类复杂的数据结构时，会选择redis，因为mc无法满足这些需求。
最典型的场景，用户订单列表，用户消息，帖子评论列表等。
持久化
mc无法满足持久化的需求，只得选择redis。
但是，这里要提醒的是，真的使用对了redis的持久化功能么？
千万不要把redis当作数据库用：
（1）redis的定期快照不能保证数据不丢失
（2）redis的AOF会降低效率，并且不能支持太大的数据量
不要期望redis做固化存储会比mysql做得好，不同的工具做各自擅长的事情，把redis当作数据库用，这样的设计八成是错误的。
缓存场景，开启固化功能，有什么利弊？
如果只是缓存场景，数据存放在数据库，缓存在redis，此时如果开启固化功能：
优点是，redis挂了再重启，内存里能够快速恢复热数据，不会瞬时将压力压到数据库上，没有一个cache预热的过程。
缺点是，在redis挂了的过程中，如果数据库中有数据的修改，可能导致redis重启后，数据库与redis的数据不一致。
因此，只读场景，或者允许一些不一致的业务场景，可以尝试开启redis的固化功能。
天然高可用
redis天然支持集群功能，可以实现主动复制，读写分离。
redis官方也提供了sentinel集群管理工具，能够实现主从服务监控，故障自动转移，这一切，对于客户端都是透明的，无需程序改动，也无需人工介入。
而memcache，要想要实现高可用，需要进行二次开发，例如客户端的双读双写，或者服务端的集群同步。
存储的内容比较大
memcache的value存储，最大为1M，如果存储的value很大，只能使用redis。