[toc]

Redis是什么

Redis是C语言开发的一个开源的高性能键值对(key-value)的内存数据库，可以用作数据库、缓存、消息中间件等。
这是一种NoSQL的数据库。Redis作为一个内存数据库：

性能优秀，数据在内存中，读写速度非常快，支持并发10W QPS。
单进程单线程，是线程安全的，采用IO多了复用机制。
丰富的数据类型，支持字符串(strings)、散列(hash)、列表(lists)、集合(sets)和有序集合(sorted sets)等。
支持数据持久化，可以将内存中的数据保存在磁盘中，重启时加载
可以用作分布式锁。
可以作为消息中间件使用，支持发布订阅

五种数据类型

string 是redis的最基本的类型，可以理解成与Memcached一模一样的类型，一个key对应一个value，values不仅是String，也可以是数字，String类型是二进制安全的，意思是Redis的String类型可以包含任何数据，比如jpg图片或者序列化对象，String类型值最大能存储512M。
hash是一个键值对(key-value)的集合，Redis的Hash是一个String的key和Value的映射表，hash特别适合存储对象，常用命令：hget、hset、hgetall等。
list链表是最简单的字符串链表，按照插入顺序排序，可以添加一个元素到链表的头部(左边)或者尾部(右边)常用命令：lpush、rpush、lpop、rpop、lrange(获取列表的片段)等。
- 应用场景：list应用场景非常多，也是redis最重要的数据结构之一，比如Twitter的关注列表，粉丝列表都可以用list结构来实现。
- 数据结构：list就是链表，可以当消息队列用，redis提供了push和pop操作，还提供了操作某一段的API，可以直接查询或者删除某一段元素。
- 实现方式：readis list的实现是一个双向链表，既可以支持反向查找和遍历，更方便操作，不过带来额外的内存开销。
set是String类型的无序集合，集合通过hashtable实现的，set的元素是没用顺序的，而且是没用重复的，常用命令：sdd、spop、smembers、sunion等。
- 应用场景：set对外提供的功能和list一样是一个列表，特殊之处在于set是自动去重的，而且set提供了判断某个成员是否在一个set集合中。
Zset和set一样是string类型元素集合，且不允许重复元素，常用命令：zdd、zrange、zrem、zcard等
- 使用场景Sorted set可以通过用户额外提供的一个优先级(score)的参数来为成员排序，并且插入有序的，即自动排序，当需要一个有序的并且不重复的集合列表，那么可以选择sorted set
- 和set相比sorted set关联了一个double类型权重的参数score的参数，使得集合中的元素能够按照score进行有序排列，redis正是通过分数来为集合中成员进行从小到大的排序。
- 实现方式：redis sorted set的内部使用HashMap和跳跃表(skipList)来保证数据的存储和有序，hashMap里存放的成员到score的映射，而跳跃表里存放的是所有的成员，排序依据hashMap里存的score，使用跳跃表的结构可以获得比较高的查询效率，并且实现上比较简单。

数据类型应用场景总结：

类型	简介	特性	场景
string	二进制安全	可以包含任何数据，比如jpg图片或者序列话对象
hash	键值对集合，即编程语言中的map类型	适合存储对象，并且可以像数据库中的update一个树形一样只修改某一项属性值	存储、读取、修改用户属性
list	链表(双向链表)	增删快，提供了操作某一元素的api	最新消息排列，可以充当队列和栈使用，消息队列
set	hash表实现、元素不重复	添加删除查找的复杂度都是O(1)提供了求交集，并集，差集等操作	共同好友，利用唯一性
sorted set	将set中元素增加一个权重参数score元素按照score有序排列	数据插入集合时，已经进行了天然排序	排行榜，带权重的消息队列。

缓存问题

缓存会出现的问题，缓存穿透，缓存击穿，缓存雪崩，热点数据失效

image

穿透

正常情况下，查询数据都是存在，那么请求查询一条根本不存在的数据，也就是缓存和数据库都查询不到这条数据，但是请求每次都会打到数据库上面，这种查询不存在的数据的现象就是缓存穿透 。

缓存穿透带来的问题：比如拿一个不存在的ID查询数据，产生大量请求到数据库中查询，可能导致数据库压力过大而宕机。

解决办法：

缓存空值
- 之所以会发生从穿透，就是因为缓存中没有存储这些空的key，从而导致每次查询都到数据库中查询，那么我们可以为这些key设置为null丢到缓存里面，后面在出现查询这个key的请求就直接返回null，并且设置一个较短的过期时间，这样就不需要到数据库中查询了，但是需要设置过期时间。
使用BloomFilter(布隆过滤器有一个问题，存在的不一定存在，不存在的一定不存在)
- BloomFilter类似一个Hbase set用来判断某个元素(key)是否存在某个集合中，这种方式在大数据场景应用比较多，比如Hbase中使用他去判断数据是否在磁盘上，还有爬虫场景判断URL是否被爬取，这种方案可以在第一种方案中，在缓存之前再加一层BloomFilter，在查询时候先去BloomFilter查询key是否存在，如果不存在直接返回，如果存在再走缓存->DB。流程图如下。
  
  image

如何选择？

针对一些恶意攻击，攻击带来大量的key是不存在的，那么我们采用第一种方式会缓存大量的不存在的key的数据，此时采用第一种就不合适，我们需要采用第二种方式进行过滤掉这些key，针对key异常多，请求重复率比较低的数据，没必要缓存，使用第二种直接过滤掉
空数据的key有限，重复率比较多，我们采用第一种方式进行缓存

缓存击穿

在平常高并发系统中，大量的请求同时查询一个key，此时这个key正好失效，就会导致大量的数据请求到数据库中，这种现象称为缓存击穿

带来的问题？

会造成某一时刻数据库请求量过大，压力剧增

如何解决？

上面现象中是多个线程查询数据库的这条数据，我们可以在第一个查询数据的请求上使用一个互斥锁，其他线程走到这一步拿不到锁就等着，等第一个线程拿到数据，然后做缓存，后面的线程进来发现已经有缓存了，就直接使用缓存。

热点数据集中失效

我们设置缓存的时候，一般会给缓存设置一个失效时间，过了这个时间，缓存失效，对于一些热点数据来说，当缓存失效以后会存在大量的请求过来，然后直接打到数据库中，从而导致数据库崩溃这情况就是热点数据集中失效

如何解决？

设置不同的失效时间，为了避免这些热点的集中失效，那么我们在设置缓存过期时间的时候，让他们的失效时间错开，比如在一个基础时间上加一个或者减去一个范围内的随机值。
互斥锁，结合上面击穿的情况，在第一个请求数据库的时候对他加一个互斥锁，其余的查询请求都会被阻塞，直到锁被释放，从而保护数据库，但是由于回阻塞其他线程，此时系统吞吐量会下降，需要结合业务去考虑是否需要这么做

雪崩

缓存雪崩的额情况是说，当某一时刻发生大规模的缓存失效问题，比如缓存服务宕机会有大量的请求直接打到DB上，结果DB撑不住，挂掉。

解决方法：

事前：使用集群缓存，保证缓存服务器的高可用，这种方案就是发生雪崩时对缓存集群实现高可用，如果使用redis，可以使用主从+哨兵，Redis Cluster来避免redis全盘崩溃的情况。
事中：ehcache本地缓存+Hystrix限流&降级，避免MySQL被打死
- 使用ehcahe本地缓存的目的也是考虑Redis Cluster完全不可用的时候，ehcache本地缓存还能支撑一阵
- 使用Hystrix限流&降级，比如一秒来了5000个请求，可以设置假设只能一秒2000个，就能通过这个组件内，其他的剩余3000个走限流逻辑，然后调用自己开发的降级组件，比如设置一些默认值，来保护最后MySQL不会被大量请求打死。
事后：开启Redis的持久化，尽快回复缓存集群，一旦重启后，就能从磁盘中，自动加载数据恢复内存中的数据。

redis为何是单线程

redis是单进程单线程的模型，因为redis完全基于内存操作，cpu不是redis的瓶颈，redis的瓶颈最有可能是机器的内存大小或者网络带宽。

既然单线程容易实现，而且cpu不会成为瓶颈，那就数量成章的采用单线程的方案了(毕竟采用单线程会有很多麻烦)

redis为何那么快

redis是单线程，为什么还能这么快？总结一下有四点

redis完全基于内存，觉大部分请求是纯粹的内存操作，非常迅速，数据存在内存中，类似与HashMap，HashMap的优势就是查找和操作的时间复杂度是O(1)
数据结构简单，对数据操作也简单
采用单线程，避免了不必要的上下文切换和竞争条件，不存在多线程导致的CPU切换，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有死锁问题导致的性能消耗
使用多路复用IO模型，非阻塞IO

redis和Memcached的区别

存储方式上：Memcached会把数据全部存在内存中，断电后会挂掉，数据不能超过内存大小，Redis有部分数据存在硬盘上，这样能保证数据的持久性
数据支持类型上：Memcache对数据类型支出简单，只支持简单的key-value，而redis支持五种数据类型
使用底层模型不同：他们之间底层实现方式以及与客户端通信的应用协议不一样，redis直接自己构建了VM机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求
value的大小：redis可以达到1GB，而Memcache只有1MB。

淘汰策略

redis六种淘汰策略如下：

策略	描述
volatile-lru	从已设置过期时间的kv集中优先对最近最少使用(LRU策略)的数据淘汰
volatile-ttl	从已设置过期时间的kv集中优先对剩余时间短的数据淘汰
volatile-random	从设置过期时间的kv集中随机选择数据淘汰
allkeys-lru	从所有kv集中优先对最近最少使用(LRU策略)的数据淘汰
allkeys-random	从所有kv集中选择数据淘汰
noeviction	不淘汰，若超过最大内存，返回错误信息

注：redis 4.0加入了LFU(最不经常使用的)淘汰策略，包含volatile-lfu和allkeys-lfu，通过统计访问频率，将访问频率最少，即最不经常使用的KV淘汰

持久化

Redis的持久化策略有两种：

RDB：快照形式是直接把内存中的数据保存到一个dump文件中，定时保存的保存策略
AOF：把所有的对Redis的服务器进行修改的命令都存到一个文件里，命令的集合。

Redis默认是快照RDB的持久化方式。

当RDB与AOF两种方式都开启时，Redis会优先使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整。

RDB

默认Redis是会以快照RDB的形式将数据持久化到磁盘的一个二进制文件dump.rdb。

工作原理：当Redis需要做持久化时，Redis会fork一个子进程，子进程将数据写到磁盘上一个临时的RDB文件中，当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处是可以copy-on-write。

优点：这种文件非常适合用于备份，比如可以在最近24小时内。
缺点：如果需要尽量避免在服务器故障时丢失数据，那么RDB不合适因为，会丢失一部分数据

AOF

AOF可以做到全程持久化，只需要在配置中开启appendonly yes，这样redis每执行一个修改数据的命令，都会把他添加到AOF文件中，当redis重启是，将会读取AOF文件进行重放，恢复到redis关闭前的最后一刻。

优点：使用AOF会让redis变的非常耐久，可以设置不同的Fsync策略，AOF的默认策略时每秒钟Fsync一次，在这种配置下，就算发生停机，也最多丢失一秒钟的数据。
缺点，对于相同数据集来说，AOF的文件体积通常大于RDB文件的体积，根据使用的Fsync策略，AOF的速度可能会慢于RDB

持久化总结

如果非常关心数据，但是仍然可以承受数分钟的数据丢失，那么可以只使用RDB持久，AOF将Redis执行的每一条命令追加到磁盘中，处理巨大的写入会降低Redis的性能。

数据库备份和灾难恢复：定时生成RDB快照非常便于进行数据库备份，并且RDB恢复数据集速度也要比AOF恢复速度快。

当然，Redis支持同时开启RDB和AOF，系统重启后，Redis优先使用AOF恢复数据，这样丢失数据会最少。

主从复制

Redis单节点存在单点故障问题，为了解决单点问题，一般都需要对Redis配置从节点，然后使用哨兵来监听主节点的存活状态，如果主节点挂掉，从节点能够提供缓存功能。

关于主从复制过程：

从节点执行slaveof[masterIP][masterPort]保存主节点信息
从节点中的定时任务发现主节点信息，建立和主节点的Socket链接
从节点发送ping信号，主节点返回pong，两边能互相通信
链接建立后，主节点将所有数据发送给从节点(数据同步)
主节点把当前的数据同步给从节点后，便完成了复值的建立过程，接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

同步过程

Redis2.8之前使用sync[runId][offset]同步命令，redis2.8之后使用psynch[runId][offset]命令。

两者不同在于Sync命令仅支持全量复制过程，Psync支持全量和部分复制。

runId：每个redis节点启动都会生成唯一的uuid，每次redis重启后，runid都会发生变化。
offset：主节点和从节点都各自维护自己的主从复制偏移量offset，当主节点有写入命令时，offset=offset+命令的字节长度，从节点在收到主节点发送的命令后，也需要增加自己的offset，并把自己的offset发送给主节点，这样主节点同时保存自己的offset和从节点offset，通过对比offset来判断主从节点数据是否一致。
repl_backlog_size：保存在主节点上的一个固定长度的先进先出队列，默认大小是1MB

主节点发送数据给从节点，主节点还会进行写操作，这时候的数据存储在复制的缓冲区中。

从节点同步主节点数据完成后，主节点将缓冲区的数据继续发送给从节点，用于部分复制。

主节点响应写命令时，不但会把命令发送给从节点，还会写入复制积压缓冲区，用于复制命令丢失的数据补救。