概述

什么是Redis

Redis是一个使用C语言编写的，开源的高性能非关系型的键值对数据库。

Redis可以存储键和五种不同类型的值之间的映射，键的类型只能为字符串，值支持五种数据类型：String，List，Set，Hash，ZSet。

与传统数据库不同的是Redis的数据是存储在内存中，所以读写速度非常快，因此Redis被广泛应用在缓存方向，每秒可以处理超过10万次读写操作，是已知性能最快的key-value 数据库，另外，Redis也经常用来做分布式锁，除此之外，Redis支持事务，持久化，LUA脚本，LRU驱动事件，多种集群方案。

Redis有哪些优缺点

优点：

读写性能优异，Redis能读的速度是110000次/s，写的速度是81000次/s
支持数据持久化，支持AOF和RDB两种持久化方式。
支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行；
数据结构丰富，除了支持String类型的value外，还支持hash，set，zset，list等数据结构；
支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

缺点：

数据库容量受到物理内存的限制，不能做海量数据的高性能读写，因此Redis适合的场景主要局限于较小数据量的高性能操作和运算上；
Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或手动切换前端的IP才能恢复；
主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引起数据不一致的问题，降低了系统的可用性；
Redis在线扩容比较复杂，当集群容量达到上限时在线扩容会变得很复杂，为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

为什么要用缓存？

主要从“高性能”和“高并发”这两点来看待这个问题。

高性能：

在这里插入图片描述

高并发：

直接操作缓存能够承受的请求是远远大于直接访问数据库的。
在这里插入图片描述

为什么要用Redis而不用map/guava做缓存

缓存分为本地缓存和分布式缓存，以Java为例，使用自带的map或者guava实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着JVM的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性。

使用Redis或Memcached之类的称为分布式缓存，在多实例的情况下，各实例共用一份缓存数据，缓存具有一致性，缺点是需要保持Redis或Memcached服务的高可用，整个程序架构上较为复杂。

Redis为什么这么快

完全基于内存，绝大部分请求都是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，查找和操作的时间复杂度都为O(1)；
数据结构简单，对数据操作也简单，Redis的数据结构是专门进行设计的；
采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，因为没有可能出现死锁而导致的性能消耗；
使用多路I/O复用模型，非阻塞IO；
使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接构建了VM机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

数据类型

Redis有哪些数据类型

在这里插入图片描述

Redis的应用场景

场景一

计数器
可以对String进行自增自减运算，从而实现计数器功能，Redis这种内存型数据库的读写性能非常高，很适合存储频繁读写的计数量。
缓存
将热点数据放到内存中，设置内存的最大使用量以及淘汰策略来保证缓存的命中率。
会话缓存
可以使用Redis来统一存储多台应用服务器的会话信息，当应用服务器不再存储用户的会话信息，也就不再具有状态，一个用户可以请求任意一个应用服务器，从而更容易实现高可用性以及可伸缩性。
查找表
例如DNS记录就很适合使用Redis进行存储，查找表和缓存类似，也是利用了Redis快速的查找特性，但是查找表的内容不能失效，而缓存的内容可以失效，因为缓存不作为可靠的数据来源。
消息队列（发布/订阅功能）
List是一个双向链表，可以通过lpush和rpop写入和读取消息，不过最好使用Kafka，RabbitMQ等消息中间件。
分布式锁实现
在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步，可以使用Redis自带的SETNX命令实现分布式锁，除此之外，还可以使用官方提供的RedLock分布式锁实现。
其他
Set可以实现交集，并集操作，从而实现共同好友等功能，ZSet可以实现有序性操作，从而实现排行榜等功能。

场景二

Redis相比其他缓存，有一个非常大的优势，就是支持多种数据类型。

String–适合最简单的k-v存储，类似于Memcached的存储结构，短信验证码，配置信息等，就用这种类型来存储；
hash–一般key为ID或者唯一标识，value对应的就是详情了，如商品详情，个人信息详情，新闻详情等；
list–有序，比较适合存储一些有序且数据相对固定的数据，如：省市区表，字典表等，因为list是有序的，适合根据写入的时间来排序，如：消息队列等；
set–可以简单理解为ID-list模式，如微博中一个人有哪些好友，可以对两个set提供交集，并集，差集操作，例如：查找两个人共同的好友等；
Sorted Set–是set的增强版本，增加了一个score参数，自动会根据score的值进行排序，比较适合类似于top10等不根据插入的时间来排序的数据。

持久化

什么是Redis持久化

持久化就是把内存的数据写到磁盘中去，防止服务宕机导致内存数据丢失。

Redis持久化机制是什么？各自的优缺点？

Redis提供了两种持久化机制RDB（默认）和AOF机制。

RDB

RDB：默认的持久化方式，按照一定的时间将内存的数据以快照的形式保存到磁盘中，对应产生的数据文件为dump.rdb，有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE，（SAVE会阻塞Redis服务器进程，直到RDB文件创建完毕，BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程继续处理请求命令）。
在这里插入图片描述
优点：

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

缺点：

数据安全性低，RDB是间隔一段时间进行持久化，如果持久化之间Redis发生故障，会发生数据丢失，所以这种方式更适合数据要求不高的情况；

AOF

AOF持久化（Append Only File）是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。

当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。
在这里插入图片描述
优点：

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

缺点：

AOF文件比RDB文件大，且恢复速度慢
数据集大的时候，AOF启动效率低

如何选择合适的持久化方式

一般来说，如果是想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能，在这种情况下，当Redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集更完整；
如果你非常关心你的数据，但仍可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化；
有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生成RDB快照非常便于进行数据库备份，并且RDB恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免AOF程序的bug；
如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式；

Redis持久化数据和缓存怎么做扩容

如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容；
如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化，如果Redis节点需要动态变化，必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。

过期键的删除策略

Redis key的过期时间和永久有效分别怎么设置

EXPIRE和PERSIST命令。

Redis的过期键的删除策略

Redis是key-value数据库，我们可以设置Redis中缓存的key的过期时间，Redis的过期策略就是指当Redis中缓存的key过期了，Redis如何处理。
过期策略通常有三种：

定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除，该策略可以立即清除过期的数据，对内存很友好，但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期就清除，该策略可以最大化的节省CPU资源，却对内存非常不友好，极端情况下可能会出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key，该策略是前两者的一个折中方案，通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。
（expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向进键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间，键空间是指该Redis集群中保存的所有键。）

Redis同时使用了惰性过期和定期过期两种过期策略。

内存相关

MySQL里有2000w数据，Redis中只有20w的数据，如何保证Redis中的数据都是热点数据

Redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。

Redis的内存淘汰策略有哪些

Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。

全局的键空间选择性移除

noeviction：当内存不足以容纳新写入数据时，新写入操作会报错；
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。
allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

设置过期时间的键空间选择性移除

volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key；
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key；
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

Redis主要消耗什么物理资源

内存

Redis的内存用完了会发生什么

如果达到设置的上限，Redis的写命令会返回错误信息（读命令还可以正常返回），或者你可以配置内存淘汰机制，当Redis达到内存上限时会冲刷掉旧的内容。

Redis如何做内存优化

可以好好利用Hash，list，sorted set，set等集合类型数据，因为通常情况下很多小的key-value可以用更紧凑的方式存放到一起，尽可能使用散列表（hash），散列表使用的内存非常小，所以你应该尽可能地将你的数据模型抽象到一个散列表中，比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户的所有信息存储到一张散列表里面。

事件

Redis服务器是一个事件驱动程序，服务器需要处理以下两类事件：

文件事件：服务器与客户端（或其他服务器）的通信会产生相应的文件事件，而服务器则通过监听并处理这些事件来完成一系列网络通信操作。
时间事件：Redis服务器中的一些操作需要在给定的时间点执行，而时间事件就是服务器对这类定时操作的抽象。

文件事件

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器，它的组成结构为4部分：多个套接字，IO多路复用程序，文件事件分派器，事件处理器。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。

文件事件处理器使用I/O多路复用程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
当被监听的套接字准备好执行连接应答（accept），读取（read），写入（write），关闭（close）等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

虽然文件事件处理器以单线程方式运行，但通过使用I/O多路复用程序来监听多个套接字，文件事件处理器既实现了高性能的网络通信模型，又可以很好地与Redis服务器中其他同样以单线程方式运行的模块进行对接，这保持了Redis内部单线程设计的简单性。

事务

什么是事务

事务是一个单独的隔离操作：事务中的所有命令都会序列化，按顺序执行，事务在执行过程中，不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

Redis事务的概念

Redis事务的本质是通过MULTI，EXEC，WATCH等一组命令的集合，事务支持一次执行多个命令，一个事务中所有命令都会被序列化，在事务执行过程中，会按照顺序序列化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。
总结说：Redis事务就是一次性、顺序性、排他性地执行一个队列中的一系列命令。

Redis事务的三个阶段

事务开始MULTI
命令入队
事务执行EXEC

事务执行过程中，如果服务端收到有EXEC,DISCARD,WATCH,MULTI之外的请求，将会把请求放入队列中排队。

Redis事务相关命令

Redis事务功能是通过MULTI,EXEC,DISCARD和WATCH四个原语实现的，Redis会将一个事务中所有命令序列化，然后按顺序执行。

Redis不支持回滚，“Redis在事务失败时不进行回滚，而是继续执行余下的命令”，所以Redis的内部可以保持简单且快速；
如果在一个事务中的命令出现错误，那么所有的命令都不会执行；
如果在一个事务中出现运行错误，那么正确的命令会被执行。

四个原语：

WATCH命令是一个乐观锁，可以为Redis事务提供check-and-set（CAS）行为，可以监控一个或多个键，一旦其中有一个键被修改，之后的事务就都不会执行，监控一直持续到EXEC命令；
MULTI命令用于开启一个事务，它总是返回OK，MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
EXEC：执行所有事务块内的命令，返回事务块内所有命令的返回值，按命令执行的先后顺序排列，当操作被打断时，返回空值nil。
通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务，并且客户端会从事务状态中退出。
UNWATCH命令可以取消WATCH对所有key的监控。

事务管理（ACID）概述

原子性（Atomicity）
原子性是指事务是一个不可分割的工作单位，事务中操作要么都发生，要么都不发生。
一致性（Consistency）
事务前后数据的完整性必须保持一致。
隔离性（Isolation）
多个事务并发执行时，一个事务的执行不应影响其他其他事务的执行。
持久性（Durability）
持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。

Redis的事务总是具有ACID中的一致性和隔离性，其他特性是不支持的，当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时，事务也具有持久性。

Redis事务支持隔离性吗

Redis是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止，因此Redis的事务总是带有隔离性的。

Redis事务保证原子性吗？支持回滚吗？

Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚，事务中任意命令执行失败，其余的命令仍会被执行。

Redis事务其他实现

基于Lua脚本，Redis可以保证脚本内的命令一次性，按顺序地执行，其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完。
基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成，但这样会需要额外写代码实现，比较繁琐。

集群方案

哨兵模式

在这里插入图片描述
哨兵的介绍
sentinel，中文名是哨兵，哨兵是Redis集群机构中非常重要的一个组件，主要有以下功能：

集群监控：负责监控Redis中master和slave进程是否正常工作；
消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员；
故障转移：如果master node挂掉了，会自动转移到slave node上；
配置中心：如果故障转移发生了，通知client客户端新的master地址。

哨兵用于实现Redis集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

故障转移时，判断一个master node是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题；
即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的。

哨兵的核心知识

哨兵至少需要3个实例，来保证自己的健壮性；
哨兵+Redis主从的部署架构，是不保证数据零丢失的，只能保证Redis集群的高可用性；
对于哨兵+Redis主从这种复杂的部署架构，尽量在测试环境和生产环境都进行充足的测试和演练。

官方Redis Cluster方案（服务端路由查询）

在这里插入图片描述

Redis集群模式的工作原理能说一下吗？在集群模式下，Redis的key是如何寻址的？分布式寻址都有哪些算法？了解一致性Hash算法吗？

简介
Redis Cluster是一种服务端Sharding（分片）技术，3.0版本开始正式提供，Redis Cluster并没有使用一致性hash，而是采用slot（槽）的概念，一共分为16384个槽，将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。

方案说明

通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽区间的数据，默认分配了16384个槽位；
每份数据分片会存储在多个互为主从的多节点上；
数据写入先写主节点，再同步到从节点；
同一分片多个节点间的数据不保持一致性；
读取数据时，当客户端操作的key没有分配在该节点上时，Redis会返回转向指令，指向正确的节点；
扩容时需要把旧节点的数据迁移一部分到新节点。

在Redis cluster架构下，每个Redis要开放两个端口号，比如一个是6379，另一个就是加1w的端口号，如：16379,16379端口号就是用来进行节点间通信的，也就是cluster bus的东西，cluster bus的通信，用来进行故障检测、配置更新、故障转移授权，cluster bus用了另外一种二进制的协议，gossip协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

节点间的内部通信机制
集群元数据的维护有两种方式：集中式、gossip协议，Redis cluster节点间采用gossip协议进行通信。

分布式寻址算法

hash算法（大量缓存重建）
一致性hash算法（自动缓存迁移）+ 虚拟节点（自动负载均衡）
Redis cluster的hash slot算法

优点

无中心架构，支持动态扩容，对业务透明；
具备Sentinel的监控和自动Failover（故障转移）能力；
客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可；
高性能，客户端直连Redis服务，免去了Proxy代理的损耗。

缺点

运维也很复杂，数据迁移需要人工干预；
只能使用0号数据库；
不支持批量操作；
分布式逻辑和存储模块耦合等

基于客户端分配

在这里插入图片描述
简介
Redis Sharding是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法，其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上，Java Redis客户端驱动Jedis，支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。

优点
非常简单，服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。

缺点

由于Sharding处理放到客户端，规模进一步扩大时给运维带来挑战；
客户端Sharding不支持动态增删节点，服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整，连接不能共享，当应用规模增大时，资源浪费制约优化。

基于代理服务器分片

在这里插入图片描述
简介
客户端发送请求到一个代理组件，代理解析客户端的数据，并将请求转发到正确的节点，最后将结果回复给客户端。

特征

透明接入，业务程序不用关心后端Redis实例，切换成本低；
Proxy的逻辑和存储的逻辑是隔离的；
代理层多了一次转发，性能有所损耗；

Redis主从架构

单机的Redis，能够承载的QPS大概就在上万到几万不等，对于缓存来说，一般都是用来支撑读高并发的，因此架构做成主从架构，一主多从，主负责写，并且将数据复制到其他的slave节点，从节点负责读，所有的读请求全部走从节点，这样也可以很轻松实现水平扩容，支撑读高并发。
在这里插入图片描述
Redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发

Redis replication的核心机制

Redis采用异步方式复制数据到slave节点，不过从Redis2.8开始，slave node会周期性地确认自己每次复制的数据量；
一个master node是可以配置多个slave node的；
slave node也可以连接其他的slave node；
slave node做复制的时候，不会阻塞master node的正常工作，也不会阻塞对自己的查询操作，它会用旧的数据集来提供服务，但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了；
slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量。

注意：如果采用了主从架构，那么建议必须开启master node的持久化，不建议用slave node作为master node的数据热备，因为那样的话，如果你关闭了master的持久化，可能在master宕机重启的时候数据是空的，然后可能一经过复制，salve node的数据也丢了。

另外，master的各种备份方案也需要做，万一本地的所有文件丢失了，从备份中挑选一份RDB去恢复master，这样才能确保启动的时候是有数据的，即使采用了后续讲解的高可用机制，slave node可以自动接管master node，但也可能sentinel还没检测到master failure，master node就自动重启了，还是可能导致上面所有的slave node数据被清空。

Redis主从复制的核心原理
当启动一个slave node的时候，它会发送一个PSYNC命令给master node。

如果这是slave node初次连接到master node，那么会触发一次full resynchronization全量复制，此时master会启动一个后台线程，开始生成一份RDB快照文件；

同时还会将从客户端client新收到的所有写命令缓存在内存中，RDB文件生成完毕后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中；

接着master会将内存中缓存的写命令发送到slave，slave也会同步这些数据；

slave node如果跟master node有网络故障，断开了连接，会自动重连，连接之后master node仅会复制给slave部分缺少的数据。
在这里插入图片描述
过程原理

当从库和主库建立master-slave关系后，从库会向主库发送SYNC命令；
主库接收到SYNC命令后会开始在后台保存快照（RDB持久化过程），并将期间接收到的写命令缓存起来；
当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis；
从Redis接收到后，会载入快照文件并且执行收到的缓存的命令；
之后，主Redis每当接收到写命令时都会将命令发送给从Redis，从而保证数据的一致性

缺点
所有的slave节点数据的复制和同步都由master节点来处理，会造成master节点压力太大，可以使用主从从结构来解决。

Redis集群的主从复制模型是怎么样的

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型，每个节点都会有N-1个复制品。

生产环境中的Redis是怎么部署的

Redis cluster，10台机器，5台机器部署了Redis主实例，另外5台机器部署了Redis的从实例，每个主实例挂了一个从实例，5个节点对外提供读写服务，每个节点的读写高峰QPS可以达到每秒5万，5台机器最多是25万读写请求/s。

机器是什么配置？
32G内存+8核CPU+1T磁盘，但是分配给Redis进程的是10G，一般线上生产环境，Redis的内存尽量不要超过10G，不然可能会有问题。

5台机器对外提供读写，一共有50G内存。

因为每个主实例都挂了一个从实例，任何一个主实例宕机，都会自动故障迁移，Redis从实例会自动变成主实例继续提供读写服务。

你往内存里写的是什么数据？每条数据的大小是多少？
商品数据，每条数据是10kb，100条数据是1mb，10万条数据就是1G，常驻内存的是200万条商品数据，占用内存是20G，仅仅不到总内存的50%，目前高峰期每秒就是3500左右的请求量。

说说Redis哈希槽的概念

Redis集群中没有使用一致性hash，而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

Redis集群会有写操作丢失吗？为什么？

Redis并不能保证数据的强一致性，这意味着在实际中集群在特定的条件下可能会丢失写操作。

Redis集群之间是如何复制的

异步复制

Redis集群最大节点个数是多少

16384

Redis集群如何选择数据库？

Redis集群目前无法做数据库选择，默认在0数据库。

分区

Redis是单线程的，如何提高多核CPU的利用率

可以在同一个服务器部署多个Redis的实例，并把他们当做不同的服务器来使用，在某些时候，无论如何一个服务器是不够的，所以如果想使用多个CPU，可以考虑一下分区（sharding）。

为什么要做Redis分区

分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存，如果没有分区，最多只能使用一台机器的内存，分区使Redis的计算能力通过简单地增加计算机得到成倍提升，Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。

你知道有哪些Redis分区实现方案

客户端分区：就是在客户端已经决定数据会被存储到哪个Redis节点或者从哪个Redis节点读取，大多数客户端已经实现了客户端分区；
代理分区：意味着客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据，代理根据分区规则决定请求哪些Redis实例，然后根据Redis的响应结果返回给客户端，Redis和Memcached的一种代理实现就是Twemproxy；
查询路由（Query routing）：客户端随机请求任意一个Redis实例，然后由Redis将请求转发给正确的Redis节点，Redis Cluster实现了一种混合形式的查询路由，但并不是直接将请求从一个Redis节点转发到另一个Redis节点，而是在客户端的帮助下直接重定向到正确的Redis节点。

Redis分区有什么缺点

涉及多个key的操作通常不会被支持，例如你不能对两个集合求交集，因为他们可能被存储到不同的Redis实例；
同时操作多个key，则不能使用Redis事务；
分区使用的粒度是key，不能使用一个非常长的排序key存储一个数据集；
当使用分区的时候，数据处理会非常复杂，例如为了备份你必须从不同的Redis实例和主机同时收集RDB/AOF文件；
分区时动态扩容或缩容可能非常复杂，Redis集群在运行时增加或者删除Redis节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。

分布式问题

Redis实现分布式锁

Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系，Redis中可以使用SETNX【SET if NOT EXISTS】命令实现分布式锁。

当且仅当key不存在，将key的值设为value，若给定的key已经存在，则SETNX不做任何动作。

使用SETNX完成同步锁的流程及事项如下：

使用SETNX命令获取锁，若返回0（key已经存在，锁已存在）则获取失败，反之获取成功。
为了防止获取锁后程序出现异常，导致其他线程/进程调用SETNX命令总是返回0而进入死锁状态，需要为该key设置一个合理的过期时间。

释放锁，使用DEL命令将锁数据删除。

如何解决Redis的并发竞争Key问题

所谓Redis的并发竞争key的问题也就是多个系统同时对一个key进行操作，但是最后执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同！

推荐一种方案：分布式锁（Zookeeper和Redis都可以实现分布式锁）

分布式Redis是前期做还是后期规模上来了再做好？为什么？

既然Redis是如此的轻量，为防止以后的扩容，最好的办法就是一开始就启动较多实例，即便你只有一台服务器，你也可以一开始就让Redis以分布式的方式运行，使用分区，在同一台服务器上启动多个实例。

一开始就多设置几个Redis实例，例如32或64个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看这点牺牲是值得的。

当你的数据不断增长，需要更多的Redis服务器时，你需要做的仅仅是将Redis实例从一台服务器迁移到另外一台服务器而已，一旦你添加了另外一台服务器，你需要将你一半的Redis实例从第一台机器迁移到第二台机器。

什么是RedLock

Redis官方提出的一种权威的基于Redis实现分布式锁的方式名叫Redlock，此种方式比原先的单节点的方式更安全，它可以保证以下特性：

安全特性：互斥访问，即永远只有一个client能拿到锁；
避免死锁：最终client都可以拿到锁，不会出现死锁的情况，即使原本锁住某资源的client崩溃了或者出现了网络分区；
容错性：只要大部分Redis节点存活就可以正常提供服务。

缓存异常

缓存雪崩

缓存雪崩是指缓存同一时间大面积的失效，所以后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决方案

缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生；
一般并发量不是特别多的时候，使用最多的解决方案是加锁排队；
给每一个缓存数据增加相应的缓存标记，记录缓存是否失效，如果缓存标记失效，则更新数据缓存。

缓存击穿

缓存在某个时间点过期的时候，恰好在这个时间点对这个 key 有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端 DB 压垮。

解决方案

设置热点数据永不过期；
加互斥锁

缓存穿透

缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决方案

接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30s，这样可以防止攻击用户反复用同一个id暴力攻击；
采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统，这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题，用户直接查询事先被预热的缓存数据。

解决方案

直接写个缓存刷新页面，上线时手动操作一下；
数据量不大时，可以在项目启动的时候自动进行加载；
定时刷新缓存。

缓存降级

当访问量剧增，服务出现问题（如：响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务，系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

缓存降级的最终目的是保证核心服务可用，即使是有损的，而且有些服务是无法降级的（比如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以弃卒保帅，从而梳理出哪些必须誓死保护，哪些可降级；

服务降级的目的是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题，因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

热点数据和冷数据

热点数据，缓存才有价值。

对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存，不仅占用内存，而且价值不大，频繁修改的数据，看情况考虑使用缓存。

对于热点数据，比如我们的某IM产品，生日祝福模块等，缓存以后可能读取数十万次。

缓存热点key

缓存中的一个key（比如一个促销商品），在某个时间点过期的时候，恰好在这个时间点对这个key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案
对缓存查询加锁，如果key不存在就加锁，然后从DB中查询数据并加入缓存，然后解锁，如果其他进程发现有锁就等待，然后等解锁后返回数据或者进入DB查询。

常用工具

Redis支持的Java客户端都有哪些？官方推荐用哪个？

Redisson、Jedis，官方推荐使用Redisson。

Redis和Redisson有什么关系？

Redisson是一个高级的分布式协调Redis客户端，能够帮助用户在分布式环境中轻松实现一些Java的对象。

Jedis和Redisson对比有什么优缺点？

Jedis是Redis的Java实现的客户端，其API提供了比较全面的Redis命令的支持；Redisson实现了分布式和可扩展的Java数据结构，和Jedis相比，功能较为简单，不支持字符串操作，不支持排序，事务，管道，分区等Redis特性，Redisson的宗旨是促进使用者对Redis的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。

其他问题

Redis与Memcached的区别

Memcached所有的值均是简单的字符串，Redis作为其替代者，支持更为丰富的数据类型；
Redis的速度比Memcached快很多；
Redis可以持久化其数据

如何保证缓存与数据库双写时的数据一致性？

将读请求和写请求串行化，串到一个内存队列中，这样就能保证一定不会出现不一致的情况，串行化之后会导致系统的吞吐量大幅度降低，用比正常情况下多几倍的机器去支撑线上的一个请求；

还有一种方式就是可能会暂时产生不一致的情况，但是发生的几率特别小，就是先更新数据库，然后将旧缓存失效，读取数据的时候，如果缓存不存在，则读取数据库再写缓存。

Redis常见性能问题和解决方案？

Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化；
如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次；
为了主从复制的速度和连接的稳定性，Slave和Master最好是在同一局域网内；
尽量避免在压力较大的主库上增加从库；
Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占用大量的CPU和内存资源，导致服务过载，会出现短暂服务暂停现象；
为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<–Slave1<–Slave2<–Slave3…，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变。

Redis官方为什么不提供Windows版本

因为目前Linux版本已经相当稳定，而且用户量很大，无须开发windows版本，反而会带来兼容性问题。

一个字符串类型的值能存储最大容量是多少

512M

Redis如何做大量数据插入？

Redis2.6开始redis-cli支持一种新的被称为之pipe mode的新模式用于执行大量数据插入工作。

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如何将它们全部找出来？

使用keys指令可以扫出指定模式的key列表。
对方接着追问：如果这个Redis正在给线上的业务提供服务，那使用keys指令会有什么问题？
这个时候你要回答Redis的一个关键特性：Redis是单线程的，keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复，这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，需要在客户端做一次去重操作，整体花费的时间比直接用keys指令长。

使用Redis做过异步队列吗？是如何实现的

使用list类型保存数据消息，rpush生产消息，lpop消费消息，当lpop没有消息时，可以sleep一段时间，然后再检查有没有消息，如果不想sleep的话，可以使用blpop，在没有消息的时候，会一直阻塞，直到消息的到来，Redis可以通过发布/订阅模式来实现一个生产者多个消费者。

Redis如何实现延时队列

使用Sorted Set，使用时间戳做score，消息内容作为key，调用zadd来生产消息，消费者使用zrangbyscore获取n秒之前的数据做轮询处理。

Redis回收进程如何工作

一个客户端运行了新的命令，添加了新的数据；
Redis检查内存使用情况，如果大于maxmemory的限制，则根据设定好的策略进行回收；
一个新的命令被执行，等等；
所以我们不断地穿越内存限制的边界，通过不断达到边界然后不断地回收到边界以下。

如果一个命令的结果导致大量内存被使用，不用多久内存限制就会被这个内存使用量超越。

Redis回收使用的是什么算法

LRU算法。