java-redis

Redis

• • Redis6.0相关知识
  • • Redis有多快？
    • Redis为什么这么快？
    • 为什么Redis是单线程？
    • 为什么使用单线程呢？
    • Redis6.0 的多线程
  • Redis的五种数据结构的底层实现原理
  • • Redis的两层数据结构简介
    • redisObject：两层数据结构的桥梁
    • 第一层数据结构
    • 第二层数据结构
  • Redis的数据过期清除策略 与 内存淘汰策略
  • • Redis的数据过期清除策略
    • Redis的缓存淘汰策略
    • Redis中的LRU和LFU算法
  • Redis的缓存雪崩、缓存击穿、缓存穿透与缓存预热、缓存降级
  • • 缓存雪崩
    • 缓存击穿
    • 缓存穿透
    • 缓存预热
    • 缓存降级
  • Redis的事务机制
  • • Redis事务的相关命令
    • Redis事务的原理
  • Redis的持久化机制
  • • RDB机制
    • AOF机制
    • Redis4.0的混合持久化
  • Redis主从复制原理
  • • 什么是Redis主从复制
    • 主从复制的原理
    • 主从复制的其他问题
    • Redis的高可用
  • Redis哨兵机制原理
  • • 什么是哨兵模式
    • 哨兵模式的搭建
    • 哨兵模式的工作原理
  • Redis集群原理详解
  • • Redis集群介绍
    • Redis集群的数据分布算法：哈希槽算法
    • Redis集群中节点的通信机制：goosip协议
    • 集群的扩容与收缩
    • 集群的故障检测与故障转恢复机制
    • Redis集群的搭建
    • Redis集群的运维
  • Redis的分布式锁
  • • 什么是分布式锁
    • 基于数据库的分布式锁
    • 基于Zookeeper的分布式锁
    • 基于redis的分布式锁
  • Redis缓存与数据库双写一致性
  • • 先更新数据库，再更新缓存
    • 先删缓存，再更新数据库
    • 先更新数据库，在删除缓存

Redis6.0相关知识

Redis有多快？

Redis是基于内存运行的高性能 K-V 数据库，官方提供的测试报告是单机可以支持约10w/s的QPS,每秒的请求.

Redis为什么这么快？

1. 完全基于内存，数据存在内存中，绝大部分请求是纯粹的内存操作，非常快速，跟传统的磁盘文件数据存储相比，避免了通过磁盘IO读取到内存这部分的开销。
2. 数据结构简单，对数据操作也简单。Redis中的数据结构是专门进行设计的，每种数据结构都有一种或多种数据结构来支持。Redis正是依赖这些灵活的数据结构，来提升读取和写入的性能。
3. 采用单线程，省去了很多上下文切换的时间以及CPU消耗，不存在竞争条件，不用去考虑各种锁的问题，不存在加锁释放锁操作，也不会出现死锁而导致的性能消耗。
4. 使用基于IO多路复用机制的线程模型，可以处理并发的链接。 Redis 基于 Reactor 模式开发了自己的网络事件处理器，这个处理器被称为文件事件处理器 file event handler。由于这个文件事件处理器是单线程的，所以Redis才叫做单线程的模型，但是它采用IO多路复用机制同时监听多个Socket，并根据Socket上的事件来选择对应的事件处理器进行处理。文件事件处理器的结构包含4个部分。 线程模型如下图：
   • 多个Socket
   • IO多路复用程序
   • 文件事件分派器
   • 事件处理器（命令请求处理器，命令回复处理器，连接应答处理器）

   

   

   多个 Socket 可能会产生不同的操作，每个操作对应不同的文件事件，但是IO多路复用程序会监听多个Socket，将Socket产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。 Redis客户端对服务端的每次调用都经历了发送命令，执行命令，返回结果三个过程。其中执行命令阶段，由于Redis是单线程来处理命令的，所有每一条到达服务端的命令不会立刻执行，所有的命令都会进入一个队列中，然后逐个被执行。并且多个客户端发送的命令的执行顺序是不确定的。但是可以确定的是不会有两条命令被同时执行，不会产生并发问题，这就是Redis的单线程基本模型。

   • 多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，然后程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。
   • 这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个客户端的网络IO连接请求（尽量减少网络 IO 的时间消耗）

   Redis直接自己构建VM机制，避免调用系统函数的时候浪费时间去移动和请求。

为什么Redis是单线程？

这里我们强调的单线程，指的是网络请求模块使用一个线程来处理，即一个线程处理所有网络请求，其他模块仍用了多个线程。

sadas

为什么使用单线程呢？

因为CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

但是，我们使用单线程的方式是无法发挥多核CPU 性能，不过我们可以通过在单机开多个Redis 实例来解决这个问题

Redis6.0 的多线程

1. Redis6.0 之前为什么一直不使用多线程？ Redis使用单线程的可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。
2. Redis6.0 为什么要引入多线程呢？ 因为Redis的瓶颈不在内存，而是在网络I/O模块带来CPU的耗时，所以Redis6.0的多线程是用来处理网络I/O这部分，充分利用CPU资源，减少网络I/O阻塞带来的性能损耗。
3. Redis6.0 怎么才能开启多线程？ 默认情况下Redis是关闭多线程的，可以在conf文件进行配置开启：
   • io-threads-do-reads yes
   • io-threads 线程数
   • 官方建议的线程数设置：4核的机器建议设置为2或3个线程，8核的建议设置为6个线程，线程数一定要小于机器核数，尽量不超过8个。
4. 多线程模式下，是否存在线程并发安全问题？ 如图，一次redis请求，要建立连接，然后获取操作的命令，然后执行命令，最后将响应的结果写到socket上。

在redis的多线程模式下，获取、解析命令，以及输出结果着两个过程，可以配置成多线程执行的，因为它毕竟是我们定位到的主要耗时点，但是命令的执行，也就是内存操作，依然是单线程运行的。所以，Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行，也就不存在并发安全问题。

也就是命令的获取和结果的传送时多线程操作的因为cpu 的延时主要在网络传输上。

Redis的五种数据结构的底层实现原理

Redis的两层数据结构简介

redis的性能高的原因之一是它每种数据结构都是经过专门设计的，并都有一种或多种数据结构来支持，依赖这些灵活的数据结构，来提升读取和写入的性能。如果要了解redis的数据结构，可以从两个不同的层面来讨论它：

（1）：第一个层面，是从使用者的角度，这一层面也是Redis暴露给外部的调用接口

string，list，hash，set，sorted set

（2）：第二个层面，是从内部实现的角度，属于更底层的实现，比如：

dict，sds，ziplist，quicklist，skiplist，intset

本文的重点在于讨论第二个层面：

• Redis数据结构的内部实现
• 这两个层面的数据结构之间的关系：Redis如何通过组合第二个层面的各种基础数据结构来实现第一个层面的更高层的数据结构

在讨论任何一个系统的内部实现的时候，我们都要先明确它的设计原则，这样我们才能更深刻地理解它为什么会进行如此设计的真正意图。在本文接下来的讨论中，我们主要关注以下几点：

• 存储效率。Redis是专用于存储数据的，它对于计算机资源的主要消耗就在于内存，因此节省内存是它非常非常重要的一个方面。这意味着Redis一定是非常精细地考虑了压缩数据、减少内存碎片等问题。
• 快速响应时间。与快速响应时间相对的，是高吞吐量。Redis是用于提供在线访问的，对于单个请求的响应时间要求很高，因此，快速响应时间是比高吞吐量更重要的目标。有时候，这两个目标是矛盾的。
• 单线程。Redis的性能瓶颈不在于CPU资源，而在于内存访问和网络IO。而采用单线程的设计带来的好处是，极大简化了数据结构和算法的实现。相反，Redis通过异步IO和pipelining等机制来实现高速的并发访问。显然，单线程的设计，对于单个请求的快速响应时间也提出了更高的要求。

redisObject：两层数据结构的桥梁

• redisObject就是Redis对外暴露的第一层面的数据结构：string, list, hash, set, sorted set，而每一种数据结构的底层实现所对应的是哪些第二层面的数据结构（dict, sds, ziplist, quicklist, skiplist等），则通过不同的encoding来区分。可以说，robj是联结两个层面的数据结构的桥梁。
• 为多种数据类型提供一种统一的表示方式。
• 允许同一类型的数据采用不同的内部表示，从而在某些情况下尽量节省内存。
• 支持对象共享和引用计数。当对象被共享的时候，只占用一份内存拷贝，进一步节省内存。

第一层数据结构

1. String: String数据结构是最简单的数据类型。一般用于复杂的计数功能的缓存：微博数，粉丝数等。 （1）底层实现方式：动态字符串sds 或者 long String的内部存储结构一般是sds（Simple Dynamic String，可以动态扩展内存），但是如果一个String类型的value的值是数字，那么Redis内部会把它转成long类型来存储，从而减少内存的使用。
   • 确切地说，String在Redis中是用一个robj来表示的。
   • 用来表示String的robj可能编码成3种内部表示：OBJ_ENCODING_RAW，OBJ_ENCODING_EMBSTR，OBJ_ENCODING_INT。其中前两种编码使用的是sds来存储，最后一种OBJ_ENCODING_INT编码直接把string存成了long型。
   • 在对string进行incr, decr等操作的时候，如果它内部是OBJ_ENCODING_INT编码，那么可以直接进行加减操作；如果它内部是OBJ_ENCODING_RAW或OBJ_ENCODING_EMBSTR编码，那么Redis会先试图把sds存储的字符串转成long型，如果能转成功，再进行加减操作。
   • 对一个内部表示成long型的string执行append, setbit, getrange这些命令，针对的仍然是string的值（即十进制表示的字符串），而不是针对内部表示的long型进行操作。比如字符串”32”，如果按照字符数组来解释，它包含两个字符，它们的ASCII码分别是0x33和0x32。当我们执行命令setbit key 7 0的时候，相当于把字符0x33变成了0x32，这样字符串的值就变成了”22”。而如果将字符串”32”按照内部的64位long型来解释，那么它是0x0000000000000020，在这个基础上执行setbit位操作，结果就完全不对了。因此，在这些命令的实现中，会把long型先转成字符串再进行相应的操作。
2. Hash Hash特别适合用于存储对象，因为一个对象的各个属性，正好对应一个hash结构的各个field，可以方便地操作对象中的某个字段。 （1）底层实现方式：压缩列表ziplist 或者 字典dict 当Hash中数据项比较少的情况下，Hash底层才用压缩列表ziplist进行存储数据，随着数据的增加，底层的ziplist就可能会转成dict，具体配置如下： hash-max-ziplist-entries 512 hash-max-ziplist-value 64

• 当hash中的数据项（即filed-value对）的数目超过512时，也就是ziplist数据项超过1024的时候
• 当hash中插入的任意一个value的长度超过了64字节的时候

当满足上面两个条件其中之一的时候，Redis就使用dict字典来实现hash。

Redis的hash之所以这样设计，是因为当ziplist变得很大的时候，它有如下几个缺点：

• 每次插入或修改引发的realloc操作会有更大的概率造成内存拷贝，从而降低性能。
• 一旦发生内存拷贝，内存拷贝的成本也相应增加，因为要拷贝更大的一块数据。
• 当ziplist数据项过多的时候，在它上面查找指定的数据项就会性能变得很低，因为ziplist上的查找需要进行遍历。

总之，ziplist本来就设计为各个数据项挨在一起组成连续的内存空间，这种结构并不擅长做修改操作。一旦数据发生改动，就会引发内存realloc，可能导致内存拷贝。

1. List list 的实现为一个双向链表，经常被用作队列使用，支持在链表两端进行push和pop操作，时间复杂度为O(1)；同时也支持在链表中的任意位置的存取操作，但是都需要对list进行遍历，支持反向查找和遍历，时间复杂度为O(n)。 list是一个能维持数据项先后顺序的列表（各个数据项的先后顺序由插入位置决定），便于在表的两端追加和删除数据，而对于中间位置的存取具有O(N)的时间复杂度。 list 的应用场景非常多，比如微博的关注列表，粉丝列表，消息列表等功能都可以用Redis的 list 结构来实现。可以利用lrange命令，做基于redis的分页功能。 （1）Redis3.2之前的底层实现方式：压缩列表ziplist 或者 双向循环链表linkedlist 当list存储的数据量比较少且同时满足下面两个条件时，list就使用ziplist存储数据：
   • list中保存的每个元素的长度小于 64 字节；
   • 列表中数据个数少于512个。

   当不能同时满足上面两个条件的时候，list就通过双向循环链表linkedlist来实现了 （2）Redis3.2及之后的底层实现方式：quicklist quicklist是一个双向链表，而且是一个基于ziplist的双向链表，quicklist的每个节点都是一个ziplist，结合了双向链表和ziplist的优点

2. Set: set是一个存放不重复值的无序集合，可以做全局去重的功能，提供了判断某个元素是否在set集合内的功能，这个也是list所不能提供的。基于set可以实现交集、并集、差集的操作，计算共同喜好，全部的喜好，自己独有的喜好等功能。 （1）底层实现方式：有序整数集合insert或者字典dict 当存储的数据同时满足下面这样两个条件的时候，Redis 就采用整数集合intset来实现set这种数据类型：
   • 存储的数都是整数
   • 存储的数据元素个数小于512个

   当不能同时满足这两个条件的时候，Redis就是用dict来存储集合中的数据。

3. Sorted Set： Sorted set多了一个权重参数score，集合中的元素能够按照score进行排列，可以做排行榜应用，取TOP N操作，另外，sorted set可以用来做延时任务，最后一个应用就是做范围内内查找。 底层实现方式：压缩列表ziplist 或者 zset 当存储的数据同时满足下边的两个条件的时候，Redis就使用压缩列表ziplist实现sorted set
   • 集合中每个数据的大小都要小于64字节
   • 元素个数要小于128个，也就是ziplist数据项小于256个

   当不能同时满足这两个条件的时候，Redis就使用zset来实现sorted set，这个zset包含一个dict + 一个skiplist。dict用来查询数据到分数(score)的对应关系，而skiplist用来根据分数查询数据（可能是范围查找）。

第二层数据结构

（3）intset与ziplist相比：

1. ziplist可以存储任意二进制串，而intset只能存储整数。
2. ziplist是无序的，而intset是从小到大有序的。因此，在ziplist上查找只能遍历，而在intset上可以进行二分查找，性能更高。
3. ziplist可以对每个数据项进行不同的变长编码（每个数据项前面都有数据长度字段len），而intset只能整体使用一个统一的编码（encoding）。
4. skiplist （1）什么是跳表 跳表是一种可以进行二分查找的有序链表，采用空间换时间的设计思路，跳表在原有的有序链表上面增加了多级索引（例如每两个节点就提取一个节点到上一级），通过索引来实现快速查找。跳表是一种动态数据结构，支持快速的插入、删除、查找操作，时间复杂度都为O(logn)，空间复杂度为 O(n)。跳表非常灵活，可以通过改变索引构建策略，有效平衡执行效率和内存消耗。 ① 跳表的删除操作：除了要删除原始链表中的节点，还要删除索引中的节点。 ② 插入元素后，索引的动态更新：不停的往跳表里面插入数据，如果不更新索引，就有可能出现某两个索引节点之间的数据非常多的情况，甚至退化成单链表。针对这种情况，我们在添加元素的时候，通过一个随机函数，同时选择将这个数据插入到部分索引层。比如随机函数生成了值 K，那我们就将这个结点添加到第一级到第K级这K级的索引中

Redis的数据过期清除策略 与 内存淘汰策略

在使用Redis时，我们一般会为Redis的缓存空间设置一个大小，不会让数据无限制地放入Redis缓存中。可以使用下面命令来设定缓存的大小，比如设置为4GB： CONFIG SET maxmemory 4gb

既然 Redis 设置了缓存的容量大小，那缓存被写满就是不可避免的。当缓存被写满时，我们需要考虑下面两个问题：决定淘汰哪些数据，如何处理那些被淘汰的数据。

Redis的数据过期清除策略

如果我们设置了Redis的key-value的过期时间，当缓存中的数据过期之后，Redis就需要将这些数据进行清除，释放占用的内存空间。Redis中主要使用 定期删除 + 惰性删除 两种数据过期清除策略。

1. 过期策略：定期删除+惰性删除： （1）定期删除：redis默认每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果有过期就删除。注意这里是随机抽取的。为什么要随机呢？你想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载。 为什么不用定时删除策略呢？ 定时删除，用一个定时器来负责监视key，过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key，因此没有采用这一策略。 (2) 惰性删除：定期删除可能导致很多过期的key 到了时间并没有被删除掉。这时就要使用到惰性删除。在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间并且过期了，是的话就删除。
2. 定期删除+惰性删除存在的问题 如果某个key过期后，定期删除没删除成功，然后也没再次去请求key，也就是说惰性删除也没生效。这时，如果大量过期的key堆积在内存中，redis的内存会越来越高，导致redis的内存块耗尽。那么就应该采用内存淘汰机制。

Redis的缓存淘汰策略

Redis共提供了8中缓存淘汰策略，其中 volatile-lfu 和 allkeys-lfu 是Redis 4.0版本新增的。

1. noeviction:不进行淘汰数据。一旦缓存被写满，再有写请求进来，Redis就不再提供服务，而是直接返回错误。Redis 用作缓存时，实际的数据集通常都是大于缓存容量的，总会有新的数据要写入缓存，这个策略本身不淘汰数据，也就不会腾出新的缓存空间，我们不把它用在 Redis 缓存中。
2. volatile-ttl：在设置了过期时间的键值对中，移除即将过期的键值对。
3. volatile-random：在设置了过期时间的键值对中，随机移除某个键值对。
4. volatile-lru: 在设置了过期时间的键值对中，移除最近最少使用的键值对。
5. volatile-lfu：在设置了过期时间的键值对中，移除最近最不频繁使用的键值对
6. allkeys-random：在所有键值对中，随机移除某个key。
7. allkeys-lru：在所有的键值对中，移除最近最少使用的键值对。
8. allkeys-lfu：在所有的键值对中，移除最近最不频繁使用的键值对

通常情况下推荐优先使用 allkeys-lru 策略。这样可以充分利用 LRU 这一经典缓存算法的优势，把最近最常访问的数据留在缓存中，提升应用的访问性能。 如果你的业务数据中有明显的冷热数据区分，建议使用allkeys-lru策略。 如果业务应用中的数据访问频率相差不大，没有明显的冷热数据区分，建议使用 allkeys-random 策略，随机选择淘汰的数据就行。 如果没有设置过期时间的键值对，那么 volatile-lru，volatile-lfu，volatile-random 和 volatile-ttl 策略的行为, 和 noeviction 基本上一致。

Redis中的LRU和LFU算法

1、LRU算法： LRU 算法的全称是 Least Recently Uses，按照最近最少使用的原则来筛选数据，最不常用的数据会被筛选出来。LRU 会把所有的数据组织成一个链表，链表的头和尾分别表示 MRU 端和 LRU 端，分别代表最近最常使用的数据和最近最不常用的数据。我们看一个例子。 MRU最近最多使用的，LRU最近最少使用的。

如果有一个新数据 45 要被写入缓存，但此时已经没有缓存空间了，也就是链表没有空余位置了，那么LRU 算法做两件事：数据 45 是刚被访问的，所以它会被放到 MRU 端；算法把 LRU 端的数据 5 从缓存中删除，相应的链表中就没有数据 5 的记录了。LRU认为刚刚被访问的数据，肯定还会被再次访问，所以就把它放在 MRU 端；长久不访问的数据，肯定就不会再被访问了，所以就让它逐渐后移到 LRU 端，在缓存满时，就优先删除它。

LRU 算法在实际实现时，需要用链表管理所有的缓存数据，移除元素时直接从链表队尾移除，增加时加到头部就可以了，但这会带来额外的空间开销。而且，当有数据被访问时，需要在链表上把该数据移动到 MRU 端，如果有大量数据被访问，就会带来很多链表移动操作，会很耗时，进而会降低 Redis 缓存性能。

所以，在 Redis 中，LRU 算法被做了简化，以减轻数据淘汰对缓存性能的影响。具体来说：Redis 默认会记录每个数据的最近一次访问的时间戳（由键值对数据结构 RedisObject 中的 lru 字段记录）。然后，Redis 在决定淘汰的数据时，第一次会随机选出 N 个数据，把它们作为一个候选集合。接下来，Redis 会比较这 N 个数据的 lru 字段，把 lru 字段值最小的数据从缓存中淘汰出去。当需要再次淘汰数据时，Redis 需要挑选数据进入第一次淘汰时创建的候选集合。这里的挑选标准是：能进入候选集合的数据的 lru 字段值必须小于候选集合中最小的 lru 值。当有新数据进入候选数据集后，如果候选数据集中的数据个数达到了 N 个，Redis 就把候选数据集中 lru 字段值最小的数据淘汰出去。这样一来，Redis 缓存不用为所有的数据维护一个大链表，也不用在每次数据访问时都移动链表项，提升了缓存的性能。 Redis 提供了一个配置参数 maxmemory-samples，这个参数就是 Redis 选出的数据个数 N。例如，我们执行如下命令，可以让 Redis 选出 100 个数据作为候选数据集：

CONFIG SET maxmemory-samples 100

RedisObject 的定义如下：（简单理解为一个 key-value）

typedef struct redisObject {
    unsigned type:4;  //表示restobject对外展示的类型 String ，还是 List 还是Hash 等等
    unsigned encoding:4;
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
                            * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

2、LFU算法 LFU是在Redis4.0后出现的，它的核心思想是根据key的最近被访问的频率进行淘汰，很少被访问的优先被淘汰，被访问的多的则被留下来。LFU算法能更好的表示一个key被访问的热度。假如你使用的是LRU算法，一个key很久没有被访问到，只刚刚是偶尔被访问了一次，那么它就被认为是热点数据，不会被淘汰，而有些key将来是很有可能被访问到的则被淘汰了。如果使用LFU算法则不会出现这种情况，因为使用一次并不会使一个key成为热点数据。它的使用与LRU有所区别：

LFU (Least Frequently Used) ：最近最不频繁使用，跟使用的次数有关，淘汰使用次数最少的。 LRU (Least Recently Used)：最近最少使用，跟使用的最后一次时间有关，淘汰最近使用时间离现在最久的。

LFU 实现比较复杂，需要考虑几个问题：

• 如果实现为链表，当对象被访问时按访问次数移动到链表的某个有序位置可能是低效的，因为可能存在大量访问次数相同的 key，最差情况是O(n)
• 某些 key 访问次数可能非常之大，理论上可以无限大，但实际上我们并不需要精确的访问次数
• 访问次数特别大的 key 可能以后都不再访问了，但是因为访问次数大而一直占用着内存不被淘汰，需要一个方法来逐步“驱除”（有点 LRU的意思），最简单的就是逐步衰减访问次数

本着能省则省的原则，Redis 只用了 24bit （server.lruclock 也是24bit）来记录上述的信息，是的不是 24byte，连32位指针都放不下！

16bit : 上一次递减时间 （解决第三个问题） 8bit : 访问次数 （解决第二个问题）

访问次数的计算如下：

uint8_t LFULogIncr(uint8_t counter) {
    if (counter == 255) return 255;
    double r = (double)rand()/RAND_MAX;
    double baseval = counter - LFU_INIT_VAL;
    if (baseval < 0) baseval = 0;
    double p = 1.0/(baseval*server.lfu_log_factor+1);
    if (r < p) counter++;
    return counter;
}

核心就是访问次数越大，访问次数被递增的可能性越小，最大 255，可以在配置 redis.conf 中写明访问多少次递增多少。由于访问次数是有限的，所以第一个问题也被解决了，直接一个255数组或链表都可以。

16bit 部分保存的是时间戳的后16位（分钟），表示上一次递减的时间，算法是这样执行，随机采样N个key，检查递减时间，如果距离现在超过 N 分钟（可配置），则递减或者减半（如果访问次数数值比较大）。 此外，由于新加入的 key 访问次数很可能比不被访问的老 key小，为了不被马上淘汰，新key访问次数设为 5.

Redis的缓存雪崩、缓存击穿、缓存穿透与缓存预热、缓存降级

缓存雪崩

1. 什么是缓存雪崩 如果缓存在某一时刻出现大规模的key失效，那么就会导致大量的请求打在数据库上面，导致数据库压力巨大，如果在高并发的情况下，可能孙坚就会导致数据库宕机。这时候如果运维马上又重启数据库，马上又会有新的流量把数据库打死。这就是缓存雪崩。
2. 问题分析： 造成缓存雪崩的关键在于同一时间的大规模的key失效，为什么会出现这个问题，主要有两种可能：第一种是Redis宕机，第二种可能就是采用了相同的过期时间。搞清楚原因之后，那么有什么解决方案呢？
3. 解决方案 （1）事前 1. 均匀过期：设置不同的过期时间，让缓存失效的时间尽量均匀，避免相同的过期时间导致缓存雪崩，造成大量数据库的访问。 2. 分级缓存：第一级缓存失效的基础上，访问二级缓存，每一级缓存的失效时间都不同。 3. 热点数据缓存永远不过期。 永不过期实际包含两层意思：
   • 物理不过期，针对热点key不设置过期时间
   • 逻辑过期，把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建

   4.保证Redis缓存的高可用，防止Redis宕机导致缓存雪崩的问题。可以使用 主从+ 哨兵，Redis集群来避免 Redis 全盘崩溃的情况。 (2)事中：

   1. ① 互斥锁：在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量，比如某个key只允许一个线程查询数据和写缓存，其他线程等待。这种方式会阻塞其他的线程，此时系统的吞吐量会下降
   2. 使用熔断机制，限流降级。当流量达到一定的阈值，直接返回“系统拥挤”之类的提示，防止过多的请求打在数据库上将数据库击垮，至少能保证一部分用户是可以正常使用，其他用户多刷新几次也能得到结果。

   （3）事后 开启Redis持久化机制，尽快恢复缓存数据，一旦重启，就能从磁盘上自动加载数据恢复内存中的数据。

缓存击穿

1. 什么是缓存击穿 缓存击穿跟雪崩有点类似，缓存雪崩是大规模的key失效，而缓存击穿是某个热点的key失效，大并发集中对其进行请求，就会造成大量请求读缓存没读到数据，从而导致高并发访问数据库，引起数据库压力剧增。这种现象就叫做缓存击穿。
2. 问题分析 关键在于某个热点的key失效了，导致大并发集中打在数据库上。所以要从两个方面解决，第一是否可以考虑热点key不设置过期时间，第二是否可以考虑降低打在数据库上的请求数量。
3. 解决方案 （1）在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量，比如某个key只允许一个线程查询数据和写缓存，其他线程等待，这种方式会阻塞其他线程，此时的系统的吞吐量会下降。 （2）热点数据缓存永远不过期 永不过期实际包含两层意思：
   • 物理不过期，针对热点key不设置过期时间
   • 逻辑过期，把国旗的时间存储再key对应的value里，如果发现要过期了，通过一个后台异步线程进行缓存的构建。

缓存穿透

1. 什么是缓存穿透 缓存穿透是指用户请求的数据在缓存中不存在即没有命中，同时在数据库中也不存在，导致用户每次请求该数据都要去数据库中查询一遍。如果有恶意攻击者不断请求系统中不存在的数据，会导致短时间大量请求落在数据库上，造成数据库压力过大，甚至导致数据库承受不住而宕机崩溃。
2. 问题分析 缓存穿透的关键在于Redis中查不到key值，它和缓存击穿的区别就是在于传进来的key在Redis中是不存在的，假如有黑客传进大量的不存在的key，那么大量的请求打在数据库上是很致命的问题，所以在日常开发中要对参数做好校验，一些非法的参数，不可能存在的key就直接返回错误提示。

1. 解决办法 （1）将无效的key存放在Redis中： 当出现Redis查不到数据，数据库也查不到数据的情况，我们就把这个key保存到Redis中，设置value=“null”，并设置其过期时间极短，后面再出现查询这个key的请求的时候，直接返回null，就不需要再查询数据库了。但这种处理方式是有问题的，假如传进来的这个不存在的Key值每次都是随机的，那存进Redis也没有意义。 （2）使用布隆过滤器 如果布隆过滤器判定某个 key 不存在布隆过滤器中，那么就一定不存在，如果判定某个 key 存在，那么很大可能是存在(存在一定的误判率)。于是我们可以在缓存之前再加一个布隆过滤器，将数据库中的所有key都存储在布隆过滤器中，在查询Redis前先去布隆过滤器查询 key 是否存在，如果不存在就直接返回，不让其访问数据库，从而避免了对底层存储系统的查询压力。

如何选择：针对一些恶意攻击，攻击带过来的大量key是随机，那么我们采用第一种方案就会缓存大量不存在key的数据。那么这种方案就不合适了，我们可以先对使用布隆过滤器方案进行过滤掉这些key。所以，针对这种key异常多、请求重复率比较低的数据，优先使用第二种方案直接过滤掉。而对于空数据的key有限的，重复率比较高的，则可优先采用第一种方式进行缓存。

缓存预热

1. 什么是缓存预热
   • 缓存预热是指系统上线后，提前将相关的缓存数据加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题，用户直接查询事先被预热的缓存数据。
   • 如果不进行预热，那么Redis初始状态数据为空，系统上线初期，对于高并发的流量，都会访问到数据库中， 对数据库造成流量的压力。
2. 缓存预热解决方案
   • 数据量不大的时候，工程启动的时候进行加载缓存动作；
   • 数据量大的时候，设置一个定时任务脚本，进行缓存的刷新；
   • 数据量太大的时候，优先保证热点数据进行提前加载到缓存。

缓存降级

缓存降级是指缓存失效或缓存服务器挂掉的情况下，不去访问数据库，直接返回默认数据或访问服务的内存数据。降级一般是有损的操作，所以尽量减少降级对于业务的影响程度。

在项目实战中通常会将部分热点数据缓存到服务的内存中，这样一旦缓存出现异常，可以直接使用服务的内存数据，从而避免数据库遭受巨大压力。

Redis的事务机制

Redis事务的相关命令

1. MULTI 用于标记事务块的开启。MULTI执行之后，Redis会将后续的命令逐个放到一个缓存队列中，当EXEC命令被调用时，所有队列中的命令才会被原子化执行。
2. EXEC 在一个事务中执行所有先前放入队列的命令，然后恢复正常的连接状态。当使用WATCH命令的时候，只有当受监控的命令没有被修改的时候，EXEC命令才会执行事务中的命令。
3. DISCARD 放弃事务，清除事务队列中的命令，然后恢复正常的连接状态。如果使用了UNWATCH命令，那么DISCARD就会取消当前连接监控的所有键。
4. WATCH 当某个事物需要按照条件执行的时候，就要使用该命令将kay设置为受监控的，如果在事务执行之前key被其他命令改动，那么整个事务将会被打断。WATCH命令可用于提供CAS功能。
5. UNWATCH 清楚事务中所有监控的键，如果调用了EXEC或者DISCARD命令，那么就不需要手动调用UNWATCH命令。

Redis事务的原理

1. 事务的定义 Redis的事务本质是一组命令的集合，一个事务中的命令要么全部执行，要么都不执行。事务的原理是先将属于一个事务的命令的发送给Redis，存放到一个队列中，再让Redis 依次执行这些命令，如果在发送EXEC命令前客户端断线了，则Redis会清空事务队列，事务中的所有命令都不会执行。而一旦客户端发送了EXEC命令，所有的命令就都会被执行，即使此后客户端断线也没关系，因为Redis中已经记录了所有要执行的命令。

除此之外，Redis的事务还能保证一个事务内的命令依次执行而不被其他命令插入。也就是说，在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，即不会被其它命令插入，不许加塞，等事务中的所有命令都执行完毕才去处理其他客户端的命令请求。即一次性、顺序性、排他性的执行一系列命令。

Redis的持久化机制

• Redis是一个基于内存的数据库，所有的数据都存放在内存中，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制。
• Redis的持久化机制有两种，第一种是RDB快照，第二种是AOF日志。RDB快照是一次全量备份，AOF是连续的增量备份。快照是内存数据的二进制序列化形式，在存储上非常紧凑，而 AOF 日志记录的是内存数据修改的指令记录文本。

RDB机制

RDB快照就是把数据以快照的形式保存在磁盘上，是某个时间点的一次全量数据备份，以二进制序列化形式的文件存储，并且在存储上非常紧密。 RDB持久化是指在指定的时间间隔内将内存中的数据集以快照的方式写入磁盘，并保存到一个名为dump.rdb的二进制文件中，也是默认的持久化方式，它恢复时是将快照文件从磁盘直接读到内存里。

1. 触发机制 RDB来说持久化触发机制有三种：save、bgsave、自动化触发 （1）save命令触发 该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB完成为止，如果数据量大的话会造成长时间的阻塞，所以线上环境一般禁止使用。 （2）bgsave命令触发 执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体流程如下： 执行bgsave命令时，Redis主进程会fork一个子进程来完成RDB的过程（主进程用来处理其他的请求,但是主进程的写到做不会同步到主内存，而是写到一个副本中，当持久化完成，把副本写到主内存），会先将数据写入到一个临时二进制文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件（可以理解为Copy On Write机制）。Redis主进程阻塞时间只有fork阶段的那一下。相对于save，阻塞时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令 fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。 (3) 自动触发： 自动触发是可以在redis.conf配置文件中修改，默认达到以下三种条件，就会自动触发持久化，触发后，底层调用的其实还有bgsave命令： 1分钟内改了1万次，5分钟内改了10次，或15分钟内改了1次。 save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。 save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。 save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。 如果不需要持久化机制，则可以注释掉所有的save命令。
2. RDB执行流程 （1）执行bgsave命令的时候，Redis主进程会检查是否有子进程在执行RDB/AOF持久化任务，如果有的话，直接返回，主要是为了性能的考虑，防止两个进程同时对磁盘进行写入操作 （2）Redis主进程fork一个子进程来执行执行RDB操作，fork操作会对主进程造成阻塞（影响Redis的读写），fork操作完成后会发消息给主进程，从而不再阻塞主进程（阻塞仅指主进程fork子进程的过程，后续子进程执行操作时不会阻塞） （3）RDB子进程把Redis主进程的内存数据，写入到一个临时的快照文件，持久化完成后，再使用临时快照文件替换掉原来的RDB文件。（该过程中主进程的读写不受影响，但Redis的写操作不会同步到主进程的主内存中，而是会写到一个临时的内存区域作为一个副本） （4）子进程完成RDB持久化后会发消息给主进程，通知RDB持久化完成，并将步骤（3）中的内存副本中的增量写数据同步到主内存
3. 优势： （1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。 （2）对于大规模数据的恢复，且对于数据恢复的完整性不是非常敏感的场景，RDB的恢复速度要比AOF方式更加的高效。 （3）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
4. 劣势： （1）fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。 （2）当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。 （3）在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。

AOF机制

1. 什么是AOF 每次都使用RDB机制全量备份的方式是非常耗时间的，因此Redis还提供了另一种持久化机制AOF（append only file）。AOF日志是持续增量的备份，将Redis执行过的每个写操作以日志的形式记录下来(读操作不记录)，只许追加文件但不可以改写文件(appendonly.aof文件)。redis启动的时候会读取该文件进行数据恢复，根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
2. AOF文件的rewrite机制 （1）因为AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，需要定期进行AOF重写，当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩，只保留可以恢复数据的最小指令集。redis提供了bgrewriteaof命令，fork一个新的进程对aof文件进行重写。 （2）重写原理：AOF文件持续增长而过大时，会fork出一条新进程来重写aof文件，将内存中的整个数据库内容用命令的方式重写了一个新的aof文件（注意：在重写时并不是读取旧的aof文件），在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新AOF文件期间，记录服务器执行的所有写命令。当子进程完成创建新AOF文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾，使得新旧两个AOF文件所保存的数据库状态一致。最后，服务器用新的AOF文件替换旧的AOF文件，以此来完成AOF文件重写操作。 （3）触发时机：Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
3. AOF持久化触发机制 （1）每修改同步：appendfsync always 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好。 （2）每秒同步：appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失。 （3）不同步：appendfsync no 从不同步 Linux 的 glibc 提供了 fsync()函数可以将指定文件的内容强制从内核缓存刷到磁盘。只要 Redis 进程实时调用 fsync 函数就可以保证 aof 日志不丢失。但是 fsync 是一个磁盘 IO 操作，它速度很慢，如果每条指令都要 fsync 一次，那么 Redis 高性能的地位就不保了。
4. 优点 （1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。 （2）AOF只是追加写日志文件，对服务器性能影响较小，速度比RDB要快，消耗的内存较少 （3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。 （4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。 5、劣势： （1）对于相同数据集的数据而言，aof文件要远大于rdb文件，恢复速度慢于rdb。 （2）对于每秒一次同步的情况，aof运行效率要慢于rdb，不同步效率和rdb相同。 注：如果同时开启两种持久化方式，在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

Redis4.0的混合持久化

• 仅使用RDB快照方式恢复数据，由于快照时间粒度较大时，会丢失大量数据。
• 仅使用AOF重放方式恢复数据，日志性能相对 rdb 来说要慢。在 Redis 实例很大的情况下，启动需要花费很长的时间。

为了解决这个问题，Redis4.0开始支持RDB和AOF的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）。RDB 文件的内容和增量的 AOF 日志文件存在一起，这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小

• 大量数据使用粗粒度（时间上）的rdb快照方式，性能高，恢复时间快。
• 增量数据使用细粒度（时间上）的AOF日志方式，尽量保证数据的不丢失。

在Redis重启时，进行AOF重写的时候就直接把RDB的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB和 AOF 的优点，快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF 里面的 RDB 部分是压缩格式不再是AOF 格式，可读性较差。

另外，可以使用下面这种方式：Master使用AOF，Slave使用RDB快照，master需要首先确保数据完整性，它作为数据备份的第一选择；slave提供只读服务或仅作为备机，它的主要目的就是快速响应客户端read请求或灾切换。

Redis主从复制原理

什么是Redis主从复制

1. 主从复制的架构 Redis Replication是一种 master-slave 模式的复制机制，这种机制使得 slave 节点可以成为与 master 节点完全相同的副本，可以采用一主多从或者级联结构。

主从复制的配置要点： （1）配从库不配主，从库配置：slaveof 主库IP 主库端口 （2）查看redis的配置信息：info replication

1. Redis为什么需要主从复制 使用Redis主从复制的原因主要是单台Redis节点存在以下的局限性： （1）Redis虽然读写的速度都很快，单节点的Redis能够支撑QPS大概在5w左右，如果上千万的用户访问，Redis就承载不了，成为了高并发的瓶颈。 （2）单节点的Redis不能保证高可用，当Redis因为某些原因意外宕机时，会导致缓存不可用 （3）CPU的利用率上，单台Redis实例只能利用单个核心，这单个核心在面临海量数据的存取和管理工作时压力会非常大。
2. 主从复制的好处 （1）数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。 （2）故障恢复：如果master宕掉了，使用哨兵模式，可以提升一个 slave 作为新的 master，进而实现故障转移，实现高可用 （3）负载均衡：可以轻易地实现横向扩展，实现读写分离，一个 master 用于写，多个 slave 用于分摊读的压力，从而实现高并发；
3. 主从复制的缺点 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave服务器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

主从复制的原理

从总体上来说，Redis主从复制的策略就是：当主从服务器刚建立连接的时候，进行全量同步；全量复制结束后，进行增量复制。当然，如果有需要，slave 在任何时候都可以发起全量同步。

1. 主从全量复制的流程 Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份，具体步骤如下： （1）slave服务器连接到master服务器，便开始进行数据同步，发送psync命令（Redis2.8之前是sync命令） （2）master服务器收到psync命令之后，开始执行bgsave命令生成RDB快照文件并使用缓存区记录此后执行的所有写命令
   • 如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是每个连接都执行一次，然后再把这一份持久化的数据发送给多个并发连接的slave。
   • 如果RDB复制时间超过60秒（repl-timeout），那么slave服务器就会认为复制失败，可以适当调节大这个参数

   (3) master服务器bgsave执行完之后，就会向所有Slava服务器发送快照文件，并在发送期间继续在缓冲区内记录被执行的写命令 client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败 (4) slave服务器收到RDB快照文件后，会将接收到的数据写入磁盘，然后清空所有旧数据，在从本地磁盘载入收到的快照到内存中，同时基于旧的数据版本对外提供服务。 (5) master服务器发送完RDB快照文件之后，便开始向slave服务器发送缓冲区中的写命令 (6) slave服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令； (7) 如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF 下图中的sync是2.8之前的命令，2.8之后改成psync。

1. 增量复制 Redis的增量复制是指在初始化的全量复制并开始正常工作之后，master服务器将发生的写操作同步到slave服务器的过程，增量复制的过程主要是master服务器每执行一个写命令就会向slave服务器发送相同的写命令，slave服务器接收并执行收到的写命令。
2. 断点续传 3.1 什么是断点续传 当master-slave网络连接断掉后，slave重新连接master时，会触发全量复制，但是从2.8版本开始，slave与master能够在网络连接断开重连后，只从中断处继续进行复制，而不必重新同步，这就是所谓的断点续传。 断电续传这个新特性使用psync命令，旧的实现中使用sync命令。Redis2.8版本可以检测出它所连接的服务器是否支持PSYNC命令，不支持的话使用SYNC命令。master服务器收到slave发送的psync命令后，会根据自身的情况做出对应的处理，可能是FULLRESYNC runid offset触发全量复制，也可能是CONTINUE触发增量复制 命令格式：psync runid offset 3.2 工作原理 （1） master服务器在内存缓冲区中给每个slave服务器都维护了一份同步备份日志（in-memory backlog），缓存最近一段时间的数据，默认大小1m，如果超过这个大小就会清理掉。 （2）同时，master 和 slave 服务器都维护了一个复制偏移量（replication offset）和 master线程ID（master run id），每个slave服务器在跟master服务器进行同步时都会携带master run id 和 最后一次同步的复制偏移量offset，通过offset可以知道主从之间的数据不一致的情况。 （3）当连接断开时，slave服务器会重新连接上master服务器，然后请求继续复制。假如主从服务器的两个master run id相同，并且指定的偏移量offset在同步备份日志中还有效，复制就会从上次中断的点开始继续。如果其中一个条件不满足，就会进行完全重新同步，因为主运行id不保存在磁盘中，如果从服务器重启的话就只能进行完全同步了。 master服务器维护的offset是存储在backlog中，msater就是根据slave发送的offset来从backlog中获取数据的 （4）在部分同步过程中，master会将本地记录的同步备份日志中记录的指令依次发送给slave服务器从而达到数据一致。
3. 无磁盘化复制 在前面全量复制的过程中，master会将数据保存在磁盘的rdb文件中然后发送给slave服务器，但如果master上的磁盘空间有限或者是使用比较低速的磁盘，这种操作会给master服务器带来较大的压力，那怎么办呢？在Redis2.8之后，可以通过无盘复制来达到目的，由master直接开启一个socket，在内存中创建RDB文件，再将rdb文件发送给slave服务器，不使用磁盘作为中间存储。（无盘复制一般应用在磁盘空间有限但是网络状态良好的情况下）

repl-diskless-sync ：是否开启无磁盘复制 repl-diskless-sync-delay：等待一定时长再开始复制，因为要等更多slave重新连接过来.

主从复制的其他问题

1. 主从复制的特点 （1）Redis使用异步复制，每次接收到写命令之后，先在内部写入数据，然后异步发送给slave服务器。但从Redis 2.8开始，从服务器会周期性的应答从复制流中处理的数据量。 （2）Redis主从复制不阻塞master服务器。也就是说当若干个从服务器在进行初始同步时，主服务器仍然可以处理外界请求。 （3）主从复制不阻塞slave服务器。当master服务器进行初始同步时，slave服务器返回的是以前旧版本的数据，如果你不想这样，那么在启动redis配置文件中进行设置，那么从redis在同步过程中来自外界的查询请求都会返回错误给客户端； 虽然说主从复制过程中对于从redis是非阻塞的，它会用旧的数据集来提供服务，但是当初始同步完成后，需删除旧数据集和加载新的数据集，在这个短暂时间内，从服务器会阻塞连接进来的请求，对于大数据集，加载到内存的时间也是比较多的 （4）主从复制提高了redis服务的扩展性，避免单个redis服务器的读写访问压力过大的问题，同时也可以给为数据备份及冗余提供一种解决方案； （5）使用主从复制可以为master服务器免除把数据写入磁盘的消耗，可以配置让master服务器不再将数据持久化到磁盘，而是通过连接让一个配置的slave类型的Redis服务器及时将相关数据持久化到磁盘。不过这种做法存在master类型的Redis服务器一旦重启，因为此时master服务器不进行持久化，所以数据为空，这时候通过主从同步可能导致slave类型的Redis服务器上的数据也被清空，所以这个配置要确保主服务器不会自动重启（详见第2点的“master开启持久化对主从架构的安全意义”）
2. master开启持久化对主从架构的安全意义 使用主从架构，必须开启master服务器的持久化机制，不建议用slave服务器作为master服务器的数据热备。当不能这么做时，比如考虑到延迟的问题，应该将master服务器配置为避免自动重启。否则，在关闭master服务器持久化机制并开始自动重启的情况下，会造成主从服务器数据被清空的情况。也就是master的持久化关闭，可能在master宕机重启的时候数据是空的（RDB和AOF都关闭了），此时就会将空数据复制到slave ，导致slave服务器的数据也丢了。
3. 过期key的处理 对于slave服务器上过期键的处理，主要是有master服务器负责。如果master过期了一个key，则由master服务器负责键的过期删除处理，然后将相关删除命令以数据同步的方式同步给slave服务器，slave服务器根据删除命令删除本地的key。

Redis的高可用

前面说过，通过主从复制，如果master服务器宕机了，可以提升一个slave服务器作为新的master服务器，实现故障的转移，实现高可用。也就是说，当master宕掉之后，可以手动执行“SLAVEOF no one”命令，重新选择一台服务器作为master服务器。但是呢，我们总不能保证每次master宕掉之后，都可以及时察觉并手动执行该命令，这时就可以使用“哨兵模式sentinel”，哨兵模式其实就是“SLAVEOF no one”命令的自动版，能够后台监控master是否故障，如果故障了，则根据投票数自动将slave转换为master，如果之前的master重启回来，不会造成双master冲突，因为原本的master会变成slave。

配置步骤： （1）在自定义的/myredis目录下新建sentinel.conf文件（名字绝不能错）。 （2）配置哨兵，在配置文件中写： sentinel monitor 被监控数据库名字 127.0.0.1 6379 1 最后的数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机。 （3）启动哨兵：redis-sentinel /myredis/sentinel.conf

Redis哨兵机制原理

什么是哨兵模式

1. 哨兵模式的架构

1. 什么是哨兵模式 在主从模式下（主从模式就是把上图的所有哨兵去掉），master节点负责写请求，然后异步同步给slave节点，从节点负责处理读请求。如果master宕机了，需要手动将从节点晋升为主节点，并且还要切换客户端的连接数据源。这就无法达到高可用，而通过哨兵模式就可以解决这一问题。 哨兵模式是Redis的高可用方式，哨兵节点是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。 哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点挂掉时，哨兵会第一时间感知到，并且在slave节点中重新选出来一个新的master，然后将新的master信息通知给client端，从而实现高可用。这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息。
2. 哨兵的主要工作任务 （1）监控：哨兵会不断的检查你的Master和Slave是否运行正常。 （2）提醒：当被监控的某个Redis节点出现问题时，哨兵可以通过 API 向管理员或者其他应用程序发送通知。 （3）自动故障迁移：当一个Master不能正常工作时，哨兵会进行自动故障迁移操作，将失效Master的其中一个Slave升级为新的Master，并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用新Master代替失效Master。

哨兵模式的搭建

哨兵模式的工作原理

哨兵是一个分布式系统，可以在一个架构中运行多个哨兵进程，这些进程使用流言协议(gossip protocols)来传播Master是否下线的信息，并使用投票协议(agreement protocols)来决定是否执行自动故障迁移，以及选择哪个Slave作为新的Master。哨兵模式的具体工作原理如下：

1. 心跳机制 （1）Sentinel与RedisNode：Redis Sentinel 是一个特殊的 Redis 节点。在哨兵模式创建时，需要通过配置指定 Sentinel 与 Redis Master Node 之间的关系，然后 Sentinel 会从主节点上获取所有从节点的信息，之后 Sentinel 会定时向主节点和从节点发送 info 命令获取其拓扑结构和状态信息。 （2）Sentinel与Sentinel：基于 Redis 的订阅发布功能， 每个 Sentinel 节点会向主节点的 sentinel：hello 频道上发送该 Sentinel 节点对于主节点的判断以及当前 Sentinel 节点的信息 ，同时每个 Sentinel 节点也会订阅该频道， 来获取其他 Sentinel 节点的信息以及它们对主节点的判断 通过以上两步所有的 Sentinel 节点以及它们与所有的 Redis 节点之间都已经彼此感知到，之后每个 Sentinel 节点会向主节点、从节点、以及其余 Sentinel 节点定时发送 ping 命令作为心跳检测， 来确认这些节点是否可达。
2. 判断master节点是否下线 （1）每个 sentinel 哨兵节点每隔1s 向所有的master、slave以及其他 sentinel 节点发送一个PING命令，作用是通过心跳检测，检测主从服务器的网络连接状态 （2）如果 master 节点回复 PING 命令的时间超过 down-after-milliseconds 设定的阈值（默认30s），则这个 master 会被 sentinel 标记为主观下线，修改其 flags 状态为SRI_S_DOWN （3）当sentinel 哨兵节点将 master 标记为主观下线后，会向其余所有的 sentinel 发送sentinel is-master-down-by-addr消息，询问其他sentinel是否同意该master下线 发送命令：sentinel is-master-down-by-addr <ip> <port> <current_epoch> <runid> ip：主观下线的服务ip port：主观下线的服务端口 current_epoch：sentinel的纪元 runid：*表示检测服务下线状态，如果是sentinel的运行id，表示用来选举领头sentinel （4）每个sentinel收到命令之后，会根据发送过来的 ip和port 检查自己判断的结果，回复自己是否认为该master节点已经下线了 回复内容主要包含三个参数（由于上面发送的runid参数是*，这里先忽略后两个参数） down_state（1表示已下线，0表示未下线） leader_runid（领头sentinal id） leader_epoch（领头sentinel纪元） (5) sentinel收到回复之后，如果同意master节点进入主观下线的sentinel数量大于等于quorum，则master会被标记为客观下线，即认为该节点已经不可用。 (6) 在一般情况下，每个 Sentinel 每隔 10s 向所有的Master，Slave发送 INFO 命令。当Master 被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次。作用：发现最新的集群拓扑结构
3. 基于Raft算法选举领头sentinel 到现在为止，已经知道了master客观下线，那就需要一个sentinel来负责故障转移，那到底是哪个sentinel节点来做这件事呢？需要通过选举实现，具体的选举过程如下： (1)判断客观下线的sentinel节点向其他 注意：这时的runid是自己的run id，每个sentinel节点都有一个自己运行时id （2）目标sentinel回复是否同意master下线并选举领头sentinel，选择领头sentinel的过程符合先到先得的原则。举例：sentinel1判断了客观下线，向sentinel2发送了第一步中的命令，sentinel2回复了sentinel1，说选你为领头，这时候sentinel3也向sentinel2发送第一步的命令，sentinel2会直接拒绝回复 （3）当sentinel发现选自己的节点个数超过 majority 的个数的时候，自己就是领头节点 （4）如果没有一个sentinel达到了majority的数量，等一段时间，重新选举.
4. 故障转移 故障转移到底要选择哪一个slaver节点来作为master呢？ 我们会认为哪个slave节点中的数据和master中的数据相识度高哪个slaver就是master了，其实哨兵模式也差不多是这样判断的。 (1) 在进行选择之前需要先剔除掉一些不满足条件的slaver，这些slaver不会作为变成master的备选 剔除列表中已经下线的从服务 剔除有5s没有回复sentinel的info命令的slave 剔除与已经下线的主服务连接断开时间超过 down-after-milliseconds * 10 + master宕机时长 的slaver （2）选主过程 ① 选择优先级最高的节点，通过sentinel配置文件中的replica-priority配置项，这个参数越小，表示优先级越高 ② 如果第一步中的优先级相同，选择offset最大的，offset表示主节点向从节点同步数据的偏移量，越大表示同步的数据越多 ③ 如果第二步offset也相同，选择run id较小的
5. 修改配置 新的master节点选择出来之后，还需要做一些事情配置的修改，如下： （1）领头sentinel会对选出来的从节点执行slaveof no one 命令让其成为主节点 （2）领头sentinel 向别的slave发送slaveof命令，告诉他们新的master是谁谁谁，你们向这个master复制数据 （3）如果之前的master重新上线时，领头sentinel同样会给起发送slaveof命令，将其变成从节点

Redis集群原理详解

Redis集群介绍

1. 为什么需要Redis集群 在讲Redis集群架构之前，我们先简单看Redis单实例的结构，从最开始的一主N重，到读写分离，再到Sentinel哨兵机制，单实例的Redis缓存足以应对大多数的使用场景，也能实现主从故障迁移。

但是，在某些场景下，单实例存Redis缓存会存在几个问题： （1）写并发：Redis单实例读写分离可以解决读操作的负载均衡，但对于写操作，仍然是全部落在了master节点上面，在海量数据高并发场景，一个节点写数据容易出现瓶颈，造成master节点的压力上升。 （2）海量数据的存储压力：单实例Redis本质上只有一台Master作为存储，如果面对海量数据的存储，一台Redis的服务器就应付不过来了，而且数据量太大意味着持久化成本高，严重时可能会阻塞服务器，造成服务请求成功率下降，降低服务的稳定性。 针对以上的问题，Redis集群提供了较为完善的方案，解决了存储能力受到单机限制，写操作无法负载均衡的问题。

1. 什么是Redis集群 Redis3.0加入了Redis的集群模式，实现了数据的分布式存储，对数据进行分片，将不同的数据存储在不同的master节点上面，从而解决了海量数据的存储问题。 Redis集群采用去中心化的思想，没有中心节点的说法，对于客户端来说，整个集群可以看成一个整体，可以连接任意一个节点进行操作，就像操作单一Redis实例一样，不需要任何代理中间件，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node。 Redis也内置了高可用机制，支持N个master节点，每个master节点都可以挂载多个slave节点，当master节点挂掉时，集群会提升它的某个slave节点作为新的master节点。

如上图所示，Redis集群可以看成多个主从架构组合起来的，每一个主从架构可以看成一个节点（其中，只有master节点具有处理请求的能力，slave节点主要是用于节点的高可用）

Redis集群的数据分布算法：哈希槽算法

1. 什么是哈希槽算法 前面讲到，Redis集群通过分布式存储的方式解决了单节点的海量数据存储的问题，对于分布式存储，需要考虑的重点就是如何将数据进行拆分到不同的Redis服务器上。常见的分区算法有hash算法、一致性hash算法，关于这些算法这里就不多介绍。
   • 普通hash算法：将key使用hash算法计算之后，按照节点数量来取余，即hash(key)%N。优点就是比较简单，但是扩容或者摘除节点时需要重新根据映射关系计算，会导致数据重新迁移。
   • 一致性hash算法：为每一个节点分配一个token，构成一个哈希环；查找时先根据key计算hash值，然后顺时针找到第一个大于等于该哈希值的token节点。优点是在加入和删除节点时只影响相邻的两个节点，缺点是加减节点会造成部分数据无法命中，所以一般用于缓存，而且用于节点量大的情况下，扩容一般增加一倍节点保障数据负载均衡。 没看明白

   Redis集群采用的算法是哈希槽分区算法。Redis集群中有16384个哈希槽（槽的范围是 0 -16383，哈希槽），将不同的哈希槽分布在不同的Redis节点上面进行管理，也就是说每个Redis节点只负责一部分的哈希槽。在对数据进行操作的时候，集群会对使用CRC16算法对key进行计算并对16384取模（slot = CRC16(key)%16383），得到的结果就是 Key-Value 所放入的槽，通过这个值，去找到对应的槽所对应的Redis节点，然后直接到这个对应的节点上进行存取操作。 使用哈希槽的好处就在于可以方便的添加或者移除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了；哈希槽数据分区算法具有以下几种特点：

   • 解耦数据和节点之间的关系，简化了扩容和收缩难度；
   • 节点自身维护槽的映射关系，不需要客户端代理服务维护槽分区元数据
   • 支持节点、槽、键之间的映射查询，用于数据路由，在线伸缩等场景

   槽的迁移与指派命令：CLUSTER ADDSLOTS 0 1 2 3 4 … 5000 默认情况下，redis集群的读和写都是到master上去执行的，不支持slave节点读和写，跟Redis主从复制下读写分离不一样，因为redis集群的核心的理念，主要是使用slave做数据的热备，以及master故障时的主备切换，实现高可用的。Redis的读写分离，是为了横向任意扩展slave节点去支撑更大的读吞吐量。而redis集群架构下，本身master就是可以任意扩展的，如果想要支撑更大的读或写的吞吐量，都可以直接对master进行横向扩展。

2. Redis中哈希槽相关的数据结构 （1）clusterNode数据结构:保存节点的当前状态，比如节点的创建时间，节点的名字，节点当前的配置纪元，节点的IP和地址，等等。

（2）clusterState数据结构：记录当前节点所认为的集群目前所处的状态。

（3）节点的槽指派信息： clusterNode数据结构的slots属性和numslot属性记录了节点负责处理哪些槽。 slots属性是一个二进制位数组(bit array)，这个数组的长度为16384/8=2048个字节，共包含16384个二进制位。Master节点用bit来标识对于某个槽自己是否拥有，时间复杂度为O(1)

（4）集群所有槽的指派信息： 当收到集群中其他节点发送的信息时，通过将节点槽的指派信息保存在本地的clusterState.slots数组里面，程序要检查槽i是否已经被指派，又或者取得负责处理槽i的节点，只需要访问clusterState.slots[i]的值即可，时间复杂度仅为O(1)

如上图所示，ClusterState 中保存的 Slots 数组中每个下标对应一个槽，每个槽信息中对应一个 clusterNode 也就是缓存的节点。这些节点会对应一个实际存在的 Redis 缓存服务，包括 IP 和 Port 的信息。Redis Cluster 的通讯机制实际上保证了每个节点都有其他节点和槽数据的对应关系。无论Redis 的客户端访问集群中的哪个节点都可以路由到对应的节点上，因为每个节点都有一份 ClusterState，它记录了所有槽和节点的对应关系。

1. 集群的请求重定向 前面讲到，Redis集群在客户端层面没有采用代理，并且无论Redis 的客户端访问集群中的哪个节点都可以路由到对应的节点上，下面来看看 Redis 客户端是如何通过路由来调用缓存节点的： （1）MOVED请求

如上图所示，Redis 客户端通过 CRC16(key)%16383 计算出 Slot 的值，发现需要找“缓存节点1”进行数据操作，但是由于缓存数据迁移或者其他原因导致这个对应的 Slot 的数据被迁移到了“缓存节点2”上面。那么这个时候 Redis 客户端就无法从“缓存节点1”中获取数据了。但是由于“缓存节点1”中保存了所有集群中缓存节点的信息，因此它知道这个 Slot 的数据在“缓存节点2”中保存，因此向 Redis 客户端发送了一个 MOVED 的重定向请求。这个请求告诉其应该访问的“缓存节点2”的地址。Redis 客户端拿到这个地址，继续访问“缓存节点2”并且拿到数据。 （2）ASK请求 上面的例子说明了，数据 Slot 从“缓存节点1”已经迁移到“缓存节点2”了，那么客户端可以直接找“缓存节点2”要数据。那么如果两个缓存节点正在做节点的数据迁移，此时客户端请求会如何处理呢？

Redis 客户端向“缓存节点1”发出请求，此时“缓存节点1”正向“缓存节点 2”迁移数据，如果没有命中对应的 Slot，它会返回客户端一个 ASK 重定向请求并且告诉“缓存节点2”的地址。客户端向“缓存节点2”发送 Asking 命令，询问需要的数据是否在“缓存节点2”上，“缓存节点2”接到消息以后返回数据是否存在的结果。 （3）频繁重定向造成的网络开销的处理：smart客户端

• 什么是 smart客户端： 在大部分情况下，可能都会出现一次请求重定向才能找到正确的节点，这个重定向过程显然会增加集群的网络负担和单次请求耗时。所以大部分的客户端都是smart的，所谓的smart客户端就是指客户端本地维护一份hashslot => node的映射表缓存，大部分情况下，直接走本地缓存就可以找到hashslot => node，不需要通过节点进行moved重定向。
• JedisCluster的工作原理
  • 在JedisCluster初始化的时候，就会随机选择一个node，初始化hashslot => node映射表，同时为每个节点创建一个JedisPool连接池。
  • 每次基于JedisCluster执行操作时，首先会在本地计算key的hashslot，然后在本地映射表找到对应的节点node。
  • 如果那个node正好还是持有那个hashslot，那么就ok；如果进行了reshard操作，可能hashslot已经不在那个node上了，就会返回moved。
  • 如果JedisCluter API发现对应的节点返回moved，那么利用该节点返回的元数据，更新本地的hashslot => node映射表缓存
  • 重复上面几个步骤，直到找到对应的节点，如果重试超过5次，那么就报错，JedisClusterMaxRedirectionException

1. hashslot迁移和ask重定向 如果hashslot正在迁移，那么会返回ask重定向给客户端。客户端接收到ask重定向之后，会重新定位到目标节点去执行，但是因为ask发生在hashslot迁移过程中，所以JedisCluster API收到ask是不会更新hashslot本地缓存。 虽然ASK与MOVED都是对客户端的重定向控制，但是有本质区别。ASK重定向说明集群正在进行slot数据迁移，客户端无法知道迁移什么时候完成，因此只能是临时性的重定向，客户端不会更新slots缓存。但是MOVED重定向说明键对应的槽已经明确指定到新的节点，客户端需要更新slots缓存。

Redis集群中节点的通信机制：goosip协议

redis集群的哈希槽算法解决的是数据的存取问题，不同的哈希槽位于不同的节点上，而不同的节点维护着一份它所认为的当前集群的状态，同时，Redis集群是去中心化的架构。那么，当集群的状态发生变化时，比如新节点加入、slot迁移、节点宕机、slave提升为新Master等等，我们希望这些变化尽快被其他节点发现，Redis是如何进行处理的呢？也就是说，Redis不同节点之间是如何进行通信进行维护集群的同步状态呢？ 在Redis集群中，不同的节点之间采用gossip协议进行通信，节点之间通讯的目的是为了维护节点之间的元数据信息。这些元数据就是每个节点包含哪些数据，是否出现故障，通过gossip协议，达到最终数据的一致性。

gossip协议，是基于流行病传播方式的节点或者进程之间信息交换的协议。原理就是在不同的节点间不断地通信交换信息，一段时间后，所有的节点就都有了整个集群的完整信息，并且所有节点的状态都会达成一致。每个节点可能知道所有其他节点，也可能仅知道几个邻居节点，但只要这些节可以通过网络连通，最终他们的状态就会是一致的。Gossip协议最大的好处在于，即使集群节点的数量增加，每个节点的负载也不会增加很多，几乎是恒定的。

Redis集群中节点的通信过程如下:

集群中每个节点都会单独开一个TCP通道，用于节点间彼此通信。 每个节点在固定周期内通过待定的规则选择几个节点发送ping消息 接收到ping消息的节点用pong消息作为响应

使用gossip协议的优点在于将元数据的更新分散在不同的节点上面，降低了压力；但是缺点就是元数据的更新有延时，可能导致集群中的一些操作会有一些滞后。另外，由于 gossip 协议对服务器时间的要求较高，时间戳不准确会影响节点判断消息的有效性。而且节点数量增多后的网络开销也会对服务器产生压力，同时结点数太多，意味着达到最终一致性的时间也相对变长，因此官方推荐最大节点数为1000左右。

redis cluster架构下的每个redis都要开放两个端口号，比如一个是6379，另一个就是加1w的端口号16379。 6379端口号就是redis服务器入口。 16379端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用的是一种叫gossip 协议的二进制协议

1. gossip协议的常见类型 gossip协议常见的消息类型包含： ping、pong、meet、fail等等。 （1）meet：主要用于通知新节点加入到集群中，通过「cluster meet ip port」命令，已有集群的节点会向新的节点发送邀请，加入现有集群。 （2）ping：用于交换节点的元数据。每个节点每秒会向集群中其他节点发送 ping 消息，消息中封装了自身节点状态还有其他部分节点的状态数据，也包括自身所管理的槽信息等等。
   • 因为发送ping命令时要携带一些元数据，如果很频繁，可能会加重网络负担。因此，一般每个节点每秒会执行 10 次 ping，每次会选择 5 个最久没有通信的其它节点。
   • 如果发现某个节点通信延时达到了 cluster_node_timeout / 2，那么立即发送 ping，避免数据交换延时过长导致信息严重滞后。比如说，两个节点之间都 10 分钟没有交换数据了，那么整个集群处于严重的元数据不一致的情况，就会有问题。所以 cluster_node_timeout 可以调节，如果调得比较大，那么会降低 ping 的频率。
   • 每次 ping，会带上自己节点的信息，还有就是带上 1/10 其它节点的信息，发送出去，进行交换。至少包含 3 个其它节点的信息，最多包含 （总节点数 - 2）个其它节点的信息。

   （3）pong：piing和meet消息的响应，同样包含了自身节点的状态和集群元数据的消息。 （4）fail: 某个节点判断另一个节点fail之后，向集群所有节点广播该节点挂掉的消息，其他节点收到消息后标记已下线。 由于Redis集群的去中心化以及gossip通信机制，Redis集群中的节点只能保证最终一致性。例如当加入新节点时(meet)，只有邀请节点和被邀请节点知道这件事，其余节点要等待 ping 消息一层一层扩散。除了 Fail 是立即全网通知的，其他诸如新节点、节点重上线、从节点选举成为主节点、槽变化等，都需要等待被通知到，也就是Gossip协议是最终一致性的协议。

2. meet命令的实现

（1）节点A会为节点B创建一个clusterNode结构，并将该结构添加到自己的clusterState.nodes字典里面。 （2）节点A根据CLUSTER MEET命令给定的IP地址和端口号，向节点B发送一条MEET消息 （3）节点B接收到节点A发送的MEET消息，节点B会为节点A创建一个clusterNode结构，并将该结构添加到自己的clusterState.nodes字典里面。 （4）节点B向节点A返回一条PONG消息。 （5）节点A将受到节点B返回的PONG消息，通过这条PONG消息，节点A可以知道节点B已经成功的接收了自己发送的MEET消息。 （6）之后，节点A将向节点B返回一条PING消息。 （7）节点B将接收到的节点A返回的PING消息，通过这条PING消息节点B可以知道节点A已经成功的接收到了自己返回的PONG消息，握手完成。 （8）之后，节点A会将节点B的信息通过Gossip协议传播给集群中的其他节点，让其他节点也与节点B进行握手，最终，经过一段时间后，节点B会被集群中的所有节点认识。

集群的扩容与收缩

作为分布式部署的缓存节点总会遇到缓存扩容和缓存故障的问题。这就会导致缓存节点的上线和下线的问题。由于每个节点中保存着槽数据，因此当缓存节点数出现变时，这些槽数据会根据对应的虚拟槽算法被迁移到其他的缓存节点上。所以对于redis集群，集群伸缩主要在于槽和数据在节点之间移动。

1. 扩容 (1) 启动新节点 (2) 使用cluster meet命令将新节点加入到集群 (3) 迁移槽和数据：添加新节点后，需要将一些槽盒数据从旧节点迁移到新结点

如上图所示，集群中本来存在“缓存节点1”和“缓存节点2”，此时“缓存节点3”上线了并且加入到集群中。此时根据虚拟槽的算法，“缓存节点1”和“缓存节点2”中对应槽的数据会应该新节点的加入被迁移到“缓存节点3”上面。 新节点加入到集群的时候，作为孤儿节点是没有和其他节点进行通讯的。因此需要在集群中任意节点执行 cluster meet 命令让新节点加入进来。假设新节点是 192.168.1.1 5002，老节点是 192.168.1.1 5003，那么运行以下命令将新节点加入到集群中。 192.168.1.1 5003> cluster meet 192.168.1.1 5002 这个是由老节点发起的，有点老成员欢迎新成员加入的意思。新节点刚刚建立没有建立槽对应的数据，也就是说没有缓存任何数据。如果这个节点是主节点，需要对其进行槽数据的扩容；如果这个节点是从节点，就需要同步主节点上的数据。总之就是要同步数据。

如上图所示，由客户端发起节点之间的槽数据迁移，数据从源节点往目标节点迁移。 （1）客户端对目标节点发起准备导入槽数据的命令，让目标节点准备好导入槽数据。这里使用 cluster setslot {slot} importing {sourceNodeId} 命令。 （2）之后对源节点发起送命令，让源节点准备迁出对应的槽数据。使用命令 cluster setslot {slot} importing {sourceNodeId}。 （3）此时源节点准备迁移数据了，在迁移之前把要迁移的数据获取出来。通过命令 cluster getkeysinslot {slot} {count}。Count 表示迁移的 Slot 的个数。 （4）然后在源节点上执行，migrate {targetIP} {targetPort} “” 0 {timeout} keys {keys} 命令，把获取的键通过流水线批量迁移到目标节点。 （5）重复 3 和 4 两步不断将数据迁移到目标节点。 （6）完成数据迁移到目标节点以后，通过 cluster setslot {slot} node {targetNodeId} 命令通知对应的槽被分配到目标节点，并且广播这个信息给全网的其他主节点，更新自身的槽节点对应表。

1. 收缩
   • 迁移槽
   • 忘记节点,通过命令 cluster forget {downNodeId} 通知其他的节点

为了安全删除节点，Redis集群只能下线没有负责槽的节点。因此如果要下线有负责槽的master节点，则需要先将它负责的槽迁移到其他节点。迁移的过程也与上线操作类似，不同的是下线的时候需要通知全网的其他节点忘记自己，此时通过命令 cluster forget {downNodeId} 通知其他的节点。

集群的故障检测与故障转恢复机制

1. 集群的故障检测 Redis集群的故障检测是基于gossip协议的，集群中的每个节点都会定期地向集群中的其他节点发送PING消息，以此交换各个节点状态信息，检测各个节点状态：在线状态、疑似下线状态PFAIL、已下线状态FAIL。 (1) 主观下线（pfail）：当节点A检测到与节点B的通讯时间超过了cluster-node-timeout 的时候，就会更新本地节点状态，把节点B更新为主观下线。 主观下线并不能代表某个节点真的下线了，有可能是节点A与节点B之间的网络断开了，但是其他的节点依旧可以和节点B进行通讯。 (2)客观下线： 由于集群内的节点会不断地与其他节点进行通讯，下线信息也会通过 Gossip 消息传遍所有节点，因此集群内的节点会不断收到下线报告。 当半数以上的主节点标记了节点B是主观下线时，便会触发客观下线的流程（该流程只针对主节点，如果是从节点就会忽略）。将主观下线的报告保存到本地的 ClusterNode 的结构fail_reports链表中，并且对主观下线报告的时效性进行检查，如果超过 cluster-node-timeout*2 的时间，就忽略这个报告，否则就记录报告内容，将其标记为客观下线。 接着向集群广播一条主节点B的Fail 消息，所有收到消息的节点都会标记节点B为客观下线。
2. 集群故障恢复 当故障节点下线后，如果是持有槽的主节点则需要在其从节点中找出一个替换它，从而保证高可用。此时下线主节点的所有从节点都担负着恢复义务，这些从节点会定时监测主节点是否进入客观下线状态，如果是，则触发故障恢复流程。故障恢复也就是选举一个节点充当新的master，选举的过程是基于Raft协议选举方式来实现的。
   1. 从节点过滤 检查每个slave节点与master节点断开连接的时间，如果超过了cluster-node-timeout * cluster-slave-validity-factor，那么就没有资格切换成master.
   2. 投票选举 （1）节点排序 对通过过滤条件的所有节点进行排序，按照priority，offset，runid排序，排序越靠前的节点，越优先进行选举。
      • priority的值越低，优先级越高
      • offset越大，表示从master节点复制的数据越多，选举时间越靠前，优先进行选举
      • offset相同，run id越小，优先级越高

      （2）更新配置纪元 每个主节点会去更新配置纪元，这个值是不断增加的整数。这个值记录了每个节点的版本和整个集群的版本。每当发生重要的事情的时候（例如：出现新节点从节点精选）都会增加全局的配置纪元并且赋给相关的主节点，用来记录这个事件。更新这个值的目的是，保证所有主节点对这件“大事”保持一致，大家都统一成一个配置纪元，表示大家都知道这个"大事"了。 （3）发起选举： 更新完配置纪元以后，从节点会向集群发起广播选举的消息（CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST），要求所有收到这条消息，并且具有投票权的主节点进行投票。每个从节点在一个纪元中只能发起一次选举。 （4）选举投票 如果一个主节点具有投票权，并且这个主节点尚未投票给其他从节点，那么主节点将向要求投票的从节点返回一条CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，表示这个主节点支持从节点成为新的主节点。每个参与选举的从节点都会接收CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK消息，并根据自己收到了多少条这种消息来统计自己获得了多少主节点的支持。 如果超过(N/2 + 1)数量的master节点都投票给了某个从节点，那么选举通过，这个从节点可以切换成master，如果在 cluster-node-timeout*2 的时间内从节点没有获得足够数量的票数，本次选举作废，更新配置纪元，并进行第二轮选举，直到选出新的主节点为止。 在第(1)步排序领先的从节点通常会获得更多的票，因为它触发选举的时间更早一些，获得票的机会更大

   3. 替换主节点 当满足投票条件的从节点被选出来以后，会触发替换主节点的操作。删除原主节点负责的槽数据，把这些槽数据添加到自己节点上，并且广播让其他的节点都知道这件事情，新的主节点诞生了。 (1) 被选中的从节点执行SLAVEOF NO ONE命令，使其成为新的主节点。 (2) 新的主节点会撤销所有对已下线主节点的槽指派，并将这些槽全部指派给自己 (3) 新的主节点对集群进行广播PONG消息，告知其他节点已经成为新的主节点 (4) 新的主节点开始接收和处理槽相关的请求 备注：如果集群中某个节点的master和slave节点都宕机了，那么集群就会进入fail状态，因为集群的slot映射不完整。如果集群超过半数以上的master挂掉，无论是否有slave，集群都会进入fail状态。

Redis集群的搭建

Redis集群的搭建可以分为以下几个部分

1. 启动节点：将节点以集群模式启动，读取或者生成集群配置文件，此时节点是独立的。
2. 节点握手：节点通过gossip协议通信，将独立的节点连成网络，主要使用meet命令。
3. 槽指派：将16384个槽位分配给主节点，以达到分片保存数据库键值对的效果。

Redis集群的运维

1. 数据迁移问题 Redis集群可以进行节点的动态扩容缩容，这一过程目前还处于半自动状态，需要人工介入。在扩缩容的时候，需要进行数据迁移。而 Redis为了保证迁移的一致性，迁移所有操作都是同步操作，执行迁移时，两端的 Redis均会进入时长不等的阻塞状态，对于小Key，该时间可以忽略不计，但如果一旦Key的内存使用过大，严重的时候会接触发集群内的故障转移，造成不必要的切换。
2. 带宽消耗问题 Redis集群是无中心节点的集群架构，依靠Gossip协议协同自动化修复集群的状态，但goosip有消息延时和消息冗余的问题，在集群节点数量过多的时候，goosip协议通信会消耗大量的带宽，主要体现在以下几个方面：
   • 消息发送频率：跟cluster-node-timeout密切相关，当节点发现与其他节点的最后通信时间超过 cluster-node-timeout/2时会直接发送ping消息
   • 消息数据量：每个消息主要的数据占用包含：slots槽数组（2kb）和整个集群1/10的状态数据
   • 节点部署的机器规模：机器的带宽上限是固定的，因此相同规模的集群分布的机器越多，每台机器划分的节点越均匀，则整个集群内整体的可用带宽越高
   • 在满足业务需求的情况下尽量避免大集群，同一个系统可以针对不同业务场景拆分使用若干个集群。
   • 适度提供cluster-node-timeout降低消息发送频率，但是cluster-node-timeout还影响故障转移的速度，因此需要根据自身业务场景兼顾二者平衡
   • 如果条件允许尽量均匀部署在更多机器上，避免集中部署。如果有60个节点的集群部署在3台机器上每台20个节点，这是机器的带宽消耗将非常严重
3. Pub/Sub广播问题 集群模式下内部对所有publish命令都会向所有节点进行广播，加重带宽负担，所以集群应该避免频繁使用Pub/sub功能。
4. 集群倾斜 集群倾斜是指不同节点之间数据量和请求量出现明显差异，这种情况将加大负载均衡和开发运维的难度。因此需要理解集群倾斜的原因 （1）数据倾斜：
   • 节点和槽分配不均
   • 不同的槽对饮的键的数量差异过大
   • 集合对象包含大量元素
   • 内存相关配置不一致 （2）请求倾斜 合理设计键，热点大集合对象做拆分或者使用hmget代替hgettall避免整体获取。
5. 集群读写分离 集群模式下读写分离成本比较高，直接扩展主节点数量来提高集群性能是更好的选择。

Redis的分布式锁

什么是分布式锁

1. 什么是分布式锁 分布式锁，即分布式系统的锁，在单体应用中我们通过锁解决的是控制共享资源访问的问题，而分布式锁，就是解决了分布式系统中控制共享资源访问的问题，与单体应用不同的是，分布式系统中竞争共享资源的最小粒度从线程升级成了进程。
2. 分布式锁应该具备哪些条件 在分布式系统的环境下，一个方法在同一时间只能被一个机器的一个线程执行。 高可用的获取锁与释放锁 高性能的获取锁与释放锁 具备可重入特性（可理解为重新进入，由多于一个任务并发使用，而不必担心数据错误） 具备锁失效机制，即自动解锁，防止死锁
3. 分布式锁的实现方式 基于数据库实现分布式锁 基于Zookeeper实现分布式锁(注册中心)

基于数据库的分布式锁

基于数据库的锁实现也有两种方式，一是基于数据库表的增删，另一种是基于数据库排他锁。

在查询语句后面增加for update，数据库会在查询过程中给数据库表增加排他锁。获得排它锁的线程即可获得分布式锁，当获得锁之后，可以执行方法的业务逻辑，执行完方法之后，释放锁connection.commit()。当某条记录被加上排他锁之后，其他线程无法获取排他锁并被阻塞。 3. 基于数据库锁的优缺点： 上面两种方式都是依赖数据库表，一种是通过表中的记录判断当前是否有锁存在，另外一种是通过数据库的排他锁来实现分布式锁。

• 优点是直接借助数据库，简单容易理解。
• 缺点是操作数据库需要一定的开销，性能问题需要考虑。

基于Zookeeper的分布式锁

基于zookeeper临时有序节点可以实现的分布式锁。每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。 （第三方库有 Curator，Curator提供的InterProcessMutex是分布式锁的实现） Zookeeper实现的分布式锁存在两个个缺点： （1）性能上可能并没有缓存服务那么高，因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同步到所有的Follower机器上。 （2）zookeeper的并发安全问题：因为可能存在网络抖动，客户端和ZK集群的session连接断了，zk集群以为客户端挂了，就会删除临时节点，这时候其他客户端就可以获取到分布式锁了。

基于redis的分布式锁

redis命令说明：

（1）setnx命令：set if not exists，当且仅当 key 不存在时，将 key 的值设为 value。若给定的 key 已经存在，则 SETNX 不做任何动作。
返回1，说明该进程获得锁，将 key 的值设为 value
返回0，说明其他进程已经获得了锁，进程不能进入临界区。
命令格式：setnx lock.key lock.value

（2）get命令：获取key的值，如果存在，则返回；如果不存在，则返回nil
命令格式：get lock.key

（3）getset命令：该方法是原子的，对key设置newValue这个值，并且返回key原来的旧值。
命令格式：getset lock.key newValue

（4）del命令：删除redis中指定的key
命令格式：del lock.key

方案一：基于set命令的分布式锁

1. 加锁：使用setnx进行加锁，当该指令返回1时，说明成功获得锁
2. 解锁：当得到锁的线程执行完任务之后，使用del命令释放锁，以便其他线程可以继续执行setnx命令来获得锁 （1）存在的问题：假设线程获取了锁之后，在执行任务的过程中挂掉，来不及显示地执行del命令释放锁，那么竞争该锁的线程都会执行不了，产生死锁的情况。 （2）解决方案：设置锁超时时间
3. 设置锁超时时间：setnx 的 key 必须设置一个超时时间，以保证即使没有被显式释放，这把锁也要在一定时间后自动释放。可以使用expire命令设置锁超时时间 （1）存在问题：setnx 和 expire 不是原子性的操作，假设某个线程执行setnx 命令，成功获得了锁，但是还没来得及执行expire 命令，服务器就挂掉了，这样一来，这把锁就没有设置过期时间了，变成了死锁，别的线程再也没有办法获得锁了。 （2）解决方案：redis的set命令支持在获取锁的同时设置key的过期时间
4. 使用set命令加锁并设置锁过期时间： 命令格式：set <lock.key> <lock.value> nx ex <expireTime> 1）存在问题： ① 假如线程A成功得到了锁，并且设置的超时时间是 30 秒。如果某些原因导致线程 A 执行的很慢，过了 30 秒都没执行完，这时候锁过期自动释放，线程 B 得到了锁。 ② 随后，线程A执行完任务，接着执行del指令来释放锁。但这时候线程 B 还没执行完，线程A实际上删除的是线程B加的锁。 （2）解决方案： 可以在 del 释放锁之前做一个判断，验证当前的锁是不是自己加的锁。在加锁的时候把当前的线程 ID 当做value，并在删除之前验证 key 对应的 value 是不是自己线程的 ID。但是，这样做其实隐含了一个新的问题，get操作、判断和释放锁是两个独立操作，不是原子性。对于非原子性的问题，我们可以使用Lua脚本来确保操作的原子性
5. 锁续期：（这种机制类似于redisson的看门狗机制，文章后面会详细说明） 虽然步骤4避免了线程A误删掉key的情况，但是同一时间有 A，B 两个线程在访问代码块，仍然是不完美的。怎么办呢？我们可以让获得锁的线程开启一个守护线程，用来给快要过期的锁“续期”。 ① 假设线程A执行了29 秒后还没执行完，这时候守护线程会执行 expire 指令，为这把锁续期 20 秒。守护线程从第 29 秒开始执行，每 20 秒执行一次。 ② 情况一：当线程A执行完任务，会显式关掉守护线程。 ③ 情况二：如果服务器忽然断电，由于线程 A 和守护线程在同一个进程，守护线程也会停下。这把锁到了超时的时候，没人给它续命，也就自动释放了。

方案二：基于setnx、get、getset的分布式锁

Redis缓存与数据库双写一致性

首先，缓存由于其高并发和高性能的特性，已经在项目中被广泛使用。在读取缓存方面，大家没啥疑问，都是按照下图的流程来进行业务操作。

但是在更新缓存方面，对于更新完数据库，是更新缓存呢，还是删除缓存呢？更新这个问题上存在一些不同的看法。 讨论三种更新策略：

1. 先更新数据库，再更新缓存
2. 先删除缓存，再更新数据库
3. 先更新数据库，再删除缓存

先更新数据库，再更新缓存

这个方案一般是不行的。 原因一：从线程安全角度看，同时有请求A和请求B进行更新操作，那么可能会出现：

（1）线程A更新了数据库 （2）线程B更新了数据库 （3）线程B更新了缓存 （4）线程A更新了缓存 这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存，这就导致了脏数据。

原因二：从业务的场景角度看，存在以下两个问题

（1）如果是一个数据库写多读少的业务场景求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。 （2）如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。

接下来讨论的就是争议最大的，先删缓存，再更新数据库。还是先更新数据库，再删缓存的问题.

先删缓存，再更新数据库

先更新数据库，在删除缓存

这个缓存策略也就是:

失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。 命中：应用程序从cache中取数据，取到后返回。 更新：先把数据存到数据库中，成功后，再让缓存失效。

但是这种策略并不是不存在并发问题，如果发生下述情况，还是会产生脏数据的。假设这会有两个请求，一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生： （1）缓存刚好失效 （2）请求A查询数据库，得一个旧值 （3）请求B将新值写入数据库 （4）请求B删除缓存 （5）请求A将查到的旧值写入缓存 是发生上述脏数据的情况有一个先天性条件，就是步骤（3）的写数据库操作比步骤（2）的读数据库操作耗时更短，才有可能使得步骤（4）先于步骤（5）。但是数据库的读操作的速度一般是远快于写操作的，因此步骤（3）耗时比步骤（2）更短，所以这一情形很难出现。 如果一定要解决怎么办？ 首先，给缓存设有效时间是一种方案。 其次，采用策略（2）里给出的异步延时删除策略，保证读请求完成以后，再进行删除操作。