尺有所短，寸有所长，看待一种技术我们不能人云亦云，而是分场景去分析。

我们先看看redis吧，

redis是一个开源的，基于内存并可持久化的日志型、Key-Value数据库，提供多种语言的API，是对传统关系型数据库的重要补充。

redis的数据类型主要有以下几种：

• string（字符串）

• hash（哈希）

• list（列表）

• set（集合）

• zset(sorted set：有序集合)

• pub/sub(发布订阅)

而且它还有以下几种特点：

读写性能优异

• 因为是内存DB，所以读写性能极其强悍
  

数据类型丰富

• string——适合最简单的k-v存储，类似于memcached的存储结构，短信验证码，配置信息等，就用这种类型来存储。

• hash——一般key为ID或者唯一标示，value对应的就是详情了。如商品详情，个人信息详情，新闻详情等。

• list——因为list是有序的，比较适合存储一些有序且数据相对固定的数据。如省市区表、字典表等。因为list是有序的，适合根据写入的时间来排序，如：最新的***，消息队列等。

• set——可以简单的理解为ID-List的模式，如微博中一个人有哪些好友，set最牛的地方在于，可以对两个set提供交集、并集、差集操作。例如：查找两个人共同的好友等。

• Sorted Set——是set的增强版本，增加了一个score参数，自动会根据score的值进行排序。比较适合类似于top 10等不根据插入的时间来排序的数据

持久化

• Redis支持多种方式将数据持久化，写入硬盘，所有，Redis数据的稳定性也是非常有保障的，结合Redis的集群方案，有的系统已经将Redis当做一种NoSql数据存储来适用。
  

单线程

• Redis 是单线程，多路复用方式提高处理效率。

• 最常用的就是分布式锁，
  

数据自动过期

• Redis针对数据都可以设置过期时间，过期的数据清理无需使用方去关注，所以开发效率和性能都比较高。最常见的就是：短信验证码、具有时间性的商品展示等。无需像数据库还要去查时间进行对比。

发布订阅

• 在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。

分布式

• Redis初期的版本官方只是支持单机或者简单的主从，大多应用则都是自己去开发集群的中间件，但是随着应用越来越广泛，用户关于分布式的呼声越来越高，所以Redis 3.0版本时候官方加入了分布式的支持。

再来说说memcache

• 简单key/value存储：服务器不关心数据本身的意义及结构，只要是可序列化数据即可。存储项由“键、过期时间、可选的标志及数据”四个部分组成。

• 功能的实现一半依赖于客户端，一半基于服务器端：客户负责发送存储项至服务器端、从服务端获取数据以及无法连接至服务器时采用相应的动作；服务端负责接收、存储数据，并负责数据项的超时过期；

• 各服务器间彼此无视：不在服务器间进行数据同步；

• O(1)的执行效率

• 清理超期数据：默认情况下，Memcache是一个LRU缓存，同时，它按事先预订的时长清理超期数据；但事实上，memcached不会删除任何已缓存数据，只是在其过期之后不再为客户所见；而且，memcache也不会真正按期限清理缓存，而仅是当get命令到达时检查其时长；

总结

Redis

优点

• 支持多种数据结构，如 string（字符串）、 list (双向链表)、dict ( hash表)、set (集合）、zset (排序 set)、hyperloglog（基数估算）。

• 支持持久化操作，可以进行 aof 及 rdb 数据持久化到磁盘，从而进行数据备份或数据恢复等操作，较好的防止数据丢失的手段。

• 支持通过 Replication 进行数据复制，通过 master-slave 机制，可以实时进行数据的同步复制，支持多级复制和增量复制，master-slave 机制是Redis 进行 HA 的重要手段。单线程请求，所有命令串行执行，并发情况下不需要考虑数据一致性问题。

• 支持 pub/sub 消息订阅机制，可以用来进行消息订阅与通知。

• 支持简单的事务需求，但业界使用场景很少，并不成熟。

缺点

• Redis 只能使用单线程，性能受限于 CPU 性能，故单实例 CPU 最高才可能达到 5-6wQPS 每秒（取决于数据结构，数据大小以及服务器硬件性能，日常环境中 QPS 高峰大约在1-2w左右）。

• 支持简单的事务需求，但业界使用场景很少，并不成熟，既是优点也是缺点。

• Redis 在 string 类型上会消耗较多内存，可以使用 dict（hash 表）压缩存储以降低内存耗用。

Memcache

优点

Memcached 可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS（取决于 key、value 的字节大小以及服务器硬件性能，日常环境中QPS 高峰大约在4-6w左右）。适用于最大程度扛量。

支持直接配置为 session handle。

缺点

• 只支持简单的 key/value 数据结构，不像 Redis 可以支持丰富的数据类型。

• 无法进行持久化，数据不能备份，只能用于缓存使用，且重启后数据全部丢失。

• 无法进行数据同步，不能将 MC 中的数据迁移到其他 MC 实例中。

• Memcached 内存分配采用 Slab Allocation机制管理内存，value 大小分布差异较大时会造成内存利用率降低，并引发低利用率时依然出现踢出等问题。需要用户注重 value 设计。

所以具体我们选择那种工具来做缓存不仅要考虑性能，开发效率还有维护成本，另外目前redis被广泛接受的还是因为它丰富的数据类型可以适应多场景需求，即维护一套服务可以提供多种解决方案。