作者：Gamer_young
链接：https://www.jianshu.com/p/0cee8085fc8f
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
使用场景：
一、如果需要缓存的数据只是key-value 这样简单的结构时，采用Memcache，足够稳定可靠。如果有持久化需求、存储、排序等一系列复制操作时，或者对数据结构和处理有高级要求的应用，选择Redis。
二、memcache使用场景：
1、在动态系统中减少数据库负载，提升性能，做缓存，适合多读少写，大数据量的情况（如人人网大量查询用户信息、好友信息、文章信息等）。它的一个总原则是将经常需要从数据库读取的数据缓存在memcached中，这些数据也分为几类：
（1）经常被读取并且实时性要求不强可以等到自动过期的数据。例如网站首页最新文章列表、某某排行等数据。也就是虽然新数据产生了，但对用户体验不会产生任何影响的场景。这类数据就使用典型的缓存策略，设置一过合理的过期时间，当数据过期以后再从数据库中读取。当然你得制定一个缓存清除策略，便于编辑或者其它人员能马上看到效果。
（2）经常被读取并且实时性要求强的数据。比如用户的好友列表，用户文章列表，用户阅读记录等。这类数据首先被载入到memcached中，当发生更改（添加、修改、删除）时就清除缓存。在缓存的时候，我将查询的SQL语句md5（）得到它的 hash值作为key,结果数组作为值写入memcached，并且将该SQL涉及的table_name以及hash值配对存入memcached中。 当更改了这个表时，我就将与此表相配对的key的缓存全部删除。
2、秒杀功能：一个人下单，要牵涉数据库读取，写入订单，更改库存，及事务要求， 对于传统型数据库来说，压力是巨大的。
可以利用 memcached 的 incr/decr 功能， 在内存存储 count 库存量， 秒杀 1000 台每人抢单主要在内存操作，速度非常快，抢到 count < =1000 的号人，得一个订单号，这时再去另一个页面慢慢支付。
三、不适用memcached的业务场景：
1、缓存对象的大小大于1MB；
2、key的长度大于250字符（所以我们把一些key先md5再存储）；
3、应用运行在不安全的环境中Memcached为提供任何安全策略，仅仅通过telnet就可以访问到memcached。如果应用运行在共享的系统上，需要着重考虑安全问题；
4、业务本身需要的是持久化数据。
四、Redis场景：适用于对读写效率要求都很高，数据处理业务复杂和对安全性要求较高的系统（如新浪微博的计数和微博发布部分系统，对数据安全性、读写要求都很高）、Pub/Sub构建实时消息系统、统计。
区别：
1、存储方式：Memcache把数据全部存在内存之中，断电后会挂掉，数据不能超 过内存大小。Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启时可以再次加载进行使用。（RDB快照和AOF日志两 种持久化方式）。
2、Redis支持数据的备份，及master-slave模式的数据备份。
3、数据支持类型：Redis在数据支持上要比Memcache多得多。
4、使用底层模型不同：新版本的Redis直接自己构建了VM机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
5、 redis有一个致命缺陷 当内存满了时 dump数据cpu占用100%。
总结：
1、Redis使用最佳方式是全部数据in-memory。
2、Redis更多场景是作为Memcache的替代者来使用。
3、当需要除key/value之外的更多数据类型支持时，使用Redis更合适。
4、当存储的数据不能被剔除时，使用Redis更合适。
5、如果要说内存使用效率，使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。当然，这和你的应用场景和数据特性有关。