String（字符串）
string 是 redis 最基本的类型，你可以理解成与 Memcached 一模一样的类型，一个 key 对应一个 value。
string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。
string 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB。
常用命令：set、get、decr、incr、mget等。
注意：一个键最大能存储512MB。

Hash（哈希）
Redis hash 是一个键值(key=>value)对集合；是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。
每个 hash 可以存储 232 -1 键值对（40多亿）。
常用命令：hget、hset、hgetall等。
应用场景：存储一些结构化的数据，比如用户的昵称、年龄、性别、积分等，存储一个用户信息对象数据。
 

List（列表）
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。
list类型经常会被用于消息队列的服务，以完成多程序之间的消息交换。
常用命令：lpush、rpush、lpop、rpop、lrange等。
列表最多可存储 232 - 1 元素 (4294967295, 每个列表可存储40多亿)。
 

Set（集合）
Redis的Set是string类型的无序集合。和列表一样，在执行插入和删除和判断是否存在某元素时，效率是很高的。集合最大的优势在于可以进行交集并集差集操作。Set可包含的最大元素数量是4294967295。
集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。
应用场景：
1、利用交集求共同好友。
2、利用唯一性，可以统计访问网站的所有独立IP。
3、好友推荐的时候根据tag求交集，大于某个threshold（临界值的）就可以推荐。
常用命令：sadd、spop、smembers、sunion等。
集合中最大的成员数为 232 - 1(4294967295, 每个集合可存储40多亿个成员)。

zset(sorted set：有序集合)
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的,但分数(score)却可以重复。
sorted set是插入有序的，即自动排序。
常用命令：zadd、zrange、zrem、zcard等。
当你需要一个有序的并且不重复的集合列表时，那么可以选择sorted set数据结构。
应用举例：
（1）例如存储全班同学的成绩，其集合value可以是同学的学号，而score就可以是成绩。
（2）排行榜应用，根据得分列出topN的用户等。

而Memcached默认使用SlabAllocation机制管理内存，其主要思想是按照预先规定的大小，将分配的内存分割成特定长度的块以存储相应长度的key-value数据记录，以完全解决内存碎片问题。

从内存利用率来讲，使用简单的key-value存储的话，Memcached的内存利用率更高。而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。

3、性能不同
由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis也在存储大数据的性能上进行了优化，但是比起Memcached，还是稍有逊色。

4、集群管理不同
Memcached是全内存的数据缓冲系统，Redis虽然支持数据的持久化，但是全内存毕竟才是其高性能的本质。作为基于内存的存储系统来说，机器物理内存的大小就是系统能够容纳的最大数据量。如果需要处理的数据量超过了单台机器的物理内存大小，就需要构建分布式集群来扩展存储能力。
Memcached本身并不支持分布式，因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。相较于Memcached只能采用客户端实现分布式存储，Redis更偏向于在服务器端构建分布式存储。

小结：Redis和Memcached哪个更好？
Redis更多场景是作为Memcached的替代者来使用，当需要除key-value之外的更多数据类型支持或存储的数据不能被剔除时，使用Redis更合适。如果只做缓存的话，Memcached已经足够应付绝大部分的需求，Redis 的出现只是提供了一个更加好的选择。总的来说，根据使用者自身的需求去选择才是最合适的。

首先说下原因：
1.redis是基于内存的，内存的读写速度非常快，数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
2.redis是单线程的，省去了很多上下文切换线程的时间；
3.数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
3.redis使用多路复用技术，可以处理并发的连接；
简单解释下第二条：上下文切换就是cpu在多线程之间进行轮流执行（枪战cpu资源），而redis单线程的，因此避免了繁琐的多线程上下文切换。
重点解释下 多路复用：多路-指的是多个socket连接，复用-指的是复用一个线程。目前，多路复用主要有三种技术：select，poll，epoll。它们出现的顺序是时间先后顺序，越排后的技术改正了之前技术的缺点。epoll是最新的也是目前最好的多路复用技术。

一个epoll场景：一个酒吧服务员（一个线程），前面趴了一群醉汉，突然一个吼一声“倒酒”（事件），你小跑过去给他倒一杯，然后随他去吧，突然又一个要倒酒，你又过去倒上，就这样一个服务员服务好多人，有时没人喝酒，服务员处于空闲状态，可以干点别的玩玩手机。至于epoll与select，poll的区别在于后两者的场景中醉汉不说话，你要挨个问要不要酒，没时间玩手机了。io多路复用大概就是指这几个醉汉共用一个服务员。

Redis 提供两种持久化机制 RDB 和 AOF 机制:
RDB(Redis DataBase)持久化方式：是指用数据集快照的方式半持久化模式) 记录 redis 数据库的所有键值对,在某个时间点将数据写入一个临时文件。
持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。

优点：
1、只有一个文件 dump.rdb，方便持久化。
2、容灾性好，一个文件可以保存到安全的磁盘。
3、性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能)
4.相对于数据集大时，比 AOF 的启动效率更高。

缺点：
1、数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生 故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)


AOF(Append-only file)持久化方式：是指所有的命令行记录以 redis 命令请 求协议的格式完全持久化存储)保存为 aof 文件。

优点：
1、数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次。
2、通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
3、AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)

缺点：
1、AOF 文件比 RDB 文件大，且恢复速度慢。
2、数据集大的时候，比 rdb 启动效率低

将no-appendfsync-on-rewrite的配置设为yes可以缓解这个问题，设置为yes表示rewrite期间对新写操作不fsync，暂时存在内存中，等rewrite完成后再写入。最好是不开启Master的AOF备份功能。

4.Redis主从复制的性能问题，第一次Slave向Master同步的实现是：Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。第二次以及以后的同步实现是：Master将变量的快照直接实时依次发送给各个Slave。不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从复制是建立在内存快照的持久化基础上，只要有Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞，但由于磁盘io的限制，如果Master快照文件比较大，那么dump会耗费比较长的时间，这个过程中Master可能无法响应请求，也就是说服务会中断，对于关键服务，这个后果也是很可怕的。

以上1.2.3.4根本问题的原因都离不开系统io瓶颈问题，也就是硬盘读写速度不够快，主进程 fsync()/write() 操作被阻塞。

5.单点故障问题，由于目前Redis的主从复制还不够成熟，所以存在明显的单点故障问题，这个目前只能自己做方案解决，如：主动复制，Proxy实现Slave对Master的替换等，这个也是Redis作者目前比较优先的任务之一，作者的解决方案思路简单优雅，详情可见 Redis Sentinel design draft http://redis.io/topics/sentinel-spec。

一，redis主节点过期key的删除策略

1，定时删除：在设置键的过期时间的同时，创建一个timer，让定时器在键的过期时间到达时，立即执行对键的删除操作。（主动删除）

优缺点：对内存友好，但是对cpu时间不友好，有较多过期键的而情况下，删除过期键会占用相当一部分cpu时间。

2，定期删除：每隔一段时间就对数据库进行一次检查，删除里面的过期键。（主动删除）

优缺点：采用对内存和cpu时间折中的方法，每个一段时间执行一次删除过期键操作，并通过限制操作执行的时长和频率来减少对cpu时间的影响。难点在于，选择一个好的策略来设置删除操作的时长和执行频率。

3，惰性删除：放任过期键不管，但是每次从键空间中获取键时，都检查取到的键是否过去，如果过期就删除，如果没过期就返回该键。（被动删除）

优缺点：对cpu时间友好，程序只会在取出键的时候才会对键进行过期检查，这不会在删除其他无关过期键上花费任何cpu时间，但是如果一个键已经过期，而这个键又保留在数据库中，那么只要这个过期键不被删除，他所占用的内存就不会释放，对内存不友好。

二，redis从节点过期key的删除策略

从节点过期key是如何删除的呢？主节点在key到期时，会在AOF文件里增加一条del指令。AOF文件被同步到从节点以后，从节点根据AOF中的这个del指令来执行删除过期key的操作。

从节点的这个过期key的处理策略，会导致一个问题，主节点已经删除的key，在从节点还是存在的。因为AOF同步del指令是异步的。

还有一个关键点，《redis深度》历险那本书这样写的：从节点不会过期扫描，从节点对过期的处理是被动的。