什么是Redis？它主要用来什么的？

Redis，英文全称是Remote Dictionary Server（远程字典服务），是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

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

Redis都有哪些使用场景？

1. Redis是基于内存的nosql数据库，可以通过新建线程的形式进行持久化，不影响Redis单线程的读写操作
2. 通过list取最新的N条数据
3. 模拟类似于token这种需要设置过期时间的场景
4. 发布订阅消息系统
5. 定时器、计数器

Redis有哪些功能？

基于本机内存的缓存

当调用api访问数据库时，假如此过程需要2秒，如果每次请求都要访问数据库，那将对服务器造成巨大的压力，如果将此sql的查询结果存到Redis中，再次请求时，直接从Redis中取得，而不是访问数据库，效率将得到巨大的提升，Redis可以定时去更新数据（比如1分钟）。

哨兵（Sentinel）和复制

Sentinel可以管理多个Redis服务器，它提供了监控、提醒以及自动的故障转移功能；

复制则是让Redis服务器可以配备备份的服务器；

Redis也是通过这两个功能保证Redis的高可用；

集群（Cluster）

单台服务器资源总是有上限的，CPU和IO资源可以通过主从复制，进行读写分离，把一部分CPU和IO的压力转移到从服务器上，但是内存资源怎么办，主从模式只是数据的备份，并不能扩充内存；

现在我们可以横向扩展，让每台服务器只负责一部分任务，然后将这些服务器构成一个整体，对外界来说，这一组服务器就像是集群一样。

Redis支持的数据类型有哪些？

1. 字符串
2. hash
3. list
4. set
5. zset

Redis为什么是单线程的？

1. 代码更清晰，处理逻辑更简单；
2. 不用考虑各种锁的问题，不存在加锁和释放锁的操作，没有因为可能出现死锁而导致的性能问题；
3. 不存在多线程切换而消耗CPU；
4. 无法发挥多核CPU的优势，但可以采用多开几个Redis实例来完善；

Redis真的是单线程的吗？

Redis6.0之前是单线程的，Redis6.0之后开始支持多线程； redis内部使用了基于epoll的多路服用，也可以多部署几个redis服务器解决单线程的问题； redis主要的性能瓶颈是内存和网络； 内存好说，加内存条就行了，而网络才是大麻烦，所以redis6内存好说，加内存条就行了； 而网络才是大麻烦，所以redis6.0引入了多线程的概念， redis6.0在网络IO处理方面引入了多线程，如网络数据的读写和协议解析等，需要注意的是，执行命令的核心模块还是单线程的。

Redis持久化有几种方式？

redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。

RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；

AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。

如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。

Redis和 memecache 有什么区别？

1、Redis相比memecache，拥有更多的数据结构和支持更丰富的数据操作。

（1）Redis支持key-value，常用的数据类型主要有String、Hash、List、Set、Sorted Set。

（2）memecache只支持key-value。

2、内存使用率对比，Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于memecache。

3、性能对比：Redis只使用单核，memecache使用多核。

4、Redis支持磁盘持久化，memecache不支持。

Redis可以将一些很久没用到的value通过swap方法交换到磁盘。

5、Redis支持分布式集群，memecache不支持。

Redis CPU飙到90%！怎么办？

1. 首先，进行快速诊断。我会立即登录服务器，使用slowlog get 10来检查是否存在慢查询。如果slowlog不明显，我会使用redis-cli --hotkeys来排查是否存在访问过于集中的热点Key。作为最后的手段，我可能会短暂地使用MONITOR抓取一小部分实时命令来分析请求模式，但我会非常谨慎，避免影响线上性能。
2. 其次，根据诊断结果进行分类处理：
   • 如果是慢命令，我会定位到业务代码，将KEYS、HGETALL等O(N)命令改造为SCAN、HSCAN等渐进式命令。
   • 如果是大Key，我会分析其结构，并推动业务改造，将其拆分为多个小Key，降低单次操作的CPU开销。
   • 如果是热Key，我会评估是读热点还是写热点。对于读热点，我会引入本地缓存或增加只读副本来分摊流量；对于写热点，则会考虑将Key进行复制并分发的方案。
3. 最后，进行复盘和预防。问题解决后，我会推动建立一套Redis使用的规范，比如在Code Review阶段就禁止使用高风险命令，并建立对大Key和热Key的常态化监控，从根源上避免类似问题再次发生。”

怎么保证缓存和数据库数据的一致性？

淘汰缓存

数据如果为较为复杂的数据时，进行缓存的更新操作就会变得异常复杂，因此一般推荐选择淘汰缓存，而不是更新缓存。

选择先淘汰缓存，再更新数据库

假如先更新数据库，再淘汰缓存，如果淘汰缓存失败，那么后面的请求都会得到脏数据，直至缓存过期。

假如先淘汰缓存再更新数据库，如果更新数据库失败，只会产生一次缓存穿透，相比较而言，后者对业务则没有本质上的影响。

延时双删策略

如下场景：同时有一个请求A进行更新操作，另一个请求B进行查询操作。

1. 请求A进行写操作，删除缓存

2. 请求B查询发现缓存不存在

3. 请求B去数据库查询得到旧值

4. 请求B将旧值写入缓存

5. 请求A将新值写入数据库

次数便出现了数据不一致问题。采用延时双删策略得以解决。

这么做，可以将1秒内所造成的缓存脏数据，再次删除。这个时间设定可根据俄业务场景进行一个调节。

数据库读写分离的场景

两个请求，一个请求A进行更新操作，另一个请求B进行查询操作。

1. 请求A进行写操作，删除缓存

2. 请求A将数据写入数据库了，

3. 请求B查询缓存发现，缓存没有值

4. 请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值

5. 请求B将旧值写入缓存

6. 数据库完成主从同步，从库变为新值

依旧采用延时双删策略解决此问题。

Redis分布式锁有什么缺陷？

Redis 分布式锁不能解决超时的问题，分布式锁有一个超时时间，程序的执行如果超出了锁的超时时间就会出现问题。

Redis容易产生的几个问题：

1. 锁未被释放
2. B锁被A锁释放了
3. 数据库事务超时
4. 锁过期了，业务还没执行完
5. Redis主从复制的问题

Redis如何做内存优化？

缩短键值的长度

缩短值的长度才是关键，如果值是一个大的业务对象，可以将对象序列化成二进制数组； 首先应该在业务上进行精简，去掉不必要的属性，避免存储一些没用的数据； 其次是序列化的工具选择上，应该选择更高效的序列化工具来降低字节数组大小； 以JAVA为例，内置的序列化方式无论从速度还是压缩比都不尽如人意，这时可以选择更高效的序列化工具，如: protostuff，kryo等

共享对象池

对象共享池指Redis内部维护[0-9999]的整数对象池。创建大量的整数类型redisObject存在内存开销，每个redisObject内部结构至少占16字节，甚至超过了整数自身空间消耗。所以Redis内存维护一个[0-9999]的整数对象池，用于节约内存。 除了整数值对象，其他类型如list,hash,set,zset内部元素也可以使用整数对象池。因此开发中在满足需求的前提下，尽量使用整数对象以节省内存。

字符串优化

编码优化

控制key的数量

什么是缓存击穿、缓存穿透、缓存雪崩？

缓存穿透问题

先来看一个常见的缓存使用方式：读请求来了，先查下缓存，缓存有值命中，就直接返回；缓存没命中，就去查数据库，然后把数据库的值更新到缓存，再返回。

缓存穿透：指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。

通俗点说，读请求访问时，缓存和数据库都没有某个值，这样就会导致每次对这个值的查询请求都会穿透到数据库，这就是缓存穿透。

缓存穿透一般都是这几种情况产生的：

• 业务不合理的设计，比如大多数用户都没开守护，但是你的每个请求都去缓存，查询某个userid查询有没有守护。
• 业务/运维/开发失误的操作，比如缓存和数据库的数据都被误删除了。
• 黑客非法请求攻击，比如黑客故意捏造大量非法请求，以读取不存在的业务数据。

如何避免缓存穿透呢？ 一般有三种方法。

• 1.如果是非法请求，我们在API入口，对参数进行校验，过滤非法值。
• 2.如果查询数据库为空，我们可以给缓存设置个空值，或者默认值。但是如有有写请求进来的话，需要更新缓存哈，以保证缓存一致性，同时，最后给缓存设置适当的过期时间。（业务上比较常用，简单有效）
• 3.使用布隆过滤器快速判断数据是否存在。即一个查询请求过来时，先通过布隆过滤器判断值是否存在，存在才继续往下查。

布隆过滤器原理：它由初始值为0的位图数组和N个哈希函数组成。一个对一个key进行N个hash算法获取N个值，在比特数组中将这N个值散列后设定为1，然后查的时候如果特定的这几个位置都为1，那么布隆过滤器判断该key存在。

缓存雪奔问题

缓存雪奔： 指缓存中数据大批量到过期时间，而查询数据量巨大，请求都直接访问数据库，引起数据库压力过大甚至down机。

• 缓存雪奔一般是由于大量数据同时过期造成的，对于这个原因，可通过均匀设置过期时间解决，即让过期时间相对离散一点。如采用一个较大固定值+一个较小的随机值，5小时+0到1800秒酱紫。
• Redis 故障宕机也可能引起缓存雪奔。这就需要构造Redis高可用集群啦。

缓存击穿问题

缓存击穿： 指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db。

缓存击穿看着有点像，其实它两区别是，缓存雪奔是指数据库压力过大甚至down机，缓存击穿只是大量并发请求到了DB数据库层面。可以认为击穿是缓存雪奔的一个子集吧。有些文章认为它俩区别，是区别在于击穿针对某一热点key缓存，雪奔则是很多key。

解决方案就有两种：

• 使用互斥锁方案。缓存失效时，不是立即去加载db数据，而是先使用某些带成功返回的原子操作命令，如(Redis的setnx）去操作，成功的时候，再去加载db数据库数据和设置缓存。否则就去重试获取缓存。
• “永不过期”，是指没有设置过期时间，但是热点数据快要过期时，异步线程去更新和设置过期时间

什么是热Key问题，如何解决热key问题

什么是热Key呢？在Redis中，我们把访问频率高的key，称为热点key。

如果某一热点key的请求到服务器主机时，由于请求量特别大，可能会导致主机资源不足，甚至宕机，从而影响正常的服务。

而热点Key是怎么产生的呢？主要原因有两个：

用户消费的数据远大于生产的数据，如秒杀、热点新闻等读多写少的场景。 请求分片集中，超过单Redi服务器的性能，比如固定名称key，Hash落入同一台服务器，瞬间访问量极大，超过机器瓶颈，产生热点Key问题。

那么在日常开发中，如何识别到热点key呢？

凭经验判断哪些是热Key； 客户端统计上报； 服务代理层上报

如何解决热key问题？

Redis集群扩容：增加分片副本，均衡读流量； 将热key分散到不同的服务器中； 使用二级缓存，即JVM本地缓存,减少Redis的读请求。

Redis 过期策略和内存淘汰策略

Redis的过期策略

我们在set key的时候，可以给它设置一个过期时间，比如expire key 60。指定这key60s后过期，60s后，redis是如何处理的嘛？我们先来介绍几种过期策略：

定时过期

每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即对key进行清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

惰性过期

只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

定期过期

每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。 expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。

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

• 假设Redis当前存放30万个key，并且都设置了过期时间，如果你每隔100ms就去检查这全部的key，CPU负载会特别高，最后可能会挂掉。
• 因此，redis采取的是定期过期，每隔100ms就随机抽取一定数量的key来检查和删除的。
• 但是呢，最后可能会有很多已经过期的key没被删除。这时候，redis采用惰性删除。在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间并且已经过期了，此时就会删除。

但是呀，如果定期删除漏掉了很多过期的key，然后也没走惰性删除。就会有很多过期key积在内存内存，直接会导致内存爆的。或者有些时候，业务量大起来了，redis的key被大量使用，内存直接不够了，运维小哥哥也忘记加大内存了。难道redis直接这样挂掉？不会的！Redis用8种内存淘汰策略保护自己~

Redis 内存淘汰策略

Redis 内存淘汰策略是指当Redis实例的内存使用量超过预设的最大内存限制（maxmemory）时，为了防止内存溢出而采取的一种自动删除（或替换）键值对的机制。Redis提供了多种内存淘汰策略供用户选择，以便根据不同的应用场景选择最适合的策略。以下是Redis支持的部分内存淘汰策略：

1. noeviction （默认策略，直到Redis 6）
   • 不进行任何数据淘汰，当内存达到上限时，所有会导致更多内存分配的命令都会返回错误。
2. volatile-lru
   • 只从设置了过期时间（TTL）的键集中淘汰最近最少使用的（LRU）键。
3. allkeys-lru
   • 从所有键集中，包括未设置过期时间的键，淘汰最近最少使用的键。
4. volatile-lfu
   • 只从设置了过期时间的键集中淘汰访问频率最低的（LFU）键。
5. allkeys-lfu
   • 从所有键集中，无论是否设置过期时间，淘汰访问频率最低的键。
6. volatile-random
   • 随机淘汰已设置过期时间的键。
7. allkeys-random
   • 随机淘汰任意键，包括未设置过期时间的键。
8. volatile-ttl
   • 淘汰那些即将过期的键，即剩余生存时间（TTL）最短的键。
9. volatile-xxx 和 allkeys-xxx 中的“volatile”表示仅针对设置了过期时间的键；“allkeys”则意味着所有键都参与淘汰策略。

从上面的信息来看，随着时间的推移，Redis可能增加了新的淘汰策略。例如，在某个时间点后的Redis版本中，LRU和LFU的实现可能更加精确或优化了异步删除逻辑。

要设置内存淘汰策略，可以使用 CONFIG SET 命令：

CONFIG SET maxmemory-policy <policy-name>

其中 <policy-name> 是上述策略之一。此外，确保合理配置 maxmemory 参数，以确定Redis允许使用的最大内存大小。在实践中，结合适当的键过期策略和内存淘汰策略，可以更好地管理Redis实例的内存资源。

Redis 的持久化机制有哪些？优缺点说说

Redis是基于内存的非关系型K-V数据库，既然它是基于内存的，如果Redis服务器挂了，数据就会丢失。为了避免数据丢失了，Redis提供了持久化，即把数据保存到磁盘。

Redis提供了RDB和AOF两种持久化机制，它持久化文件加载流程如下：

• RDB（快照）：
  • 优点：快照周期短，对系统性能影响小
  • 缺点：无法做到数据完全不丢失，快照期间会阻塞客户端写入
• AOF（追加文件）：
  • 优点：可以做到数据完全不丢失
  • 缺点：对系统性能影响较大

怎么实现Redis的高可用？

我们在项目中使用Redis，肯定不会是单点部署Redis服务的。因为，单点部署一旦宕机，就不可用了。为了实现高可用，通常的做法是，将数据库复制多个副本以部署在不同的服务器上，其中一台挂了也可以继续提供服务。Redis 实现高可用有三种部署模式：主从模式，哨兵模式，集群模式。

主从模式

主从模式中，Redis部署了多台机器，有主节点，负责读写操作，有从节点，只负责读操作。从节点的数据来自主节点，实现原理就是主从复制机制

主从复制包括全量复制，增量复制两种。一般当slave第一次启动连接master，或者认为是第一次连接，就采用全量复制，全量复制流程如下：

• 1.slave发送sync命令到master。
• 2.master接收到SYNC命令后，执行bgsave命令，生成RDB全量文件。
• 3.master使用缓冲区，记录RDB快照生成期间的所有写命令。
• 4.master执行完bgsave后，向所有slave发送RDB快照文件。
• 5.slave收到RDB快照文件后，载入、解析收到的快照。
• 6.master使用缓冲区，记录RDB同步期间生成的所有写的命令。
• 7.master快照发送完毕后，开始向slave发送缓冲区中的写命令;
• 8.salve接受命令请求，并执行来自master缓冲区的写命令

redis2.8版本之后，已经使用psync来替代sync，因为sync命令非常消耗系统资源，psync的效率更高。

slave与master全量同步之后，master上的数据，如果再次发生更新，就会触发增量复制。

当master节点发生数据增减时，就会触发replicationFeedSalves()函数，接下来在 Master节点上调用的每一个命令会使用replicationFeedSlaves()来同步到Slave节点。执行此函数之前呢，master节点会判断用户执行的命令是否有数据更新，如果有数据更新的话，并且slave节点不为空，就会执行此函数。这个函数作用就是：把用户执行的命令发送到所有的slave节点，让slave节点执行。

主从模式中，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址。显然，多数业务场景都不能接受这种故障处理方式。Redis从2.8开始正式提供了Redis Sentinel（哨兵）架构来解决这个问题。

哨兵模式，由一个或多个Sentinel实例组成的Sentinel系统，它可以监视所有的Redis主节点和从节点，并在被监视的主节点进入下线状态时，自动将下线主服务器属下的某个从节点升级为新的主节点。但是呢，一个哨兵进程对Redis节点进行监控，就可能会出现问题（单点问题），因此，可以使用多个哨兵来进行监控Redis节点，并且各个哨兵之间还会进行监控。

Sentinel哨兵模式

简单来说，哨兵模式就三个作用：

• 发送命令，等待Redis服务器（包括主服务器和从服务器）返回监控其运行状态；
• 哨兵监测到主节点宕机，会自动将从节点切换成主节点，然后通过发布订阅模式通知其他的从节点，修改配置文件，让它们切换主机；
• 哨兵之间还会相互监控，从而达到高可用。

故障切换的过程是怎样的呢

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行 failover 过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover 操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。

哨兵的工作模式如下：

1. 每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他Sentinel实例发送一个 PING命令。
2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel标记为主观下线。
3. 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4. 当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线。
5. 在一般情况下， 每个 Sentinel 会以每10秒一次的频率向它已知的所有Master，Slave发送 INFO 命令。
6. 当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
7. 若没有足够数量的 Sentinel同意Master已经下线， Master的客观下线状态就会被移除；若Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

Cluster集群模式

哨兵模式基于主从模式，实现读写分离，它还可以自动切换，系统可用性更高。但是它每个节点存储的数据是一样的，浪费内存，并且不好在线扩容。因此，Cluster集群应运而生，它在Redis3.0加入的，实现了Redis的分布式存储。对数据进行分片，也就是说每台Redis节点上存储不同的内容，来解决在线扩容的问题。并且，它也提供复制和故障转移的功能。

Cluster集群节点的通讯

一个Redis集群由多个节点组成，各个节点之间是怎么通信的呢？通过Gossip协议！

Redis Cluster集群通过Gossip协议进行通信，节点之前不断交换信息，交换的信息内容包括节点出现故障、新节点加入、主从节点变更信息、slot信息等等。常用的Gossip消息分为4种，分别是：ping、pong、meet、fail。

meet消息：通知新节点加入。消息发送者通知接收者加入到当前集群，meet消息通信正常完成后，接收节点会加入到集群中并进行周期性的ping、pong消息交换。 ping消息：集群内交换最频繁的消息，集群内每个节点每秒向多个其他节点发送ping消息，用于检测节点是否在线和交换彼此状态信息。 pong消息：当接收到ping、meet消息时，作为响应消息回复给发送方确认消息正常通信。pong消息内部封装了自身状态数据。节点也可以向集群内广播自身的pong消息来通知整个集群对自身状态进行更新。 fail消息：当节点判定集群内另一个节点下线时，会向集群内广播一个fail消息，其他节点接收到fail消息之后把对应节点更新为下线状态。

特别的，每个节点是通过集群总线(cluster bus) 与其他的节点进行通信的。通讯时，使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是 16379。nodes 之间的通信采用特殊的二进制协议。

Hash Slot插槽算法

既然是分布式存储，Cluster集群使用的分布式算法是一致性Hash嘛？并不是，而是Hash Slot插槽算法。

插槽算法把整个数据库被分为16384个slot（槽），每个进入Redis的键值对，根据key进行散列，分配到这16384插槽中的一个。使用的哈希映射也比较简单，用CRC16算法计算出一个16 位的值，再对16384取模。数据库中的每个键都属于这16384个槽的其中一个，集群中的每个节点都可以处理这16384个槽。

集群中的每个节点负责一部分的hash槽，比如当前集群有A、B、C个节点，每个节点上的哈希槽数 =16384/3，那么就有：

• 节点A负责0~5460号哈希槽
• 节点B负责5461~10922号哈希槽
• 节点C负责10923~16383号哈希槽

如果redis集群扩容哈希槽是否是增加

Redis集群的哈希槽总数是固定的，始终保持为16384个。当进行集群扩容时，这里的“扩容”通常指的是增加集群中的节点数量，而不是增加哈希槽的数量。

在实际的Redis集群扩容过程中，不是增加哈希槽，而是将已存在的哈希槽重新分布到更多的节点上。扩容时，集群会自动地将某些节点上的哈希槽迁移到新加入的节点上，以保持各个节点的负载均衡。这样做的好处是可以将数据更均匀地分布在新增加的节点上，从而提升集群的整体处理能力以及冗余备份。

所以，Redis集群扩容的关键在于节点扩容，并伴随着哈希槽的重新分配，而非增加哈希槽数量本身。

Redis Cluster集群

Redis Cluster集群中，需要确保16384个槽对应的node都正常工作，如果某个node出现故障，它负责的slot也会失效，整个集群将不能工作。

因此为了保证高可用，Cluster集群引入了主从复制，一个主节点对应一个或者多个从节点。当其它主节点 ping 一个主节点 A 时，如果半数以上的主节点与 A 通信超时，那么认为主节点 A 宕机了。如果主节点宕机时，就会启用从节点。

在Redis的每一个节点上，都有两个玩意，一个是插槽（slot），它的取值范围是0~16383。另外一个是cluster，可以理解为一个集群管理的插件。当我们存取的key到达时，Redis 会根据CRC16算法得出一个16 bit的值，然后把结果对16384取模。酱紫每个key都会对应一个编号在 0~16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

虽然数据是分开存储在不同节点上的，但是对客户端来说，整个集群Cluster，被看做一个整体。客户端端连接任意一个node，看起来跟操作单实例的Redis一样。当客户端操作的key没有被分配到正确的node节点时，Redis会返回转向指令，最后指向正确的node，这就有点像浏览器页面的302 重定向跳转。

故障转移

Redis集群实现了高可用，当集群内节点出现故障时，通过故障转移，以保证集群正常对外提供服务。

redis集群通过ping/pong消息，实现故障发现。这个环境包括主观下线和客观下线。

主观下线： 某个节点认为另一个节点不可用，即下线状态，这个状态并不是最终的故障判定，只能代表一个节点的意见，可能存在误判情况。

主观下线

客观下线： 指标记一个节点真正的下线，集群内多个节点都认为该节点不可用，从而达成共识的结果。如果是持有槽的主节点故障，需要为该节点进行故障转移。

• 假如节点A标记节点B为主观下线，一段时间后，节点A通过消息把节点B的状态发到其它节点，当节点C接受到消息并解析出消息体时，如果发现节点B的pfail状态时，会触发客观下线流程；
• 当下线为主节点时，此时Redis Cluster集群为统计持有槽的主节点投票，看投票数是否达到一半，当下线报告统计数大于一半时，被标记为客观下线状态。

客观下线

故障恢复：故障发现后，如果下线节点的是主节点，则需要在它的从节点中选一个替换它，以保证集群的高可用。流程如下：

• 资格检查：检查从节点是否具备替换故障主节点的条件。
• 准备选举时间：资格检查通过后，更新触发故障选举时间。
• 发起选举：到了故障选举时间，进行选举。
• 选举投票：只有持有槽的主节点才有票，从节点收集到足够的选票（大于一半），触发替换主节点操作

什么是Redlock算法

Redis一般都是集群部署的，假设数据在主从同步过程，主节点挂了，Redis分布式锁可能会有哪些问题呢？一起来看些这个流程图：

如果线程一在Redis的master节点上拿到了锁，但是加锁的key还没同步到slave节点。恰好这时，master节点发生故障，一个slave节点就会升级为master节点。线程二就可以获取同个key的锁啦，但线程一也已经拿到锁了，锁的安全性就没了。

为了解决这个问题，Redis作者 antirez提出一种高级的分布式锁算法：Redlock。Redlock核心思想是这样的：

搞多个Redis master部署，以保证它们不会同时宕掉。并且这些master节点是完全相互独立的，相互之间不存在数据同步。同时，需要确保在这多个master实例上，是与在Redis单实例，使用相同方法来获取和释放锁。

我们假设当前有5个Redis master节点，在5台服务器上面运行这些Redis实例。

RedLock的实现步骤:如下

1.获取当前时间，以毫秒为单位。 2.按顺序向5个master节点请求加锁。客户端设置网络连接和响应超时时间，并且超时时间要小于锁的失效时间。（假设锁自动失效时间为10秒，则超时时间一般在5-50毫秒之间,我们就假设超时时间是50ms吧）。如果超时，跳过该master节点，尽快去尝试下一个master节点。 3.客户端使用当前时间减去开始获取锁时间（即步骤1记录的时间），得到获取锁使用的时间。当且仅当超过一半（N/2+1，这里是5/2+1=3个节点）的Redis master节点都获得锁，并且使用的时间小于锁失效时间时，锁才算获取成功。（如上图，10s> 30ms+40ms+50ms+4m0s+50ms） 如果取到了锁，key的真正有效时间就变啦，需要减去获取锁所使用的时间。 如果获取锁失败（没有在至少N/2+1个master实例取到锁，有或者获取锁时间已经超过了有效时间），客户端要在所有的master节点上解锁（即便有些master节点根本就没有加锁成功，也需要解锁，以防止有些漏网之鱼）。

简化下步骤就是：

• 按顺序向5个master节点请求加锁
• 根据设置的超时时间来判断，是不是要跳过该master节点。
• 如果大于等于三个节点加锁成功，并且使用的时间小于锁的有效期，即可认定加锁成功啦。
• 如果获取锁失败，解锁！

Redis的跳跃表

跳跃表

• 跳跃表是有序集合zset的底层实现之一
• 跳跃表支持平均O（logN）,最坏 O（N）复杂度的节点查找，还可以通过顺序性操作批量处理节点。
• 跳跃表实现由zskiplist和zskiplistNode两个结构组成，其中zskiplist用于保存跳跃表信息（如表头节点、表尾节点、长度），而zskiplistNode则用于表示跳跃表节点。
• 跳跃表就是在链表的基础上，增加多级索引提升查找效率。

MySQL与Redis 如何保证双写一致性

• 缓存延时双删
• 删除缓存重试机制
• 读取biglog异步删除缓存

延时双删？

什么是延时双删呢？流程图如下：

延时双删流程

1. 先删除缓存
2. 再更新数据库
3. 休眠一会（比如1秒），再次删除缓存。

这个休眠一会，一般多久呢？都是1秒？

这个休眠时间 = 读业务逻辑数据的耗时 + 几百毫秒。为了确保读请求结束，写请求可以删除读请求可能带来的缓存脏数据。

这种方案还算可以，只有休眠那一会（比如就那1秒），可能有脏数据，一般业务也会接受的。但是如果第二次删除缓存失败呢？缓存和数据库的数据还是可能不一致，对吧？给Key设置一个自然的expire过期时间，让它自动过期怎样？那业务要接受过期时间内，数据的不一致咯？还是有其他更佳方案呢？

删除缓存重试机制

因为延时双删可能会存在第二步的删除缓存失败，导致的数据不一致问题。可以使用这个方案优化：删除失败就多删除几次呀,保证删除缓存成功就可以了呀~ 所以可以引入删除缓存重试机制

删除缓存重试流程

1. 写请求更新数据库
2. 缓存因为某些原因，删除失败
3. 把删除失败的key放到消息队列
4. 消费消息队列的消息，获取要删除的key
5. 重试删除缓存操作

读取biglog异步删除缓存

重试删除缓存机制还可以吧，就是会造成好多业务代码入侵。其实，还可以这样优化：通过数据库的binlog来异步淘汰key。

以mysql为例吧

• 可以使用阿里的canal将binlog日志采集发送到MQ队列里面
• 然后通过ACK机制确认处理这条更新消息，删除缓存，保证数据缓存一致性

为什么Redis 6.0 之后改多线程呢？

• Redis6.0之前，Redis在处理客户端的请求时，包括读socket、解析、执行、写socket等都由一个顺序串行的主线程处理，这就是所谓的“单线程”。
• Redis6.0之前为什么一直不使用多线程？使用Redis时，几乎不存在CPU成为瓶颈的情况， Redis主要受限于内存和网络。例如在一个普通的Linux系统上，Redis通过使用pipelining每秒可以处理100万个请求，所以如果应用程序主要使用O(N)或O(log(N))的命令，它几乎不会占用太多CPU。

redis使用多线程并非是完全摒弃单线程，redis还是使用单线程模型来处理客户端的请求，只是使用多线程来处理数据的读写和协议解析，执行命令还是使用单线程。

这样做的目的是因为redis的性能瓶颈在于网络IO而非CPU，使用多线程能提升IO读写的效率，从而整体提高redis的性能。

聊聊Redis 事务机制

Redis通过MULTI、EXEC、WATCH等一组命令集合，来实现事务机制。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。

简言之，Redis事务就是顺序性、一次性、排他性的执行一个队列中的一系列命令。

Redis执行事务的流程如下：

• 开始事务（MULTI）
• 命令入队
• 执行事务（EXEC）、撤销事务（DISCARD ）

Redis的Hash 冲突怎么办

Redis 作为一个K-V的内存数据库，它使用用一张全局的哈希来保存所有的键值对。这张哈希表，有多个哈希桶组成，哈希桶中的entry元素保存了key和value指针，其中*key指向了实际的键，*value指向了实际的值。

哈希表查找速率很快的，有点类似于Java中的HashMap，它让我们在O(1) 的时间复杂度快速找到键值对。首先通过key计算哈希值，找到对应的哈希桶位置，然后定位到entry，在entry找到对应的数据。

什么是哈希冲突？

哈希冲突：通过不同的key，计算出一样的哈希值，导致落在同一个哈希桶中。

Redis为了解决哈希冲突，采用了链式哈希。链式哈希是指同一个哈希桶中，多个元素用一个链表来保存，它们之间依次用指针连接。

有些读者可能还会有疑问：哈希冲突链上的元素只能通过指针逐一查找再操作。当往哈希表插入数据很多，冲突也会越多，冲突链表就会越长，那查询效率就会降低了。

为了保持高效，Redis 会对哈希表做rehash操作，也就是增加哈希桶，减少冲突。为了rehash更高效，Redis还默认使用了两个全局哈希表，一个用于当前使用，称为主哈希表，一个用于扩容，称为备用哈希表。

在生成 RDB期间，Redis 可以同时处理写请求么？

可以的，Redis提供两个指令生成RDB，分别是save和bgsave。

• 如果是save指令，会阻塞，因为是主线程执行的。
• 如果是bgsave指令，是fork一个子进程来写入RDB文件的，快照持久化完全交给子进程来处理，父进程则可以继续处理客户端的请求。

Redis底层，使用的什么协议?

RESP，英文全称是Redis Serialization Protocol,它是专门为redis设计的一套序列化协议. 这个协议其实在redis的1.2版本时就已经出现了,但是到了redis2.0才最终成为redis通讯协议的标准。

RESP主要有实现简单、解析速度快、可读性好等优点。

布隆过滤器

应对缓存击穿问题，我们可以使用布隆过滤器。布隆过滤器是什么呢？

布隆过滤器是一种占用空间很小的数据结构，它由一个很长的二进制向量和一组Hash映射函数组成，它用于检索一个元素是否在一个集合中，空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。

布隆过滤器原理是？假设我们有个集合A，A中有n个元素。利用k个哈希散列函数，将A中的每个元素映射到一个长度为a位的数组B中的不同位置上，这些位置上的二进制数均设置为1。如果待检查的元素，经过这k个哈希散列函数的映射后，发现其k个位置上的二进制数全部为1，这个元素很可能属于集合A，反之，一定不属于集合A。

来看个简单例子吧，假设集合A有3个元素，分别为{d1,d2,d3}。有1个哈希函数，为Hash1。现在将A的每个元素映射到长度为16位数组B。

我们现在把d1映射过来，假设Hash1（d1）= 2，我们就把数组B中，下标为2的格子改成1，如下：

我们现在把d2也映射过来，假设Hash1（d2）= 5，我们把数组B中，下标为5的格子也改成1，如下：

接着我们把d3也映射过来，假设Hash1（d3）也等于 2，它也是把下标为2的格子标1：

因此，我们要确认一个元素dn是否在集合A里，我们只要算出Hash1（dn）得到的索引下标，只要是0，那就表示这个元素不在集合A，如果索引下标是1呢？那该元素可能是A中的某一个元素。因为你看，d1和d3得到的下标值，都可能是1，还可能是其他别的数映射的，布隆过滤器是存在这个缺点的：会存在hash碰撞导致的假阳性，判断存在误差。

如何减少这种误差呢？

• 搞多几个哈希函数映射，降低哈希碰撞的概率
• 同时增加B数组的bit长度，可以增大hash函数生成的数据的范围，也可以降低哈希碰撞的概率

我们又增加一个Hash2哈希映射函数，假设Hash2（d1）=6,Hash2（d3）=8,它俩不就不冲突了嘛，如下：

即使存在误差，我们可以发现，布隆过滤器并没有存放完整的数据，它只是运用一系列哈希映射函数计算出位置，然后填充二进制向量。如果数量很大的话，布隆过滤器通过极少的错误率，换取了存储空间的极大节省，还是挺划算的。

目前布隆过滤器已经有相应实现的开源类库啦，如Google的Guava类库，Twitter的 Algebird 类库，信手拈来即可，或者基于Redis自带的Bitmaps自行实现设计也是可以的。

为什么Redis集群的最大槽数是16384个？

Redis集群的最大槽数固定为16384个的原因可以从以下几个方面理解：

1. 性能与资源平衡： 设计Redis集群时，选择16384个槽位是为了在节点间高效地分配和迁移数据的同时，兼顾网络通信效率和服务器资源。每个槽位对应数据分区中的一个区间，通过CRC16算法计算key对应的槽位，然后将数据分配到持有该槽位的节点上。槽位数量多意味着能更好地分散数据，但槽位过多则会增加维护成本和网络通信开销。
2. 心跳包和带宽优化： Redis节点之间需要通过心跳包维持集群状态同步。若槽位过多，意味着心跳包中包含的槽位信息将会占用更多空间，增大网络带宽需求。选择16384个槽位时，可以将槽位信息以压缩的方式存储在心跳包内，从而控制在网络层面上的数据传输量。
3. 实践中的集群规模考量： Redis集群的实际应用中，通常不会部署上千个节点，而16384个槽位足以满足大部分场景下的节点规模需求。即使在集群内部署数百个节点，每个节点也能平均分配到一定数量的槽位，提供良好的负载均衡效果。
4. 简洁性和易用性： 设定一个固定且较大的槽位数量简化了集群管理和运维，同时为未来可能的增长预留了足够的空间，避免频繁调整槽位数量。

综上所述，16384个槽位是一个综合考虑了性能、资源利用率、网络开销以及实际应用规模等因素之后做出的设计决策。这个数量既保证了Redis集群功能的实现，又能在大多数实际环境中提供良好的可扩展性和稳定性。。