REmote DIctionary Server(Redis) 是一个由Salvatore Sanfilippo写的key-value存储系统。
Redis是一个开源的使用ANSI C语言编写、遵守BSD协议(代码共享)、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
它通常被称为数据结构服务器，因为值（value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。
1. 使用redis有哪些好处？
(1) 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
(2) 支持丰富数据类型，支持string，list，set，sorted set，hash
(3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
(4) 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除
(5)、Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
2. 特性
（1）、会话缓存（Session Cache），全页缓存（FPC）
Redis提供持久化。
（2）、队列
Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为 队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。
（3）、排行榜/计数器
Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。
（4）、发布/订阅
最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统。
3，Redis作为消息中间件
Redis自带的PUB/SUB机制，即发布-订阅模式。这种模式生产者(producer)和消费者(consumer)是1-M的关系，即一条消息会被多个消费者消费，当只有一个消费者时即可以看做一个1-1的消息队列，但这种方式并不适合题主的场景。首先，数据可靠性的无法保障，题主的数据最终需要落库，如果消息丢失、Redis宕机部分数据没有持久化甚至突然的网络抖动都可能带来数据的丢失，应该是无法忍受的。其次，扩展不灵活，没法通过多加consumer来加快消费的进度，如果前端写入数据太多，同步会比较慢，数据不同步的状态越久，风险越大，可以通过channel拆分的方式来解决，虽然不灵活，但可以规避。这种方案更适合于对数据可靠性要求不高，比如一些统计日志打点。
Redis的PUSH/POP机制，利用的Redis的列表(lists)数据结构。比较好的使用模式是，生产者lpush消息，消费者brpop消息，并设定超时时间，可以减少redis的压力。这种方案相对于第一种方案是数据可靠性提高了，只有在Redis宕机且数据没有持久化的情况下丢失数据，可以根据业务通过AOF和缩短持久化间隔来保证很高的可靠性，而且也可以通过多个client来提高消费速度。但相对于专业的消息队列来说，该方案消息的状态过于简单(没有状态)，且没有ack机制，消息取出后消费失败依赖于client记录日志或者重新push到队列里面。
4, 分布式缓存的实现
通过key做一致性哈希，实现key对应redis结点的分布。
一致性哈希的实现：
hash值计算：通过支持MD5与MurmurHash两种计算方式，默认是采用MurmurHash，高效的hash计算。
一致性的实现：通过Java的TreeMap来模拟环状结构，实现均匀分布。
Redis 集群是一个分布式（distributed）、容错（fault-tolerant）的 Redis 实现， 集群可以使用的功能是普通单机 Redis 所能使用的功能的一个子集（subset）。
Redis 集群中不存在中心（central）节点或者代理（proxy）节点， 集群的其中一个主要设计目标是达到线性可扩展性（linear scalability）。
Redis 集群为了保证一致性（consistency）而牺牲了一部分容错性： 系统会在保证对网络断线（netsplit）和节点失效（node failure）具有有限（limited）抵抗力的前提下，尽可能地保持数据的一致性。
Redis集群分区原理
槽(slot)的基本概念
redis存取key的时候，都要定位相应的槽(slot)。
Redis 集群键分布算法使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一个 Redis 集群包含 16384 个哈希槽（hash slot）， 它们的编号为0、1、2、3……16382、16383，这个槽是一个逻辑意义上的槽，实际上并不存在。redis中的每个key都属于这 16384 个哈希槽的其中一个，存取key时都要进行key->slot的映射计算。
使用一致性哈希实现Redis分布式部署
像Memcache以及其它一些内存K/V数据库一样，Redis本身不提供分布式支持，所以在部署多台Redis服务器时，就需要解决如何把数据分散到各个服务器的问题，并且在服务器数量变化时，能做到最大程度的不令数据重新分布。
通常使用的分布式方法是根据所要存储数据的键的hash值与服务器数量N，按 hash % N 取模的算法来将数据分布到各个服务器。该算法的优点是足够简单，而且数据分布均匀。但是一旦服务器数量N发生变化的时候，缓存命中率会瞬间跌入谷底，因为绝大多数的数据需要重新分布。而且对于大型网站来说，此时会有巨大的压力涌向后端服务，可能会导致性能故障和服务故障，甚至宕机。
下面介绍一致性哈希，
一致性哈希
一致性hash算法通过一个叫作一致性hash环的数据结构实现。这个环的起点是0，终点是2^32 - 1，并且起点与终点连接，环的中间的整数按逆时针分布，故这个环的整数分布范围是[0, 2^32-1]，如下图3所示：
图3：一致性Hash环
最关键的区别就是，对节点和数据，都做一次哈希运算，然后比较节点和数据的哈希值，数据取和节点最相近的节点做为存放节点。这样就保证当节点增加或者减少的时候，影响的数据最少。
虚拟节点
在上图中，很容易看出一个问题，沿顺时针方向看，server2到server1之间的区间跨度大，而server1到server2的区间跨度小，这就会导致一个问题：数据分布不均匀。大部分数据都分配到server1了，只有小部分数据分布在server2。在服务器数据很少的时候，数据不均匀会表现的非常明显。
解决这个问题的方法是使用虚拟节点，一个真实服务器对应多个虚拟节点，所有虚拟节点按hash值分布在一致性哈希圆环上。具体实现方法可以这样做，为真实服务器设置副本数量，然后根据各真实服务器的IP和端口号再加上一个递增的索引数计算hash值。
副本数量可以按真实服务器的数量调节，真实服务器多则副本数量可以设置小一点，真实服务器少则副本数量需要设置多一点。在虚拟节点数量很大的时候，出于性能考虑所以不能使用循环的方法查找key对应的虚拟节点，可以使用二分法快速查找。一个优化的算法是不论副本数量设置为10，100，还是10000的时候，对查找所需要的时间基本是没有影响的。
问题：
1. 简单介绍 Redis
Redis是一个高性能的key-value数据库。Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
2. Redis 底层数据结构（数据类型、SDS、跳表、hash）
值（value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。
简单动态字符串 字符串的底层实现
链表 列表的底层实现
字典 运用在多个方面，包括Hash的实现等
跳跃表 有序集合的底层实现
整数集合 集合的底层实现之一
压缩字典 列表键和哈希键的底层实现之一
3. Redis key-value过期策略
3种过期策略
定时删除
含义：在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除
惰性删除
含义：key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null。
定期删除（结合上面两种策略）
含义：每隔一段时间执行一次删除(在redis.conf配置文件设置hz，1s刷新的频率)过期key操作
优点：
通过限制删除操作的时长和频率，来减少删除操作对CPU时间的占用--处理"定时删除"的缺点。
定期删除过期key--处理"惰性删除"的缺点。
4. 为什么 Redis 是单线程
Redis的数据结构并不全是简单的Key-Value，还有list，hash等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在hash当中添加或者删除一个对象，这些操作还可以合成MULTI/EXEC的组。这样一个操作中可能就需要加非常多的锁，导致的结果是同步开销大大增加。在权衡之后的选择是用单线程，突出自己功能的灵活性。在单线程基础上任何原子操作都可以几乎无代价地实现。避免线程锁的使用。
5. Redis 事件机制（文件事件、时间事件等）
简单说来Redis使用的事件处理机制就是通过一个主aeMain循环在单线程执行，在每一次循环中首先查看是否需要有其他阻塞的客户端或者是aof需要执行。然后在具体的aeProcessEvents中则根据传递的参数判断如何处理文件事件和时间事件。
在处理完一个事件以后我们的事件列表可能产生了变化，因而我们需要从头开始再遍历处理。
6. 持久化方式
Redis 分别提供了 RDB 和 AOF 两种持久化机制：
RDB 将数据库的快照（snapshot）以二进制的方式保存到磁盘中。单指快照这个词语的话，它表示相应数据在某个时间点的映像。
AOF 则以协议文本的方式，将所有对数据库进行过写入的命令（及其参数）记录到 AOF 文件，以此达到记录数据库状态的目的。
7. 主从复制
8. I/O 多路复用模型