Redis知识汇总

2、丰富的数据类型，Redis有8种数据类型，当然常用的主要是 String、Hash、List、Set、 SortSet 这5种类型，他们都是基于键值的方式组织数据。每一种数据类型提供了非常丰富的操作命令，可以满足绝大部分需求，如果有特殊需求还能自己通过 lua 脚本自己创建新的命令（具备原子性）；

3、除了提供的丰富的数据类型，Redis还提供了像慢查询分析、性能测试、Pipeline、事务、Lua自定义命令、Bitmaps、HyperLogLog、发布/订阅、Geo等个性化功能。

4、Redis的代码开源在GitHub，代码非常简单优雅，任何人都能够吃透它的源码；它的编译安装也是非常的简单，没有任何的系统依赖；有非常活跃的社区，各种客户端的语言支持也是非常完善。另外它还支持事务（没用过）、持久化、主从复制让高可用、分布式成为可能。

Redis为什么快？

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路I/O复用模型，非阻塞IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

以上几点都比较好理解，下边我们针对多路 I/O 复用模型进行简单的探讨：多路 I/O 复用模型多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。

这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以上几点造就了 Redis 具有很高的吞吐量。

哪些场景使用Redis

一：缓存——热数据

热点数据（经常会被查询，但是不经常被修改或者删除的数据），首选是使用redis缓存，毕竟强大到冒泡的QPS和极强的稳定性不是所有类似工具都有的，而且相比于memcached还提供了丰富的数据类型可以使用，另外，内存中的数据也提供了AOF和RDB等持久化机制可以选择，要冷、热的还是忽冷忽热的都可选。

结合具体应用需要注意一下：很多人用spring的AOP来构建redis缓存的自动生产和清除，过程可能如下：

Select 数据库前查询redis，有的话使用redis数据，放弃select 数据库，没有的话，select 数据库，然后将数据插入redis
update或者delete数据库钱，查询redis是否存在该数据，存在的话先删除redis中数据，然后再update或者delete数据库中的数据

上面这种操作，如果并发量很小的情况下基本没问题，但是高并发的情况请注意下面场景：

为了update先删掉了redis中的该数据，这时候另一个线程执行查询，发现redis中没有，瞬间执行了查询SQL，并且插入到redis中一条数据，回到刚才那个update语句，这个悲催的线程压根不知道刚才那个该死的select线程犯了一个弥天大错！于是这个redis中的错误数据就永远的存在了下去，直到下一个update或者delete。

二：计数器

诸如统计点击数等应用。由于单线程，可以避免并发问题，保证不会出错，而且100%毫秒级性能！爽。

命令：INCRBY

当然爽完了，别忘记持久化，毕竟是redis只是存了内存！

三：队列

相当于消息系统，ActiveMQ，RocketMQ等工具类似，但是个人觉得简单用一下还行，如果对于数据一致性要求高的话还是用RocketMQ等专业系统。
由于redis把数据添加到队列是返回添加元素在队列的第几位，所以可以做判断用户是第几个访问这种业务
队列不仅可以把并发请求变成串行，并且还可以做队列或者栈使用

四：位操作（大数据处理）

用于数据量上亿的场景下，例如几亿用户系统的签到，去重登录次数统计，某用户是否在线状态等等。

想想一下腾讯10亿用户，要几个毫秒内查询到某个用户是否在线，你能怎么做？千万别说给每个用户建立一个key，然后挨个记（你可以算一下需要的内存会很恐怖，而且这种类似的需求很多，腾讯光这个得多花多少钱。。）好吧。这里要用到位操作——使用setbit、getbit、bitcount命令。

原理是：

redis内构建一个足够长的数组，每个数组元素只能是0和1两个值，然后这个数组的下标index用来表示我们上面例子里面的用户id（必须是数字哈），那么很显然，这个几亿长的大数组就能通过下标和元素值（0和1）来构建一个记忆系统，上面我说的几个场景也就能够实现。用到的命令是：setbit、getbit、bitcount

五：分布式锁与单线程机制

验证前端的重复请求（可以自由扩展类似情况），可以通过redis进行过滤：每次请求将request Ip、参数、接口等hash作为key存储redis（幂等性请求），设置多长时间有效期，然后下次请求过来的时候先在redis中检索有没有这个key，进而验证是不是一定时间内过来的重复提交
秒杀系统，基于redis是单线程特征，防止出现数据库“爆破”
全局增量ID生成，类似“秒杀”

六：最新列表

例如新闻列表页面最新的新闻列表，如果总数量很大的情况下，尽量不要使用select a from A limit 10这种low货，尝试redis的 LPUSH命令构建List，一个个顺序都塞进去就可以啦。不过万一内存清掉了咋办？也简单，查询不到存储key的话，用mysql查询并且初始化一个List到redis中就好了。

七：排行榜

谁得分高谁排名往上。命令：ZADD（有续集，sorted set）

最近在研究股票，发现量化交易是个非常好的办法，通过臆想出来规律，用程序对历史数据进行验证，来判断这个臆想出来的规律是否有效，这玩意真牛！有没有哪位玩这个的给我留个言，交流一下呗。

什么场景不适合Redis？

数据量太大、数据访问频率非常低、修改特别频繁

数据结构

5种基础类型

String(字符串): string类型时二进制安全的，意思就是可以存储任何数据；

Hash（哈希）：类似于map ： java中的Map<String,Object>；

List（列表）：实际上是链表，可以添加任何一个元素在表头或者表位；

Set（集合）：无序无重复；

Zset（有序集合）：跟set一样也是string类型元素的集合。关联一个double分数；

String

redisTemplate.opsForValue().set();

redisTemplate.opsForValue().get();

Hash

    //Redis hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，hash 特别适合用于存储对象。 Redis 中每个 hash 可以存储 232 - 1 键值对
    private void hash() {
        Map userInfo = new HashMap<>();
        
        userInfo.put("name", "Lucy");
        userInfo.put("description", "a cool girl");
        
        
        //put ： (map的key, hashkey（name等），value
        redisTemplate.opsForHash().put("userInfo", "sex", "Female");
        
        //putAll：放入map对象
        redisTemplate.opsForHash().putAll("userInfo", userInfo);
        
        //values参数key对应的map值，返回结果为List<Object> ，keys方法也类似
        System.err.println(redisTemplate.opsForHash().values("userInfo").toString());
        
        //delete删除对应的字段
         redisTemplate.opsForHash().delete("userInfo", "name");
         
        //确定字段是否在map中存在，bool类型
         Boolean is_save = redisTemplate.opsForHash().hasKey("userInfo", "name");
         
         //multiGet,获取多个值
         Collection<Object> keys = new ArrayList<>();
            keys.add("name");
            keys.add("sex");
            System.out.println(redisTemplate.opsForHash().multiGet("userInfo", keys));
         
    }

List

List实现数据结构是双端链表。

    public void list() {        
        List userInfo = new ArrayList();
        
        redisTemplate.delete("userInfo");
        userInfo.add("Nancy");
        userInfo.add("a sunny girl");
        redisTemplate.opsForList().leftPush("userInfo", "first String before nancy");
        redisTemplate.opsForList().leftPush("userInfo", "second String before nancy");
        //左右插入l/rpush , all 是集合
        redisTemplate.opsForList().rightPushAll("userInfo", userInfo);
        
        System.err.println(redisTemplate.opsForList().leftPop("userInfo").toString());
        System.err.println(redisTemplate.opsForList().rightPop("userInfo").toString());
        System.err.println("在出栈后的userInfoList列表数据：" + redisTemplate.opsForList().range("userInfo", 0, -1));
    }

L / Rpush——链表头尾（左右插入元素） Lrange——模板中是range，返回区间值，0 到 -1是返回全集 L / Rpop——头尾（左右）出栈，会删除元素 Lindex——根据索引，取出元素 Llen——链表长度，元素个数 Lrem——根据key，删除n个value Ltrim——根据索引，删除指定元素 Rpoplpush——出栈，入栈 Lset——根据index，设置value Linsert before——根据value，在之前插入值 Linsert after——根据value，在之后插入值

Set

add remove pop //出并删除元素 move //将集合1中的指定元素移到集合2 isMember //是否存在元素 randomMember //随机取元素 members //遍历元素

Zset

Redis 有序集合和集合一样也是string类型元素的集合,且不允许重复的成员。

不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

有序集合的成员是唯一的,但分数(score)却可以重复。

1：zadd：添加元素，格式是zadd zset的key score值项的值，Score和项可以是多对，score可以是整数，

也可以是浮点数，还可以是+inf表示正无穷大，-inf表示负无穷大

2：zrange：获取索引区间内的元素

3：zrangebyscore：获取分数区间内的元素

4：zrem：删除元素，格式是zrem zset的key 项的值，项的值可以是多个

5：zcard：获取集合中元素个数，格式是zcard zset的key

6：zincrby：增减元素的Score，格式是zincrby zset的key 正负数字项的值

7：zcount：获取分数区间内元素个数，格式是zcount zset的key 起始score 终止score

8：zrank：获取项在zset中的索引，格式是zrank zset的key 项的值

9：zscore：获取元素的分数，格式是zscore zset的key 项的值，返回项在zset中的score

10：zrevrank：获取项在zset中倒序的索引，格式是zrevrank zset的key 项的值

11：zrevrange：获取索引区间内的元素，格式是zrevrange zset的key 起始索引终止索引(withscores)

插曲

使用完Hash后再在同一个字段插入List有报错：

org.springframework.data.redis.RedisSystemException: Error in execution; nested exception is io.lettuce.core.RedisCommandExecutionException:

WRONGTYPE Operation against a key holding the wrong kind of value

原因：可能是有同名Key写入不同类型值导致的问题。比如说：存进去是hash，去除操作用了list的操作。

解决方案：删除key重新写入：

redisTemplate.delete("userInfo");

3种特殊类型

Geospatal：地理位置，Geospatal底层是zset通过来实现的。

HyperLogLog：基数统计，就是不重复的元素的个数，网站用户数。

BitMaps：位图，只有0 和 1 两个状态，可以应用在统计用户每日打卡情况。

Geospatal

geoadd key longitude(经度) latitude(纬度) member(名称) [longitude latitude member ...]

将指定经纬度的地理位置及其名称添加到指定的zset集合中，支持一次添加多个，该命令的返回值为添加到zset有序集合的数目。如添加一个经纬度为116.413384 39.910925(表示潮州的经纬度，经纬度之间以空格分开)到key为cityzset集合中，如下

geopos key member [member ...]

根据key、member名称获取指定的经纬度，如获取上面我们保存的潮州的地理位置，支持一次获取多个。

geodist key member1 member2 [m|km|ft|mi]]

返回两个给定位置之间的距离，可以应用在求两个地理位置之间的距离。如果两个位置之间的其中一个不存在，那么命令返回空值。其中指定单位的参数 unit 必须是以下单位的其中一个（默认为m）：

m 表示单位为米。
km 表示单位为千米。
mi 表示单位为英里。
ft 表示单位为英尺。

示例：计算广州和北京之间的距离。

georadius key longitude(经度) latitude(纬度) radius [m|km|ft|mi]] [withcoord] [withdist]

通过该命令可以实现以给定的经纬度为中心，找出指定半径内的元素member，如可以应用在查找附近的人。

georadiusbymember key member radius [m|km|ft|mi]] [withcoord] [withdist]

找出指定元素周围的其他元素，与上一条命令不同的是，georadiusbymember是根据member和指定的查找距离radius来搜索，并将查找结果保存到另外的集合中。

zrem key member [member ...]

geo的底层是zset，因此可以用zrem key member来删除指定的member元素

 zrange key min max

查看指定key中对应的所有member元素

HyperLogLog

pfadd key element1 element2 [element...]

添加1个或n个element到指定key对应的集合中

pfmerge destkey sourcekey1 sourcekey2 [sourcekey....]

合并n个指定的元素的基数到指定的destkey元素的基数中（取并集）

pfcount key

统计指定key中对应的基数值（自动去重）

如下示例：

BitMaps

(1条消息) 一看就懂系列之详解redis的bitmap在亿级项目中的应用_咖啡色的羊驼-CSDN博客

setbit key offset value

设置offset和value必须为Integer类型，且value只能取 0 或 1

getbit key offset

bitcount key [start end]

统计指定范围内value取值为1的数量

bitop AND|OR|NOT|XOR destkey key [key...]

命令可以在不同的字符串之间执行按位运算，提供的位运算有逻辑并、逻辑或、逻辑异或，并将结果保存到destkey中。

bitpos key bit [start] [end]

查找指定范围内为0或1的第一位。

应用：统计员工一周出勤情况（0代表缺勤、1代表出勤）：

Stream

Redis Stream 是 Redis 5.0 版本新增加的数据结构。

Redis Stream 主要用于消息队列（MQ，Message Queue），Redis 本身是有一个 Redis 发布订阅 (pub/sub) 来实现消息队列的功能，但它有个缺点就是消息无法持久化，如果出现网络断开、Redis 宕机等，消息就会被丢弃。

简单来说发布订阅 (pub/sub) 可以分发消息，但无法记录历史消息。

而 Redis Stream 提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每一个客户端的访问位置，还能保证消息不丢失。

Redis Stream 的结构如下所示，它有一个消息链表，将所有加入的消息都串起来，每个消息都有一个唯一的 ID 和对应的内容：

每个 Stream 都有唯一的名称，它就是 Redis 的 key，在我们首次使用 xadd 指令追加消息时自动创建。

上图解析：

Consumer Group ：消费组，使用 XGROUP CREATE 命令创建，一个消费组有多个消费者(Consumer)。
last_delivered_id ：游标，每个消费组会有个游标 last_delivered_id，任意一个消费者读取了消息都会使游标 last_delivered_id 往前移动。
pending_ids ：消费者(Consumer)的状态变量，作用是维护消费者的未确认的 id。 pending_ids 记录了当前已经被客户端读取的消息，但是还没有 ack (Acknowledge character：确认字符）。

消息队列相关命令：

XADD - 添加消息到末尾
XTRIM - 对流进行修剪，限制长度
XDEL - 删除消息
XLEN - 获取流包含的元素数量，即消息长度
XRANGE - 获取消息列表，会自动过滤已经删除的消息
XREVRANGE - 反向获取消息列表，ID 从大到小
XREAD - 以阻塞或非阻塞方式获取消息列表

消费者组相关命令：

XGROUP CREATE - 创建消费者组
XREADGROUP GROUP - 读取消费者组中的消息
XACK - 将消息标记为"已处理"
XGROUP SETID - 为消费者组设置新的最后递送消息ID
XGROUP DELCONSUMER - 删除消费者
XGROUP DESTROY - 删除消费者组
XPENDING - 显示待处理消息的相关信息
XCLAIM - 转移消息的归属权
XINFO - 查看流和消费者组的相关信息；
XINFO GROUPS - 打印消费者组的信息；
XINFO STREAM - 打印流信息

对象机制

为什么Redis会设计redisObject对象？

LPUSH 和 LLEN 只能用于列表键, 而 SADD 和 SRANDMEMBER 只能用于集合键, 等等; 另外一些命令, 比如 DEL、 TTL 和 TYPE, 可以用于任何类型的键；

但是要正确实现这些命令, 必须为不同类型的键设置不同的处理方式: 比如说, 删除一个列表键和删除一个字符串键的操作过程就不太一样。

Redis 必须让每个键都带有类型信息, 使得程序可以检查键的类型, 并为它选择合适的处理方式.

集合类型就可以由字典和整数集合两种不同的数据结构实现，但是，当用户执行 ZADD 命令时，不必关心集合使用的是什么编码，将新元素添加到集合就可以了。

操作数据类型的命令除了要对键的类型进行检查之外, 还需要根据数据类型的不同编码进行多态处理。

为了解决以上问题, Redis 构建了自己的类型系统, 这个系统的主要功能包括:

redisObject 对象.

基于 redisObject 对象的类型检查.

基于 redisObject 对象的显式多态函数.

对 redisObject 进行分配、共享和销毁的机制.

redisObject

Redis 针对不同的数据结构定义统一的数据结构 redisObject 来进行管理。

换句话说，redisObject 是所有数据结构的最外层的一层结构定义。

redisObject 由五个属性组成

1、type

type 表示当前值对象的一个数据类型，在上一级视视频中，我们用来验证 bitmaps,typeloglogs ,geo底层的数据结构类型的时候使用的 type 命令。

Redis 5.x 支持六种数据类型：string,hash,set,list,zset,stream。

所以 type 的取值有六种。

type {key}的方式查看当前 kye-value 的数据类型

2、enconding

表示当前值对象底层存储的编码格式。

Redis 针对每种数据结构都设计有多种编码格式进行数据存储。比如说：单纯一个字符串的编码Redis 就提供了 int，embstr，raw 三种编码格式。

关于编码后面会谈到。而 encoding 就是用来表示当前数据存储采用的是那种编码格式。

encoding 相关属性值在源码中有定义，相关代码如下：

src/server.h 文件

object encoding key查看当前 kye-value 的数据类型

3、lru

lru 这个字段用来记录对象最后一次访问时间，当 Redis 配置了最大内存配置 maxmemory 后，再触发执行执行 lru 策略的时候，用来辅助 lru 策略删除数据用的。

4、refcount

refcount 记录了当前对象被引用的次数，当 refcount =0时，表示可以安全回收当前对象。

当配置有 maxmemory 时，存在共享对象池，[0-1000] 范围内的数值存在共享对象，这些共享对象被引用的次数越多相应的 refcount 越大。

refcount key查看当前 key-value 的引用次数

5、ptr

ptr 就是真实存储数据的指针。指向真实数据。

案例：set age 18

假设此时 Redis 中存在一个字符串，如上

此时该字符串对应的一个 redisObject 抽象图如下：

根据图片我们能够知道Redis中该字符串的讯息

首先 age 的数据结构类型为 string，

并且该字符串的编码为 int 。

lru 是这个对象最近一次被访问的时间

refcount 表示的当前对象被引用的次数

ptr 存储的是当前这个 age 对应的值，也就是 18

当执行一个处理数据类型命令的时候，redis执行以下步骤

根据给定的key，在数据库字典中查找和他相对应的redisObject，如果没找到，就返回NULL；
检查redisObject的type属性和执行命令所需的类型是否相符，如果不相符，返回类型错误；
根据redisObject的encoding属性所指定的编码，选择合适的操作函数来处理底层的数据结构；
返回数据结构的操作结果作为命令的返回值。

比如现在执行LPOP命令：

对象共享

redis一般会把一些常见的值放到一个共享对象中，这样可使程序避免了重复分配的麻烦，也节约了一些CPU时间。

redis预分配的值对象如下：

1.各种命令的返回值，比如成功时返回的OK，错误时返回的ERROR，命令入队事务时返回的QUEUE，等等

2.包括0 在内，小于REDIS_SHARED_INTEGERS的所有整数（REDIS_SHARED_INTEGERS的默认值是10000）

如果共享对象是保存整数值(0~9999)的字符串对象，那么验证操作的复杂度为O(1)
如果共享对象是保存字符串值的字符串对象，那么验证操作的复杂度为 O(N)
如果共享对象是包含了多个值(或者对象) 对象，比如列表对象或哈希对象，那么验证操作的复杂度为 O(N^2)

如果对复杂度较高的对象创建共享对象，需要消耗很大的CPU，用这种消耗去换取内存空间，是不合适的

对象淘汰

每个redisObject结构都带有一个refcount属性，指示这个对象被引用了多少次；
当新创建一个对象时，它的refcount属性被设置为1；
当对一个对象进行共享时，redis将这个对象的refcount加1；
当使用完一个对象后，或者消除对一个对象的引用之后，程序将对象的refcount减1；
当对象的refcount降至0 时，这个RedisObject结构，以及它引用的数据结构的内存都会被释放。

底层数据结构

简单动态字符串 - sds
压缩列表 - ZipList
快表 - QuickList
字典/哈希表 - Dict
整数集 - IntSet
跳表 - ZSkipList

简单动态字符串 - sds

这是一种用于存储二进制数据的一种结构, 具有动态扩容的特点。

SDS本质上就是char *，因为有了表头sdshdr结构的存在，所以SDS比传统C字符串在某些方面更加优秀，并且能够兼容传统C字符串。

sds是二进制安全的，它可以存储任意二进制数据，不像C语言字符串那样以‘\0’来标识字符串结束。

因为传统C字符串符合ASCII编码，这种编码的操作的特点就是：遇零则止 。即，当读一个字符串时，只要遇到’\0’结尾，就认为到达末尾，就忽略’\0’结尾以后的所有字符。因此，如果传统字符串保存图片，视频等二进制文件，操作文件时就被截断了。

SDS表头的buf被定义为字节数组，因为判断是否到达字符串结尾的依据则是表头的len成员，这意味着它可以存放任何二进制的数据和文本数据，包括’\0’。

SDS 和传统的 C 字符串获得的做法不同，传统的C字符串遍历字符串的长度，遇零则止，复杂度为O(n)。而SDS表头的len成员就保存着字符串长度，所以获得字符串长度的操作复杂度为O(1)。

总结下sds的特点是：可动态扩展内存、二进制安全、快速遍历字符串和与传统的C语言字符串类型兼容。

sds结构一共有五种Header定义，其目的是为了满足不同长度的字符串可以使用不同大小的Header，从而节省内存。 Header部分主要包含以下几个部分： + len：表示字符串真正的长度，不包含空终止字符 + alloc：表示字符串的最大容量，不包含Header和最后的空终止字符 + flags：表示header的类型。

// 五种header类型，flags取值为0~4
#define SDS_TYPE_5  0
#define SDS_TYPE_8  1
#define SDS_TYPE_16 2
#define SDS_TYPE_32 3
#define SDS_TYPE_64 4

在RedisObject中，SDS的两种存储形式

而Redis 的字符串共有两种存储方式，在长度特别短时，使用 emb 形式存储 (embedded)，当长度超过 44 时，使用 raw 形式存储。

存储格式

embstr 存储形式是这样一种存储形式，它将 RedisObject 对象头和 SDS 对象连续存在一起，使用 malloc 方法一次分配。而 raw 存储形式不一样，它需要两次 malloc，两个对象头在内存地址上一般是不连续的。

在字符串比较小时，SDS 对象头的大小是capacity+3——SDS结构体的内存大小至少是 3。意味着分配一个字符串的最小空间占用为 19 字节 (16+3)。

如果总体超出了 64 字节，Redis 认为它是一个大字符串，不再使用 emdstr 形式存储，而该用 raw 形式。而64-19-结尾的\0，所以empstr只能容纳44字节。

当字符串长度小于 1M 时，扩容都是加倍现有的空间，如果超过 1M，扩容时一次只会多扩 1M 的空间。(字符串最大长度为 512M)

SDS_MAX_PREALLOC的容量大小定义在sds.h文件中，默认是 1024 * 1024，也就是1MB。

通过上面的源代码可以看出，扩容策略是字符串在长度小于 SDS_MAX_PREALLOC 之前，扩容空间采用加倍策略，也就是保留 100% 的冗余空间。当长度超过 SDS_MAX_PREALLOC 之后，为了避免加倍后的冗余空间过大而导致浪费，每次扩容只会多分配 SDS_MAX_PREALLOC大小的冗余空间。

惰性空间释放用于优化SDS的字符串缩短操作。

当要缩短SDS保存的字符串时，程序并不立即使用内存充分配来回收缩短后多出来的字节，而是使用表头的free成员将这些字节记录起来，并等待将来使用。

压缩列表-ZipList

ziplist是list键、hash键以及zset键的底层实现之一（3.0之后list键已经不直接用ziplist和linkedlist作为底层实现了，取而代之的是quicklist）

这些键的常规底层实现如下：

list键：双向链表
hash键：字典dict
zset键：跳跃表zskiplist

但是当list键里包含的元素较少、并且每个元素要么是小整数要么是长度较小的字符串时，redis将会用ziplist作为list键的底层实现。同理hash和zset在这种场景下也会使用ziplist。

既然已有底层结构可以实现list、hash、zset键，为什么还要用ziplist呢？当然是为了节省内存空间，我们先来看看ziplist是如何压缩的。

ziplist是由*一系列特殊编码的连续内存块组成的顺序存储结构*，类似于数组，ziplist在内存中是连续存储的，但是不同于数组，为了节省内存 ziplist的每个元素所占的内存大小可以不同（数组中叫元素，ziplist叫节点entry，下文都用“节点”），每个节点可以用来存储一个整数或者一个字符串。

zlbytes: ziplist的长度（单位: 字节)，是一个32位无符号整数
zltail: ziplist最后一个节点的偏移量，反向遍历ziplist或者pop尾部节点的时候有用。
zllen: ziplist的节点（entry）个数
entry: 节点
zlend: 值为0xFF，用于标记ziplist的结尾

普通数组的遍历是根据数组里存储的数据类型找到下一个元素的，例如int类型的数组访问下一个元素时每次只需要移动一个sizeof(int)就行（实际上开发者只需让指针p+1就行，在这里引入sizeof(int)只是为了说明区别）。上文说了，ziplist的每个节点的长度是可以不一样的，而我们面对不同长度的节点又不可能直接sizeof(entry)，那么它是怎么访问下一个节点呢？ ziplist将一些必要的偏移量信息记录在了每一个节点里，使之能跳到上一个节点或下一个节点。

每个节点由三部分组成：prevlength、encoding、data

prevlengh: 记录上一个节点的长度，为了方便反向遍历ziplist
encoding: 当前节点的编码规则，下文会详细说
data: 当前节点的值，可以是数字或字符串

为了节省内存

根据上一个节点的长度prevlength 可以将ziplist节点分为两类：

entry的前8位小于254，则这8位就表示上一个节点的长度
entry的前8位等于254，则意味着上一个节点的长度无法用8位表示，后面32位才是真实的prevlength。用254 不用255(11111111)作为分界是因为255是zlend的值，它用于判断ziplist是否到达尾部。

根据当前节点存储的数据类型及长度，可以将ziplist节点分为9类：其中整数节点分为6类：

整数节点的encoding的长度为8位，其中高2位用来区分整数节点和字符串节点（高2位为11时是整数节点），低6位用来区分整数节点的类型，定义如下:

#define ZIP_INT_16B (0xc0 | 0<<4)//整数data,占16位（2字节）
#define ZIP_INT_32B (0xc0 | 1<<4)//整数data,占32位（4字节）
#define ZIP_INT_64B (0xc0 | 2<<4)//整数data,占64位（8字节）
#define ZIP_INT_24B (0xc0 | 3<<4)//整数data,占24位（3字节）
#define ZIP_INT_8B 0xfe //整数data,占8位（1字节）
/* 4 bit integer immediate encoding */
//整数值1~13的节点没有data，encoding的低四位用来表示data
#define ZIP_INT_IMM_MASK 0x0f
#define ZIP_INT_IMM_MIN 0xf1    /* 11110001 */
#define ZIP_INT_IMM_MAX 0xfd    /* 11111101 */

值得注意的是最后一种encoding是存储整数0~12的节点的encoding，它没有额外的data部分，encoding的高4位表示这个类型，低4位就是它的data。这种类型的节点的encoding大小介于ZIP_INT_24B与ZIP_INT_8B之间（1~13），但是为了表示整数0，取出低四位xxxx之后会将其-1作为实际的data值（0~12）。在函数zipLoadInteger中，我们可以看到这种类型节点的取值方法：

...
 } else if (encoding >= ZIP_INT_IMM_MIN && encoding <= ZIP_INT_IMM_MAX) {
        ret = (encoding & ZIP_INT_IMM_MASK)-1;
 }
...

字符串节点分为3类：

当data小于63字节时(2^6)，节点存为上图的第一种类型，高2位为00，低6位表示data的长度。
当data小于16383字节时(2^14)，节点存为上图的第二种类型，高2位为01，后续14位表示data的长度。
当data小于4294967296字节时(2^32)，节点存为上图的第二种类型，高2位为10，下一字节起连续32位表示data的长度。

快速列表-QuickList

何为quicklist，上次说到ziplist每次变更的时间复杂度都非常高，因为必须要重新生成一个新的ziplist来作为更新后的list，如果一个list非常大且更新频繁，那就会给redis带来非常大的负担。如何既保留ziplist的空间高效性，又能不让其更新复杂度过高？

其实说白了就是把ziplist和普通的双向链表结合起来。每个双链表节点中保存一个ziplist，然后每个ziplist中存一批list中的数据(具体ziplist大小可配置)，这样既可以避免大量链表指针带来的内存消耗，也可以避免ziplist更新导致的大量性能损耗，将大的ziplist化整为零。

quicklist结构在quicklist.c中的解释为一个由ziplist组成的双向链表。

压缩列表ziplist结构本身就是一个连续的内存块，由表头、若干个entry节点和压缩列表尾部标识符zlend组成，通过一系列编码规则，提高内存的利用率，使用于存储整数和短字符串。
压缩列表ziplist结构的缺点是：每次插入或删除一个元素时，都需要进行频繁的调用realloc()函数进行内存的扩展或减小，然后进行数据”搬移”，甚至可能引发连锁更新，造成严重效率的损失。

quicklist是由ziplist组成的双向链表，链表中的每一个节点都以压缩列表ziplist的结构保存着数据，而ziplist有多个entry节点，保存着数据。相当与一个quicklist节点保存的是一片数据，而不再是一个数据。

quicklist宏观上是一个双向链表，因此，它具有一个双向链表的有点，进行插入或删除操作时非常方便，虽然复杂度为O(n)，但是不需要内存的复制，提高了效率，而且访问两端元素复杂度为O(1)。
quicklist微观上是一片片entry节点，每一片entry节点内存连续且顺序存储，可以通过二分查找以 log2(n)log2(n) 的复杂度进行定位。

代码

/* 
 * quicklist
 */
typedef struct quicklist {
    //头结点
    quicklistNode *head; 
    //尾节点
    quicklistNode *tail; 
    //所有ziplist中entry数量
    unsigned long count; 
    //quicklistNodes节点数量
    unsigned int len;   
    //ziplist中entry能保存的数量,由list-max-ziplist-size配置项控制 
    int fill : 16;       
    //压缩深度,由list-compress-depth配置项控制
    unsigned int compress : 16; 
} quicklist;

注释

fill ：ziplist 中 entry 能保存的数量,由 list-max-ziplist-size 配置项控制

Copy    表示了单个节点(quicklistNode)的负载比例(fill factor)，负数限制 quicklistNode 中的 ziplist 的字节长度, 
    正数限制 quicklistNode 中的 ziplist 的最大长度。
Copy-5: 最大存储空间: 64 Kb <-- 通常情况下不要设置这个值
-4: 最大存储空间: 32 Kb <-- 非常不推荐
-3: 最大存储空间: 16 Kb <-- 不推荐
-2: 最大存储空间: 8 Kb <-- 推荐
-1: 最大存储空间: 4 Kb <-- 推荐
对于正整数则表示最多能存储到你设置的那个值, 当前的节点就装满了
通常在 -2 (8 Kb size) 或 -1 (4 Kb size) 时, 性能表现最好

compress ：压缩深度,由 list-compress-depth 配置项控制

Copy    表示 quicklist 中的节点 quicklistNode, 除开最两端的 compress 个节点之后, 中间的节点都会被压缩（LZF压缩算法）。

Copytypedef struct quicklistNode {
    //前节点指针
    struct quicklistNode *prev; 
    //后节点指针
    struct quicklistNode *next; 
    //数据指针。当前节点的数据没有压缩，那么它指向一个ziplist结构；否则，它指向一个quicklistLZF结构。
    unsigned char *zl;
    //zl指向的ziplist实际占用内存大小。需要注意的是：如果ziplist被压缩了，那么这个sz的值仍然是压缩前的ziplist大小
    unsigned int sz;  
    //ziplist里面包含的数据项个数
    unsigned int count : 16;   
    //ziplist是否压缩。取值：1--ziplist，2--quicklistLZF 
    unsigned int encoding : 2; 
    //存储类型，目前使用固定值2 表示使用ziplist存储
    unsigned int container : 2; 
    //当我们使用类似lindex这样的命令查看了某一项本来压缩的数据时，需要把数据暂时解压，这时就设置recompress=1做一个标记，等有机会再把数据重新压缩
    unsigned int recompress : 1;
    unsigned int attempted_compress : 1; /* node can't compress; too small */
    unsigned int extra : 10; /* more bits to steal for future usage */
} quicklistNode;

Copytypedef struct quicklistLZF {
    unsigned int sz;  //压缩后的ziplist大小
    char compressed[];//柔性数组，存放压缩后的ziplist字节数组
} quicklistLZF;

创建

/* 创建一个新的quicklist.
 * 使用quicklistRelease()释放quicklist. */
quicklist *quicklistCreate(void) {
    struct quicklist *quicklist;

    quicklist = zmalloc(sizeof(*quicklist));
    quicklist->head = quicklist->tail = NULL;
    quicklist->len = 0;
    quicklist->count = 0;
    quicklist->compress = 0;
    quicklist->fill = -2;
    quicklist->bookmark_count = 0;
    return quicklist;
}

create就没啥好说的了，但这里需要提醒下，fill值默认是-2，也就是说每个quicklistNode中的ziplist最长是8k字节，可以更具自己业务需求调整具体配置。

-1: 每个quicklistNode节点的ziplist所占字节数不能超过4kb。（建议配置） -2: 每个quicklistNode节点的ziplist所占字节数不能超过8kb。（默认配置&建议配置） -3: 每个quicklistNode节点的ziplist所占字节数不能超过16kb。 -4: 每个quicklistNode节点的ziplist所占字节数不能超过32kb。 -5: 每个quicklistNode节点的ziplist所占字节数不能超过64kb。任意正数: 表示：ziplist结构所最多包含的entry个数，最大为215215。

插入

头插和尾插都调用了quicklistNodeAllowInsert先判断了是否能直接在当前头|尾节点能插入，如果能就直接插入到对应的ziplist里，否则就需要新建一个新节点再操作了。还记得上文中我们说的fill字段吗，quicklistNodeAllowInsert其实就是根据fill的具体值来判断是否已经超过最大容量。

特定插入比较麻烦总结如下：

如果当前被插入节点不满，直接插入。如果当前被插入节点是满的，要插入的位置是当前节点的尾部，且后一个节点有空间，那就插到后一个节点的头部。如果当前被插入节点是满的，要插入的位置是当前节点的头部，且前一个节点有空间，那就插到前一个节点的尾部。如果当前被插入节点是满的，前后节点也都是满的，要插入的位置是当前节点的头部或者尾部，那就创建一个新的节点插进去。否则，当前节点是满的，且要插入的位置在当前节点的中间位置，我们需要把当前节点分裂成两个新节点，然后再插入。

删除

删除相对于插入而言简单多了，我先看的插入逻辑，插入中有节点的分裂，但删除里却没有节点的合并，quicklist有节点最大容量，但没有最小容量限制。

字典/哈希表 - Dict

(1条消息) 【Redis源码剖析】 - Redis内置数据结构之字典dict_上善若水，人淡如菊-CSDN博客

typedef struct dictht{
    //哈希表数组
    dictEntry **table;
    //哈希表大小
    unsigned long size;
    //哈希表大小掩码，用于计算索引值
    //总是等于 size-1
    unsigned long sizemask;
    //该哈希表已有节点的数量
    unsigned long used;
}dictht

哈希表是由数组 table 组成，table 中每个元素都是指向 dict.h/dictEntry 结构，dictEntry 结构定义如下：

typedef struct dictEntry{
     //键
     void *key;
     //值
     union{
          void *val;
          uint64_tu64;
          int64_ts64;
     }v;
 
     //指向下一个哈希表节点，形成链表
     struct dictEntry *next;
}dictEntry

著作权归Java 全栈知识体系所有。链接：Redis进阶 - 数据结构：底层数据结构详解 | Java 全栈知识体系

key 用来保存键，val 属性用来保存值，值可以是一个指针，也可以是uint64_t整数，也可以是int64_t整数。

注意这里还有一个指向下一个哈希表节点的指针，我们知道哈希表最大的问题是存在哈希冲突，如何解决哈希冲突，有开放地址法和链地址法。这里采用的便是链地址法，通过next这个指针可以将多个哈希值相同的键值对连接在一起，用来解决哈希冲突。

著作权归Java 全栈知识体系所有。链接：Redis进阶 - 数据结构：底层数据结构详解 | Java 全栈知识体系

哈希算法：Redis计算哈希值和索引值方法如下：

#1、使用字典设置的哈希函数，计算键 key 的哈希值
hash = dict->type->hashFunction(key);

#2、使用哈希表的sizemask属性和第一步得到的哈希值，计算索引值
index = hash & dict->ht[x].sizemask;

解决哈希冲突：这个问题上面我们介绍了，方法是链地址法。通过字典里面的 *next 指针指向下一个具有相同索引值的哈希表节点。
扩容和收缩：当哈希表保存的键值对太多或者太少时，就要通过 rerehash(重新散列）来对哈希表进行相应的扩展或者收缩。具体步骤：

1、如果执行扩展操作，会基于原哈希表创建一个大小等于 ht[0].used*2n 的哈希表（也就是每次扩展都是根据原哈希表已使用的空间扩大一倍创建另一个哈希表）。相反如果执行的是收缩操作，每次收缩是根据已使用空间缩小一倍创建一个新的哈希表。

2、重新利用上面的哈希算法，计算索引值，然后将键值对放到新的哈希表位置上。

3、所有键值对都迁徙完毕后，释放原哈希表的内存空间。

触发扩容的条件：

1、服务器目前没有执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且负载因子大于等于1。

2、服务器目前正在执行 BGSAVE 命令或者 BGREWRITEAOF 命令，并且负载因子大于等于5。

ps：负载因子 = 哈希表已保存节点数量 / 哈希表大小。

渐近式 rehash

什么叫渐进式 rehash？也就是说扩容和收缩操作不是一次性、集中式完成的，而是分多次、渐进式完成的。如果保存在Redis中的键值对只有几个几十个，那么 rehash 操作可以瞬间完成，但是如果键值对有几百万，几千万甚至几亿，那么要一次性的进行 rehash，势必会造成Redis一段时间内不能进行别的操作。所以Redis采用渐进式 rehash,这样在进行渐进式rehash期间，字典的删除查找更新等操作可能会在两个哈希表上进行，第一个哈希表没有找到，就会去第二个哈希表上进行查找。但是进行增加操作，一定是在新的哈希表上进行的。

整数集 - IntSet

整数集合（intset）是集合类型的底层实现之一，当一个集合只包含整数值元素，并且这个集合的元素数量不多时，Redis 就会使用整数集合作为集合键的底层实现。

Intset是集合键的底层实现之一，如果一个集合满足只保存整数元素和元素数量不多这两个条件，那么 Redis 就会采用 intset 来保存这个数据集。intset的数据结构如下：

typedef struct intset {
    uint32_t encoding; // 编码模式
    uint32_t length;  // 长度
    int8_t contents[];  // 数据部分
} intset;

其中，encoding 字段表示该整数集合的编码模式，Redis 提供三种模式的宏定义如下：

// 可以看出，虽然contents部分指明的类型是int8_t，但是数据并不以这个类型存放
// 数据以int16_t类型存放，每个占2个字节，能存放-32768~32767范围内的整数
#define INTSET_ENC_INT16 (sizeof(int16_t)) 
// 数据以int32_t类型存放，每个占4个字节，能存放-2^32-1~2^32范围内的整数
#define INTSET_ENC_INT32 (sizeof(int32_t)) 
// 数据以int64_t类型存放，每个占8个字节，能存放-2^64-1~2^64范围内的整数
#define INTSET_ENC_INT64 (sizeof(int64_t))

length 字段用来保存集合中元素的个数。

contents 字段用于保存整数，数组中的元素要求不含有重复的整数且按照从小到大的顺序排列。在读取和写入的时候，均按照指定的 encoding 编码模式读取和写入。

升级

inset中最值得一提的就是升级操作。当intset中添加的整数超过当前编码类型的时候，intset会自定升级到能容纳该整数类型的编码模式，如 1,2,3,4，创建该集合的时候，采用int16_t的类型存储，现在需要像集合中添加一个大整数，超出了当前集合能存放的最大范围，这个时候就需要对该整数集合进行升级操作，将encoding字段改成int32_6类型，并对contents字段内的数据进行重排列。

Redis提供intsetUpgradeAndAdd函数来对整数集合进行升级然后添加数据。其升级过程可以参考如下图示：

intset数据结构

typedef struct intset {
    uint32_t encoding; // 编码模式
    uint32_t length;  // 长度
    int8_t contents[];  // 数据部分
} intset;

其中，encoding 字段表示该整数集合的编码模式，Redis 提供三种模式的宏定义如下：

// 可以看出，虽然contents部分指明的类型是int8_t，但是数据并不以这个类型存放
// 数据以int16_t类型存放，每个占2个字节，能存放-32768~32767范围内的整数
#define INTSET_ENC_INT16 (sizeof(int16_t)) 
// 数据以int32_t类型存放，每个占4个字节，能存放-2^32-1~2^32范围内的整数
#define INTSET_ENC_INT32 (sizeof(int32_t)) 
// 数据以int64_t类型存放，每个占8个字节，能存放-2^64-1~2^64范围内的整数
#define INTSET_ENC_INT64 (sizeof(int64_t))

length 字段用来保存集合中元素的个数。

升级

Redis提供intsetUpgradeAndAdd函数来对整数集合进行升级然后添加数据。其升级过程可以参考如下图示：

跳表-ZSkipList

数据结构之Redis-跳表 - 简书 (jianshu.com)

将有序链表通过建立索引层的方式改造为可以支持折半查找算法，可以快速增删改查。

附带

String与Hash的选择

String 存JSON，取出后再转回对象。

如果存储的都是比较结构化的数据，比如用户数据缓存，或者经常需要操作数据的一个或者几个，特别是如果一个数据中如果filed比较多，但是每次只需要使用其中的一个或者少数的几个，使用hash是一个好的选择，因为它提供了hget 和 hmget，而无需取出所有数据再在代码中处理。

反之，如果数据差异较大，操作时常常需要把所有数据都读取出来再处理，使用string 是一个好的选择。

当然，也可以听Redis 的，放心的使用hash 吧。

还有一种场景：如果一个hash中有大量的field（成千上万个），需要考虑是不是使用string来分开存储是不是更好的选择。

核心知识

持久化

深入学习Redis（2）：持久化 - 编程迷思 - 博客园 (cnblogs.com)

Redis 运行时数据保存在内存中, 一旦重启则数据将全部丢失.

Redis 提供了两种持久化方式:

RDB 持久化: 生成某个时间点的快照文件
AOF 持久化(append only file): 日志追加模式(Redis协议格式保存)

Redis可以同时使用以上两种持久化

案例

传感器数据的持久化，我们的传感器数据有如下几个特点

数据量大，查询DB缓慢
数据固定，不会涉及更改
日期查询，每天数据量一致

为了保证查询速度，我们在前端固定了以天为单位的查询。

在Redis中保存了以"年-月-日-设备编号"为key，数据集List为value的List存储。

每天00:10分使用工作调动线程池开启对前一天数据的加载，放入Redis。

因为不需要考虑实时性深夜访问量小，同时也需要保证数据恢复速度，所以我们使用了RDB。

至于当天的数据，我们直接通过偏移量去数据库查询，然后丢到缓存，每天00:11分自动过期。

非当天的数据，如果缓存不存在，那么查询DB在丢到缓存手动BGSAVE。

RDB

所谓内存快照，顾名思义就是给内存拍个照，在某个时刻把内存中的数据记录下来，以文件的形式保存到硬盘上，这样即使宕机，数据依然存在。在服务器重启后只需要把“照片”中的数据恢复即可。

RDB持久化就是把当前进程的数据在某个时刻生成快照(一个压缩的二进制文件)保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

save

save命令会阻塞当前Redis服务器，直到RDB过程完成为止。在服务器进程阻塞期间，服务器不能处理任何命令请求。因此，当save命令正在执行时，客户端发送的所有命令都会被拒绝，知道save命令执行完毕。

Copyredis>save //等待，直到RDB文件创建完毕
ok

注意:

Redis的单线程模型就决定了，我们要尽量避免所有会阻塞主线程的操作，由于Save命令执行期间阻塞服务器进程，对于内存比较大的实例会造成长时间阻塞，因此线上环境不建议使用。

bgsave

bgsave命令会派生出一个子进程(而不是线程)，由子进程进行RDB文件创建，而父进程继续处理命令。

Copyredis>bgsave
Background saving started   //直接返回，由子进程进行RDB文件创建
redis>					  	//继续处理其它命令

Redis 持久化bgsave流程

注意:

在bgsave命令执行的时候，为了避免父进程与子进程同时执行两个rdbSave的调用而产生竞争条件，客户端发送的save命令会被服务器拒绝。
如果bgsave命令正在执行，bgrewriteaof（aof重写）命令会被延迟到bgsave命令之后执行，如果bgrewriteaof命令正在执行，那么客户端发送的bgsave命令会被服务器拒绝。
虽然bgsave命令是由子进程进行RDB文件的生成，但是fork()创建子进程的时候会阻塞父进程（详情请往下看）。

自动写入

因为bgsave命令可以在不阻塞服务器进程的情况下保存，所以redis可以通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次bgsave命令。如：我们向服务器设置如下配置(这也是redis默认的配置):

Copysave 900 1
save 300 10
save 60  10000

那么只要满足如下条件中的一个bgsave命令就会被执行：

服务器在900秒内对数据库进行了至少1次修改
服务器在300秒内对数据库进行了至少10次修改
服务器在60秒内对数据库进行了至少10000次修改

载入

在Redis启动的时候，只要检测到RDB文件的存在，就会自动加载RDB文件。需要注意的是

因为AOF文件的更新频率通常比RDB文件的更新频率高,所以口如果服务器开启了AOF持久化功能,那么服务器会优先使用AOF文件来还原数据库状态。
只有在AOF持久化功能处于关闭状态时,服务器才会使用RDB文件来还原数据库状态。

注意:服务器在载入RDB文件期间,会一直处于阻塞状态,直到载入工作完成为止

快照的时候修改数据

Redis写时复制

Redis 借助了操作系统提供的写时复制技术（Copy-On-Write, COW），可以让在执行快照的同时，正常处理写操作。简单来说，bgsave fork子进程的时候，并不会完全复制主进程的内存数据，而是只复制必要的虚拟数据结构，并不为其分配真实的物理空间，它与父进程共享同一个物理内存空间。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作，那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据，此时会给子进程分配一块物理内存空间，把要修改的数据复制一份，生成该数据的副本到子进程的物理内存空间。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

优缺点

优点：RDB是一个紧凑压缩的二进制文件，代表数据在某一个时间点的快照。非常适合备份，全景复制。比如每三个小时执行bgsave备份，并把RDB文件上传到备份服务器中，用于防止Redis服务器不可恢复性问题。 RDB恢复数据速度快于AOF的方式。缺点：RDB方式没有办法做到实时、秒级别的持久化。因为bgsave每次运行都要fork操作创建子线程，是一个重量级的操作，操作频繁成本比较高。 RDB文件是一个中特制的二进制文件，涉及到不同的Redis版本可能会发生老版本无法兼容新版本。

AOF

AOF是redis对将所有的写命令保存到一个aof文件中，根据这些写命令，实现数据的持久化和数据恢复。

写命令的保存格式就是上述的RESP协议。

RESP协议

Redis客户端与服务器交互采用序列化协议（RESP）,请求以字符串数组的形式来表示要执行命令的参数。用命令特有（command-specific）数据类型作为回复。

通信协议的特点 客户端和服务器通过 TCP 连接来进行数据交互，服务器默认的端口号为 6379 。客户端和服务器发送的命令或数据一律以 \r\n （CRLF）结尾。在这个协议中，所有发送至 Redis 服务器的参数都是二进制安全（binary safe）的。简单，高效，易读。

规范格式 1、间隔符号，在Linux下是\r\n，在Windows下是\n; 2、简单字符串 Simple Strings, 以 "+"加号开头; 3、错误 Errors, 以"-"减号开头; 4、整数型 Integer，以 ":" 冒号开头; 5、大字符串类型 Bulk Strings, 以 "$"美元符号开头，长度限制512M; 6、数组类型 Arrays，以 "*"星号开头。

配置

配置在redis.conf文件中，通过将appendonly:yes打开创建AOF文件功能。

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

含义： appendonly：是否打开 AOF 持久化功能 appendfilename：AOF 文件名称 appendfsync：同步频率

对于同步频率有三种方式

always：redis执行每个写命令时，都同步写入硬盘，这样会严重降低redis性能；
everysec：每秒执行一次，显示的在这一秒内执行的写命令同步到硬盘；
no：不同步到硬盘（让操作系统来决定何时进行同步）。

文件生成

生成过程包括三个步骤：命令追加、文件写入、文件同步。 redis打开AOF持久化功能之后，redis在执行完一个写命令后，把执行的命令首先追加到redis内部的aof_buf缓冲区膜末尾，此时缓冲区的记录还没有写到appendonly.aof文件中。然后，缓冲区的写命令会被写入到 AOF 文件，这一过程是文件写入过程。对于操作系统来说，调用write函数并不会立刻将数据写入到硬盘，为了将数据真正写入硬盘，还需要调用fsync函数，调用fsync函数即是文件同步的过程，只有经过了文件的同步过程，写命令才真正的被保存到了AOF文件中。appendfsync 就是配置同步的频率的选项。

压缩

redis不断的将写命令保存到AOF文件中，导致AOF文件越来越大，当AOF文件体积过大时，数据恢复的时间也是非常长的，因此，redis提供了重写或者说压缩AOF文件的功能。比如对key1初始值是0，调用incr命,100次，key1的值变为100，那么其实直接一句set key1 100 就可以顶之前的100局调用，AOF重写功能就是干这个事情的。重写时，可以调用BGREWRITEAOF命令重写AOF文件，与新建子线程bgsave命令的工作原理相似。也可以通过配置文件配置什么条件下对AOF文件重写。

auto-aof-rewrite-percentage 100 #当前AOF文件大小和上一次重写时AOF文件大小的比值
auto-aof-rewrite-min-size 64mb  #文件的最小体积

重写步骤: 1.创建子进程进行AOF重写 2.将客户端的写命令追加到AOF重写缓冲区 3.子进程完成AOF重写工作后，会向父进程发送一个信号 4.父进程接收到信号后，将AOF重写缓冲区的所有内容写入到新AOF文件中 5.对新的AOF文件进行改名，原子的覆盖现有的AOF文件

优缺点

优点： 1.提供了多种同步命令的方式，默认1秒同步一次写命令，最多丢失1秒内的数据； 2.如果AOF文件有错误，比如在写AOF文件时redis崩溃了，redis提供了多种恢复AOF文件的方式，例如使用redis-check-aof工具修正AOF文件（一般都是最后一条写命令有问题，可以手动取出最后一条写命令）； 3.AOF文件可读性交强，也可手动操作写命令。缺点： 1.AOF文件比RDB文件较大； 2.redis负载较高时，RDB文件比AOF文件具有更好的性能； 3.RDB使用快照的方式持久化整个redis数据，而aof只是追加写命令，因此从理论上来说，RDB比AOF方式更加健壮，另外，官方文档也指出，在某些情况下，AOF的确也存在一些bug，比如使用阻塞命令时，这些bug的场景RDB是不存在的。

混合模式

因为RDB持久化无法实时保存数据，数据库或者主机down机时，会丢失数据。AOF持久化虽然可以提高数据的安全性，但是在恢复数据时需要大量时间。因此Redis 4.0 推出RDB-AOF混合持久化。

持久化时，可以根据AOF的落盘策略实时刷盘。

恢复时先加载AOF文件中的RDB部分，然后再加载AOF文件部分。

4.0版本的混合持久化功能默认关闭，5.0 版本默认开启。

ppendonly yes

aof-use-rdb-preamble yes

流程

混合持久化开启，系统根据策略触发aof rewrite时，fork 一个子线程将内存数据以RDB二进制格式写入AOF文件头部，那些在重写操作执行之后执行的 Redis 命令，则以AOF持久化的方式追加到AOF文件的末尾。

触发机制

因为混合持久化是基于AOF重写的，所以和AOF rewrite的机制一致。

appendfsync：同步频率

对于同步频率有三种方式

always：redis执行每个写命令时，都同步写入硬盘，这样会严重降低redis性能；

everysec：每秒执行一次，显示的在这一秒内执行的写命令同步到硬盘；

no：不同步到硬盘（让操作系统来决定何时进行同步）。

混合持久化开启，同时配置RDB的save参数,Redis会生成rdb文件和AOF文件，而不是省略RDB文件。

格式

开启混合模式时，AOF文件的内容

未开启混合持久化，AOF文件的内容

其实就是AOF实时性高，但是效率低，将它的一部分用fork子进程来执行RDB操作并放到APF头部，这样AOF的效率会提高，恢复的时候先恢复RDB再恢复AOF。其实就是使用RDB对AOF来进行优化。

订阅发布

Redis可以执行发布/订阅模式(publish/subscribe), 该模式可以解耦消息的发送者和接收者,使程序具有更好的扩展性.从宏观上来讲,Redis的发布/订阅模式具有如下特点:

客户端执行订阅以后,除了可以继续订阅(SUBSCRIBE或者PSUBSCRIBE),取消订阅(UNSUBSCRIBE或者PUNSUBSCRIBE), PING命令和结束连接(QUIT)外, 不能执行其他操作,客户端将阻塞直到订阅通道上发布消息的到来.
发布的消息在Redis系统中不存储.因此,必须先执行订阅,再等待消息发布. 但是,相反的顺序则不支持. 订阅的通道名称支持glob模式匹配.如果客户端同时订阅了glob模式的通道和非glob模式的通道,并且名称存在交集,则对于一个发布的消息,该执行订阅的客户端接收到两个消息.

可以结合List做消息队列，不过最好用kafka、MQ等。

pub/sub API

Redis的发布/订阅设计模式相关的命令有六个:

SUBSCRIBE命令执行订阅.客户端可以多次执行该命令, 也可以一次订阅多个通道. 多个客户端可以订阅相同的通道.该命令的响应包括三部分, 依次是:命令名称(字符串subscribe),订阅的通道名称,总共订阅的通道数(包含glob通道).
PSUBSCRIBE命令执行glob模式订阅.客户端可以多次执行该命令, 也可以一次订阅多个glob通道. 多个客户端可以订阅相同的glob通道.该命令的响应包括三部分, 依次是:命令名称(字符串psubscribe),订阅的glob通道名称,总共订阅的通道数(包含非glob通道).
UNSUBSCRIBE命令取消订阅指定的通道.可以指定一个或者多个取消的订阅通道名称,也可以不带任何参数,此时将取消所有的订阅的通道(不包括glob通道).该命令的响应包括三部分, 依次是:命令名称(字符串unsubscribe),取消的订阅通道名称,总共订阅的通道数(包含glob通道).
PUNSUBSCRIBE命令取消订阅指定的glob模式通道.可以指定一个或者多个取消的glob模式的订阅通道名称,也可以不带任何参数,此时将取消所有的glob模式订阅的通道(不包括非glob通道).该命令的响应包括三部分, 依次是:命令名称(字符串punsubscribe),取消的glob模式的订阅通道名称,总共订阅的通道数(包含非glob通道).
PUBLISH命令在指定的通道上发布消息.只能在一个通道上发布消息,不能在多个通道上同时发布消息.该命令的响应包括通知的接收者个数,需要注意的是,这里的接收者数目大于等于订阅该通道的客户端数目(因为一个客户端的glob通道和非glob通道同时匹配发布通道的话,则视为两个接收者).而在接收端,收到的响应包括三部分,依次是 :message或者pmessage字符串(取决于是否为glob匹配),匹配的通道名称,发布的消息内容.
PUBSUB命令执行状态查询.支持若干子命令.需要注意的是,该命令不能在客户端进入订阅后执行.

案例

例子:

subscribe foo bar
*3
$9
subscribe
$3
foo
:1
*3
$9
subscribe
$3
bar
:2

同时订阅了两个非glob通道,返回的响应中最后给出的订阅的通道总数为2. 接着继续执:

psubscribe b?r *news
*3
$10
psubscribe
$3
b?r
:3
*3
$10
psubscribe
$5
*news
:4

同时订阅了两个glob通道,这时总共订阅的通道数增加到4个(包括之前订阅的2个非glob通道). 接着,在其他客户端上执行:

publish foo "Hello foo"
:1

说明有一个接收者在该通道上接受了消息. 接收客户端(订阅客户端)的响应为:

*3
$7
message
$3
foo
$9
Hello foo

从响应中,可以看出是在非glob通道上(foo通道)上接受的消息. 发布客户端继续执行:

publish bar "Hi bar"
:2

有两个接收者在该发布通道上接收了消息. 这是因为,订阅客户端的glob通道和非glob通道同时匹配这个通道名称,视为两个接收者. 订阅客户端上的响应为:

*3
$7
message
$3
bar
$6
Hi bar
*4
$8
pmessage
$3
b?r
$3
bar
$6
Hi bar

从响应中看到,message和pmessage类型的通道都收到了消息. 在订阅客户端上,继续执行:

unsubscribe foo
*3
$11
unsubscribe
$3
foo
:3

取消了一个非glob通道的订阅,订阅总数更新为3个. 在订阅客户端上,继续执行:

punsubscribe

*3
$12
punsubscribe
$3
b?r
:2
*3
$12
punsubscribe
$5
*news
:1

取消了所有glob通道的订阅,订阅总数更新为1个. 在发布客户端上,继续执行:

pubsub channels
*1
$3
bar

从响应中,可看到Redis系统中只存在一个订阅通道了. 在发布客户端上,继续执行:

select 1
+OK

每个客户端连接到Redis系统时,默认使用的是0号数据库.该命令将发布客户端连接到Redis系统的1号数据库上. 在发布客户端上,继续执行:

publish bar "howdy bar"
:1

说明有一个接收者在该通道上接收到了消息. 订阅客户端上的情况:

*3
$7
message
$3
bar
$9
howdy bar

订阅客户端接收到了消息.

小结:

只有在订阅客户端上,才能取消订阅. 一个客户端连接不能为另一个客户端连接取消订阅. 这是显而易见的. 在发布/订阅模式下,通道名称是全局的,和客户端连接的Redis数据库没有关系.

源码

SUBSCRIBE命令执行函数subscribeCommand, 其实现为(pubsub.c):

void subscribeCommand(redisClient *c) {
    int j;
    for (j = 1; j < c->argc; j++)
        pubsubSubscribeChannel(c,c->argv[j]);
    c->flags |= REDIS_PUBSUB;
}

该命令设置客户端对象标志REDIS_PUBSUB,表示进入了订阅模式. 函数pubsubSubscribeChannel的实现为(pubsub.c):

/* Subscribe a client to a channel. Returns 1 if the operation succeeded, or
 * 0 if the client was already subscribed to that channel. */
int pubsubSubscribeChannel(redisClient *c, robj *channel) {
    struct dictEntry *de;
    list *clients = NULL;
    int retval = 0;

    /* Add the channel to the client -> channels hash table */
    if (dictAdd(c->pubsub_channels,channel,NULL) == DICT_OK) {
        retval = 1;
        incrRefCount(channel);
        /* Add the client to the channel -> list of clients hash table */
        de = dictFind(server.pubsub_channels,channel);
        if (de == NULL) {
            clients = listCreate();
            dictAdd(server.pubsub_channels,channel,clients);
            incrRefCount(channel);
        } else {
            clients = dictGetVal(de);
        }
        listAddNodeTail(clients,c);
    }
    /* Notify the client */
    addReply(c,shared.mbulkhdr[3]);
    addReply(c,shared.subscribebulk);
    addReplyBulk(c,channel);
    addReplyLongLong(c,clientSubscriptionsCount(c));
    return retval;
}

需要说明的是,通道名称既在客户端对象的哈希表pubsub_channels中保存,也在全局变量server的哈希表pubsub_channels中保存.保存在这两个数据结构的一个原因是, 通过在客户端对象的哈希表中可以快速判断该通道是否添加过. 通道名称并没有保存在连接的数据库中,而是直接保存在了全局的server结构中,因此客户端改变连接的数据库时, 对发布/订阅没有任何影响.在全局哈希表pubsub_channels中保存的是通道名称和订阅该通道的客户端链表.

PSUBSCRIBE

和非glob通道名称一样, glob通道名称也是既保存在客户端对象中也保存在全局变量server中. 并且均使用不同的字段,而且字段数据结构都是使用的链表.为什么不和非glob通道一样用哈希表来保存, 个人认为,glob模式的名字在系统中可能数量较少,而且名字长度可能要短一些,所以,使用链表处理就可以了. 这里需要注意的一点是,对于glob通道名字,必须保存其原始编码格式(REDIS_ENCODING_RAW), 因为后续在处理PUBLISH命令的时候,涉及到glob字符匹配.

命令PUBLISH执行函数publishCommand, 其实现为(pubsub.c):

void publishCommand(redisClient *c) {
    int receivers = pubsubPublishMessage(c->argv[1],c->argv[2]);
    forceCommandPropagation(c,REDIS_PROPAGATE_REPL);
    addReplyLongLong(c,receivers);
}

消息发布会replica节点同步. 函数pubsubPublishMessage的实现为(pubsub.c):

/* Publish a message */
int pubsubPublishMessage(robj *channel, robj *message) {
    int receivers = 0;
    struct dictEntry *de;
    listNode *ln;
    listIter li;

    /* Send to clients listening for that channel */
    de = dictFind(server.pubsub_channels,channel);
    if (de) {
        list *list = dictGetVal(de);
        listNode *ln;
        listIter li;

        listRewind(list,&li);
        while ((ln = listNext(&li)) != NULL) {
            redisClient *c = ln->value;

            addReply(c,shared.mbulkhdr[3]);
            addReply(c,shared.messagebulk);
            addReplyBulk(c,channel);
            addReplyBulk(c,message);
            receivers++;
        }
    }
    /* Send to clients listening to matching channels */
    if (listLength(server.pubsub_patterns)) {
        listRewind(server.pubsub_patterns,&li);
        channel = getDecodedObject(channel);
        while ((ln = listNext(&li)) != NULL) {
            pubsubPattern *pat = ln->value;

            if (stringmatchlen((char*)pat->pattern->ptr,
                                sdslen(pat->pattern->ptr),
                                (char*)channel->ptr,
                                sdslen(channel->ptr),0)) {
                addReply(pat->client,shared.mbulkhdr[4]);
                addReply(pat->client,shared.pmessagebulk);
                addReplyBulk(pat->client,pat->pattern);
                addReplyBulk(pat->client,channel);
                addReplyBulk(pat->client,message);
                receivers++;
            }
        }
        decrRefCount(channel);
    }
    return receivers;
}

LINE8:25在全局的哈希表pubsub_channels中查找订阅该通道的客户端,并把发布的消息写入订阅客户端的发送缓存中. LINE26:46遍历全局glob通道名称链表pubsub_patterns, 对每个订阅的glob通道,模式匹配发布命令的通道,如果匹配成功, 向该订阅客户端发送缓存写入发布消息.

命令UNSUBSCRIBE执行函数unsubscribeCommand, 其实现为(pubsub.c):

void unsubscribeCommand(redisClient *c) {
    if (c->argc == 1) {
        pubsubUnsubscribeAllChannels(c,1);
    } else {
        int j;

        for (j = 1; j < c->argc; j++)
            pubsubUnsubscribeChannel(c,c->argv[j],1);
    }
    if (clientSubscriptionsCount(c) == 0) c->flags &= ~REDIS_PUBSUB;
}

如果当前客户端所有订阅的通道均被取消,则取消标识REDIS_PUBSUB,退出订阅模式. 函数pubsubUnsubscribeAllChannels的实现会调用pubsubUnsubscribeChannel逐个取消订阅的通道, 其实现为(pubsub.c):

/* Unsubscribe a client from a channel. Returns 1 if the operation succeeded, or
 * 0 if the client was not subscribed to the specified channel. */
int pubsubUnsubscribeChannel(redisClient *c, robj *channel, int notify) {
    struct dictEntry *de;
    list *clients;
    listNode *ln;
    int retval = 0;
    /* Remove the channel from the client -> channels hash table */
    incrRefCount(channel); /* channel may be just a pointer to the same object
                            we have in the hash tables. Protect it... */
    if (dictDelete(c->pubsub_channels,channel) == DICT_OK) {
        retval = 1;
        /* Remove the client from the channel -> clients list hash table */
        de = dictFind(server.pubsub_channels,channel);
        redisAssertWithInfo(c,NULL,de != NULL);
        clients = dictGetVal(de);
        ln = listSearchKey(clients,c);
        redisAssertWithInfo(c,NULL,ln != NULL);
        listDelNode(clients,ln);
        if (listLength(clients) == 0) {
            /* Free the list and associated hash entry at all if this was
             * the latest client, so that it will be possible to abuse
             * Redis PUBSUB creating millions of channels. */
            dictDelete(server.pubsub_channels,channel);
        }
    }
    /* Notify the client */
    if (notify) {
        addReply(c,shared.mbulkhdr[3]);
        addReply(c,shared.unsubscribebulk);
        addReplyBulk(c,channel);
        addReplyLongLong(c,dictSize(c->pubsub_channels)+
                       listLength(c->pubsub_patterns));
    }
    decrRefCount(channel); /* it is finally safe to release it */
    return retval;
}

即分别在客户端对象的哈希表pubsub_channels和全局变量server的哈希表pubsub_channels取消该通道.

命令PUNSUBSCRIBE和命令UNSUBSCRIBE的实现基本类似,这里不再分析.

事件

彻底搞懂Redis的线程模型 - 掘金 (juejin.cn)

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

文件事件(file event)：Redis服务器通过套接字与客户端(或其他Redis服务器)进行连接，而文件事件就是服务器对套接字操作的抽象。服务器与客户端(或其他服务器)的通信会产生相应的文件事件，而服务器则通过监听并处理这些事件来完成一系列网络通信操作；
时间事件(time event)：Redis服务器的一些操作(比如serverCron函数)需要在给定的时间执行，而时间事件就是服务器对这类定时操作的抽象；

文件事件

文件事件处理器

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

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

文件事件处理器由四个组成部分

套接字（socket）：就是对网络中不同主机上的应用进程之间进行双向通信的端点的抽象，一个套接字就是网络上进程通信的一端，提供了应用层进程利用网络协议交换数据的机制。

套接字、I/O多路复用程序、文件事件调度器，以及事件处理器；

文件事件是对套接字操作的抽象，每当一个套接字准备好执行连接应答、写入、读取、关闭等操作时，就会产生一个文件事件。因为一个服务器通常会连接多个套接字，所以多个文件事件有可能会并发地出现。
I/O多路复用程序负责监听多个套接字，并向文件时间调度器传送那些产生了事件的套接字。尽管多个文件事件可能会并发地出现，但I/O多路复用程序总是会将所有产生事件的套接字都放到一个队列里面，然后通过这个队列以有序、同步、每次一个套接字的方式向文件事件调度器传送套接字。如下如所示：
文件事件调度器接收I/O多路复用程序传来的套接字，并根据套接字产生的事件类型，调用相应的时间处理器；
事件处理器是一个个函数，它们定义了某个事件发生时，服务器该执行的动作。

I/O多路复用程序 Redis的I/O多路复用程序的所有功能都是通过包装常见的select、epoll、evport和kqueue这些I/O多路复用函数来实现的，每个I/O多路复用函数库在Redis源码中都对应一个单独的文件，比如ae_select.c、ae_epoll.c、ae_kqueue.c诸如此类。因为Redis为每个I/O多路复用函数库都实现了相同的API，所以I/O多路复用程序的底层实现是可以互换，如下如所示：

彻底搞懂epoll高效运行的原理 (qq.com)

Redis在I/O多路复用程序的实现源码中用#include宏定义了相应的规则，程序会在编译时自动选择系统中性能最高的I/O多路复用函数库来作为Redis的I/O多路复用程序的底层实现：

# ifdef HAVE_EVPORT
# include "ae_evport.c"
# else
    # ifdef HAVE_EPOLL
    # include "ae_epoll.c"
    # else
        # ifdef HAVE_KQUEUE
        # include "ae_kqueue.c"
        # else
        # include "ae_select.c"
        # endif
    # endif
# endif

事件类型

I/O多路复用程序可以监听多个套接字的ae.h/AE_READABLE事件和ae.h/AE_WRITABLE事件，这两类事件和套接字操作之间的对应关系如下：

当套接字变得可读时(客户端对套接字执行write操作或执行close操作)，或者有新的可应答(acceptable)套接字出现时(客户端对服务器的监听套接字执行connect操作)，套接字产生AE_READABLE事件；
当套接字变得可写时(客户端对套接字执行read操作)，套接字产生AE_WRITABLE事件；

I/O多路服用程序允许服务器同时监听套接字的AE_READABLE事件和AE_WRITABLE事件，如果一个套接字同时产生了这两种事件，那么文件事件调度器会优先处理AE_READABLE事件，等到AE_READABLE事件处理完成之后，才处理AE_WRITABLE事件。

ae.c/aeCreateFileEvent函数接受一个套接字描述符、一个事件类型，以及一个事件处理函数作为参数，将给定套接字的给定事件键入到I/O多路复用程序的监听范围，并对事件和时间处理器进行关联；
ae.c/aeDeleteFileEvent函数接受一个套接字描述符和一个监听事件类型作为参数，让I/O多路复用程序程序取消对给定套接字的给定事件的监听，并取消事件和事件处理之间的关联；
ae.c/aeGetFileEvents函数接受一个套接字描述符，返回该套接字正在被监听的事件类型：如果套接字没有任何事件被监听，那么函数返回AE_NONE；如果套接字的读事件正在被监听，那么函数返回AE_READABLE；如果套接字的写事件正在被监听，那么函数返回AE_WRITABLE；如果套接字的读事件和写事件正在被监听，那么函数返回AE_READABLE|AE_WRITABLE；
ae.c/aeWait函数接受一个套接字描述符、一个事件类型和一个毫秒数为参数，在给定的时间内阻塞并等待套接字的给定类型事件产生，当事件成功产生，或者等待超时后，函数返回；
ae.c/aeApiPoll函数接受一个sys/time.h/struct timeval结构为参数，并在指定时间内，阻塞并等待所有被aeCreateFileEvent函数设置为监听状态的套接字产生文件事件，当有至少一个事件产生，或者等待超时后，函数返回；
ae.c/aeProcessEvent函数是文件事件调度器，它先调用aeApiPoll函数来等待事件产生，然后遍历所有已产生的事件，并调度相应的时间处理器来处理这些事件；
ae.c/aeGetApiName函数返回I/O多路复用程序底层所使用的I/O多路复用函数库的名称：返回"select"表示底层为select函数库，诸如此类；

文件事件的处理器

Redis为文件事件编写了多个处理器，这些事件处理器分别用于实现不同的网络通讯需求，常用的处理器如下：

为了对连接服务器的各个客户端进行应答，服务器要为监听套接字关联连接应答处理器。
为了接收客户端传来的命令请求，服务器要为客户端套接字关联命令请求处理器。
为了向客户端返回命令的执行结果，服务器要为客户端套接字关联命令回复处理器。

连接应答处理器

networking.c中acceptTcpHandler函数是Redis的连接应答处理器，这个处理器用于对连接服务器监听套接字的客户端进行应答，具体实现为sys/socket.h/accept函数的包装。

当Redis服务器进行初始化的时候，程序会将这个连接应答处理器和服务器监听套接字的AE_READABLE事件关联起来，当有客户端用sys/socket.h/connect函数连接服务器监听套接字的时候，套接字就会产生AE_READABLE 事件，引发连接应答处理器执行，并执行相应的套接字应答操作，如图所示。

命令请求处理器

networking.c中readQueryFromClient函数是Redis的命令请求处理器，这个处理器负责从套接字中读入客户端发送的命令请求内容，具体实现为unistd.h/read函数的包装。

当一个客户端通过连接应答处理器成功连接到服务器之后，服务器会将客户端套接字的AE_READABLE事件和命令请求处理器关联起来，当客户端向服务器发送命令请求的时候，套接字就会产生 AE_READABLE事件，引发命令请求处理器执行，并执行相应的套接字读入操作，如图所示。

在客户端连接服务器的整个过程中，服务器都会一直为客户端套接字的AE_READABLE事件关联命令请求处理器。

命令回复处理器

networking.c中sendReplyToClient函数是Redis的命令回复处理器，这个处理器负责将服务器执行命令后得到的命令回复通过套接字返回给客户端，具体实现为unistd.h/write函数的包装。

当服务器有命令回复需要传送给客户端的时候，服务器会将客户端套接字的AE_WRITABLE事件和命令回复处理器关联起来，当客户端准备好接收服务器传回的命令回复时，就会产生AE_WRITABLE事件，引发命令回复处理器执行，并执行相应的套接字写入操作，如图所示。

当命令回复发送完毕之后，服务器就会解除命令回复处理器与客户端套接字的 AE_WRITABLE 事件之间的关联。

时间事件

时间事件分为以下两类：

定时事件：让一段程序在指定的时间之后执行一次，比如，让程序A在当前时间30秒后执行一次；
周期性事件：让一段程序每隔指定时间就执行一次，比如，让程序B每隔30秒就执行一次；

时间事件主要有以下三个属性构成：

id：服务器为时间事件创建的全局唯一ID(标识)，ID按从小到大的顺序递增，新事件的ID号比旧事件的ID号要大；
when：毫秒精度的UNIX时间戳，记录了时间事件的到达(arrive)时间；
timeProc：时间事件处理器，一个函数。当时间事件到达时，服务器就会调用相应的处理器来处理事件；

一个时间事件是定时事件还是周期性事件取决于时间处理器的返回值：

如果事件处理器返回ae.h/AE_NOMORE，那么这个事件为定时事件，该事件在达到一次之后就会被删除，之后不会再到达；
如果事件处理器返回一个非AE_NOMORE整数值，那么这个事件为周期性事件：当一个时间事件达到之后，服务器会根据事件处理器返回的值，对时间事件的when属性进行更新，让这个事件在一段时间之后再次到达，并以这种方式一直更新并运行下去。比如，如果一个时间事件的处理器返回整数值10，那么服务器应该对这个时间事件进行更新，让这个事件在10毫秒之后再次到达(现在Redis主要使用这个)；

ae.c/aeCreateTimeEvent函数接受一个毫秒数milliseconds和一个时间事件处理器proc作为参数，将一个新的时间事件添加到服务器，这个新的时间事件将在当前时间的milliseconds毫秒之后达到，而事件的处理器为proc；
ae.c/aeDeleteFileEvent函数接受一个时间事件ID作为参数，然后从服务器中删除该ID所对应的时间事件；
ae.c/aeSearchNearestTimer函数返回到达事件距离当前时间最接近的那个时间事件；
ae.c/processTimeEvents函数是时间事件的执行器，这个函数会遍历所有已到达的时间事件，并调用这些事件的处理器。已到达指的是，时间事件的when属性记录的UNIX时间戳等于或小于当前时间的UNIX时间戳。

processTimeEvents函数的定义可以用下面的伪代码来描述：

def processTimeEvents():
    # 遍历服务器中的所有时间事件
    for time_event in all_time_event():
        # 检查事件是否已经到达
        if time_event.when <= unix_ts_now():
            # 事件已到达
            # 执行事件处理器，并获取返回值
            retval = time_event.timeProc()
            # 如果这是一个定时事件
            if retval == AE_NOMORE:
                # 那么将该事件从服务器中删除
                delete_time_event_from_server(time_event)
        # 如果这是一个周期性事件
        else:
            # 那么按照事件处理器的返回值更新时间事件的 when 属性
            # 让这个事件在指定的时间之后再次到达
            update_when(time_event, retval)

时间事件应用实例：serverCron函数

持续运行的Redis服务器需要定期对自身的资源和状态进行检查和调整，从而确保服务器可长期、稳定地运行，这些定期操作由redis.c/serverCron函数负责执行，它的主要工作包括：

更新服务器的各类统计信息，比如时间、内存扎用、数据库使用情况等；
清理数据中的过期键值对；
关闭和清理连接失效的客户端；
尝试进行AOF或RDB持久化操作；
如果服务器是主服务器，那么对从服务器进行定期同步；
如果处于集群模式，对集群进行定期同步和连接测试；

事件的调度与执行

事件的调度和执行由ae.c/aeProcessEvents函数负责，可以用以下源代码完成：

def aeProcessEvents():
    # 获取到达时间离当前时间最接近的时间事件
    time_event = aeSearchNearestTimer()
    # 计算最接近的时间事件距离到达还有多少毫秒
    remaind_ms = time_event.when - unix_ts_now()
    # 如果事件已到达，那么remaind_ms的值可能为负数，将它设定为0
    if remaind_ms < 0:
        remaind_ms = 0
    # 根据remaind_ms的值，创建timeval结构
    timeval = create_timeval_with_ms(remaind_ms)
    # 阻塞并等待文件事件产生，最大阻塞时间由传入的timeval结构决定
    # 如果remaind_ms的值为0，那么aeApiPoll调用之后马上返回，不阻塞
    aeApiPoll(timeval)
    # 处理所有已产生的文件事件（其实并没有这个函数）
    processFileEvents()
    # 处理所有已到达的时间事件
    processTimeEvents()

事务

概念

Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。

总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。　

没有隔离级别

批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。

不保证原子性

Redis中，运维使用lua脚本，单条命令是原子性执行的，但为了保证性能，事务（多条命令）不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

事务的三个阶段

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

案例

（1）正常执行

（2）放弃事务

（3）若在事务队列中存在命令性错误（类似于java编译性错误），则执行EXEC命令时，所有命令都不会执行

（4）若在事务队列中存在语法性错误（类似于java的1/0的运行时异常），则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。

（5）使用watch

案例一：使用watch检测balance，事务期间balance数据未变动，事务执行成功

案例二：使用watch检测balance，在开启事务后（标注1处），在新窗口执行标注2中的操作，更改balance的值，模拟其他客户端在事务执行期间更改watch监控的数据，然后再执行标注1后命令，执行EXEC后，事务未成功执行。

一但执行 EXEC 开启事务的执行后，无论事务使用执行成功， WARCH 对变量的监控都将被取消。

故当事务执行失败后，需重新执行WATCH命令对变量进行监控，并开启新的事务进行操作。

总结

watch指令类似于乐观锁，在事务提交时，如果watch监控的多个KEY中任何KEY的值已经被其他客户端更改，则使用EXEC执行事务时，事务队列将不会被执行，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

高可用

主从复制

深入学习Redis（3）：主从复制 - 编程迷思 - 博客园 (cnblogs.com)

概述

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的作用主要包括：

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

使用

1.建立复制

需要注意，主从复制的开启，完全是在从节点发起的；不需要我们在主节点做任何事情。

从节点开启主从复制，有3种方式：

（1）配置文件

在从服务器的配置文件中加入：slaveof <masterip> <masterport>

（2）启动命令

redis-server启动命令后加入 --slaveof <masterip> <masterport>

（3）客户端命令

Redis服务器启动后，直接通过客户端执行命令：slaveof <masterip> <masterport>，则该Redis实例成为从节点。

上述3种方式是等效的，下面以客户端命令的方式为例，看一下当执行了slaveof后，Redis主节点和从节点的变化。

实例

准备工作：启动两个节点

方便起见，实验所使用的主从节点是在一台机器上的不同Redis实例，其中主节点监听6379端口，从节点监听6380端口；从节点监听的端口号可以在配置文件中修改：

启动后可以看到：

两个Redis节点启动后（分别称为6379节点和6380节点），默认都是主节点。

建立复制

此时在6380节点执行slaveof命令，使之变为从节点：

观察效果

下面验证一下，在主从复制建立后，主节点的数据会复制到从节点中。

（1）首先在从节点查询一个不存在的key：

（2）然后在主节点中增加这个key：

（3）此时在从节点中再次查询这个key，会发现主节点的操作已经同步至从节点：

（4）然后在主节点删除这个key：

（5）此时在从节点中再次查询这个key，会发现主节点的操作已经同步至从节点：

断开

通过slaveof <masterip> <masterport>命令建立主从复制关系以后，可以通过slaveof no one断开。需要注意的是，从节点断开复制后，不会删除已有的数据，只是不再接受主节点新的数据变化。

从节点执行slaveof no one后，打印日志如下所示；可以看出断开复制后，从节点又变回为主节点。

主节点打印日志如下：

实现原理

主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段；

连接建立阶段

该阶段的主要作用是在主从节点之间建立连接，为数据同步做好准备。

步骤1：保存主节点信息

从节点服务器内部维护了两个字段，即masterhost和masterport字段，用于存储主节点的ip和port信息。

需要注意的是，slaveof是异步命令，从节点完成主节点ip和port的保存后，向发送slaveof命令的客户端直接返回OK，实际的复制操作在这之后才开始进行。

这个过程中，可以看到从节点打印日志如下：

步骤2：建立socket连接

从节点每秒1次调用复制定时函数replicationCron()，如果发现了有主节点可以连接，便会根据主节点的ip和port，创建socket连接。如果连接成功，则：

从节点：为该socket建立一个专门处理复制工作的文件事件处理器，负责后续的复制工作，如接收RDB文件、接收命令传播等。

主节点：接收到从节点的socket连接后（即accept之后），为该socket创建相应的客户端状态，并将从节点看做是连接到主节点的一个客户端，后面的步骤会以从节点向主节点发送命令请求的形式来进行。

这个过程中，从节点打印日志如下：

步骤3：发送ping命令

从节点成为主节点的客户端之后，发送ping命令进行首次请求，目的是：检查socket连接是否可用，以及主节点当前是否能够处理请求。

从节点发送ping命令后，可能出现3种情况：

（1）返回pong：说明socket连接正常，且主节点当前可以处理请求，复制过程继续。

（2）超时：一定时间后从节点仍未收到主节点的回复，说明socket连接不可用，则从节点断开socket连接，并重连。

（3）返回pong以外的结果：如果主节点返回其他结果，如正在处理超时运行的脚本，说明主节点当前无法处理命令，则从节点断开socket连接，并重连。

在主节点返回pong情况下，从节点打印日志如下：

步骤4：身份验证

如果从节点中设置了masterauth选项，则从节点需要向主节点进行身份验证；没有设置该选项，则不需要验证。从节点进行身份验证是通过向主节点发送auth命令进行的，auth命令的参数即为配置文件中的masterauth的值。

如果主节点设置密码的状态，与从节点masterauth的状态一致（一致是指都存在，且密码相同，或者都不存在），则身份验证通过，复制过程继续；如果不一致，则从节点断开socket连接，并重连。

步骤5：发送从节点端口信息

身份验证之后，从节点会向主节点发送其监听的端口号（前述例子中为6380），主节点将该信息保存到该从节点对应的客户端的slave_listening_port字段中；该端口信息除了在主节点中执行info Replication时显示以外，没有其他作用。

数据同步阶段

主从节点之间的连接建立以后，便可以开始进行数据同步，该阶段可以理解为从节点数据的初始化。具体执行的方式是：从节点向主节点发送psync命令（Redis2.8以前是sync命令），开始同步。

数据同步阶段是主从复制最核心的阶段，根据主从节点当前状态的不同，可以分为全量复制和部分复制，下面会有一章专门讲解这两种复制方式以及psync命令的执行过程，这里不再详述。

需要注意的是，在数据同步阶段之前，从节点是主节点的客户端，主节点不是从节点的客户端；而到了这一阶段及以后，主从节点互为客户端。原因在于：在此之前，主节点只需要响应从节点的请求即可，不需要主动发请求，而在数据同步阶段和后面的命令传播阶段，主节点需要主动向从节点发送请求（如推送缓冲区中的写命令），才能完成复制。

命令传播阶段

数据同步阶段完成后，主从节点进入命令传播阶段；在这个阶段主节点将自己执行的写命令发送给从节点，从节点接收命令并执行，从而保证主从节点数据的一致性。

在命令传播阶段，除了发送写命令，主从节点还维持着心跳机制：PING和REPLCONF ACK。由于心跳机制的原理涉及部分复制，因此将在介绍了部分复制的相关内容后单独介绍该心跳机制。

epl-disable-tcp-nodelay no：该配置作用于命令传播阶段，控制主节点是否禁止与从节点的TCP_NODELAY；默认no，即不禁止TCP_NODELAY。当设置为yes时，TCP会对包进行合并从而减少带宽，但是发送的频率会降低，从节点数据延迟增加，一致性变差；具体发送频率与Linux内核的配置有关，默认配置为40ms。当设置为no时，TCP会立马将主节点的数据发送给从节点，带宽增加但延迟变小。

一般来说，只有当应用对Redis数据不一致的容忍度较高，且主从节点之间网络状况不好时，才会设置为yes；多数情况使用默认值no。

全量复制部分复制

在Redis2.8以前，从节点向主节点发送sync命令请求同步数据，此时的同步方式是全量复制；在Redis2.8及以后，从节点可以发送psync命令请求同步数据，此时根据主从节点当前状态的不同，同步方式可能是全量复制或部分复制。后文介绍以Redis2.8及以后版本为例。

全量复制：用于初次复制或其他无法进行部分复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作。
部分复制：用于网络中断等情况后的复制，只将中断期间主节点执行的写命令发送给从节点，与全量复制相比更加高效。需要注意的是，如果网络中断时间过长，导致主节点没有能够完整地保存中断期间执行的写命令，则无法进行部分复制，仍使用全量复制。

全量复制

Redis通过psync命令进行全量复制的过程如下：

（1）从节点判断无法进行部分复制，向主节点发送全量复制的请求；或从节点发送部分复制的请求，但主节点判断无法进行部分复制；具体判断过程需要在讲述了部分复制原理后再介绍。

（2）主节点收到全量复制的命令后，执行bgsave，在后台生成RDB文件，并使用一个缓冲区（称为复制缓冲区）记录从现在开始执行的所有写命令

（3）主节点的bgsave执行完成后，将RDB文件发送给从节点；从节点首先清除自己的旧数据，然后载入接收的**RDB文件**，将数据库状态更新至主节点执行bgsave时的数据库状态

（4）主节点将前述复制缓冲区中的所有写命令发送给从节点，从节点执行这些写命令，将数据库状态更新至主节点的最新状态

（5）如果从节点开启了AOF，则会触发bgrewriteaof的执行，从而保证AOF文件更新至主节点的最新状态

下面是执行全量复制时，主从节点打印的日志；可以看出日志内容与上述步骤是完全对应的。

主节点的打印日志如下：

从节点打印日志如下图所示：

其中，有几点需要注意：从节点接收了来自主节点的89260个字节的数据；从节点在载入主节点的数据之前要先将老数据清除；从节点在同步完数据后，调用了bgrewriteaof。

通过全量复制的过程可以看出，全量复制是非常重型的操作：

（1）主节点通过bgsave命令fork子进程进行RDB持久化，该过程是非常消耗CPU、内存(页表复制)、硬盘IO的；

（2）主节点通过网络将RDB文件发送给从节点，对主从节点的带宽都会带来很大的消耗

（3）从节点清空老数据、载入新RDB文件的过程是阻塞的，无法响应客户端的命令；如果从节点执行bgrewriteaof，也会带来额外的消耗

部分复制

由于全量复制在主节点数据量较大时效率太低，因此Redis2.8开始提供部分复制，用于处理网络中断时的数据同步。部分复制的实现，依赖于三个重要的概念：

（1）复制偏移量

主节点和从节点分别维护一个复制偏移量（offset），代表的是主节点向从节点传递的字节数；主节点每次向从节点传播N个字节数据时，主节点的offset增加N；从节点每次收到主节点传来的N个字节数据时，从节点的offset增加N。

offset用于判断主从节点的数据库状态是否一致：如果二者offset相同，则一致；如果offset不同，则不一致，此时可以根据两个offset找出从节点缺少的那部分数据。例如，如果主节点的offset是1000，而从节点的offset是500，那么部分复制就需要将offset为501-1000的数据传递给从节点。而offset为501-1000的数据存储的位置，就是下面要介绍的复制积压缓冲区。

（2）复制积压缓冲区

复制积压缓冲区是由主节点维护的、固定长度的、先进先出(FIFO)队列，默认大小1MB；当主节点开始有从节点时创建，其作用是备份主节点最近发送给从节点的数据。注意，无论主节点有一个还是多个从节点，都只需要一个复制积压缓冲区。

在命令传播阶段，主节点除了将写命令发送给从节点，还会发送一份给复制积压缓冲区，作为写命令的备份；除了存储写命令，复制积压缓冲区中还存储了其中的每个字节对应的复制偏移量（offset）。由于复制积压缓冲区定长且是先进先出，所以它保存的是主节点最近执行的写命令；时间较早的写命令会被挤出缓冲区。

由于该缓冲区长度固定且有限，因此可以备份的写命令也有限，当主从节点offset的差距过大超过缓冲区长度时，将无法执行部分复制，只能执行全量复制。反过来说，为了提高网络中断时部分复制执行的概率，可以根据需要增大复制积压缓冲区的大小(通过配置repl-backlog-size)；例如如果网络中断的平均时间是60s，而主节点平均每秒产生的写命令(特定协议格式)所占的字节数为100KB，则复制积压缓冲区的平均需求为6MB，保险起见，可以设置为12MB，来保证绝大多数断线情况都可以使用部分复制。

从节点将offset发送给主节点后，主节点根据offset和缓冲区大小决定能否执行部分复制：

如果offset偏移量之后的数据，仍然都在复制积压缓冲区里，则执行部分复制；
如果offset偏移量之后的数据已不在复制积压缓冲区中（数据已被挤出），则执行全量复制。

（3）服务器运行ID(runid)

每个Redis节点(无论主从)，在启动时都会自动生成一个随机ID(每次启动都不一样)，由40个随机的十六进制字符组成；runid用来唯一识别一个Redis节点。通过info Server命令，可以查看节点的runid：

主从节点初次复制时，主节点将自己的runid发送给从节点，从节点将这个runid保存起来；当断线重连时，从节点会将这个runid发送给主节点；主节点根据runid判断能否进行部分复制：

如果从节点保存的runid与主节点现在的runid相同，说明主从节点之前同步过，主节点会继续尝试使用部分复制(到底能不能部分复制还要看offset和复制积压缓冲区的情况)；
如果从节点保存的runid与主节点现在的runid不同，说明从节点在断线前同步的Redis节点并不是当前的主节点，只能进行全量复制。

psync命令的执行

在了解了复制偏移量、复制积压缓冲区、节点运行id之后，本节将介绍psync命令的参数和返回值，从而说明psync命令执行过程中，主从节点是如何确定使用全量复制还是部分复制的。

psync命令的执行过程可以参见下图（图片来源：《Redis设计与实现》）：

（1）首先，从节点根据当前状态，决定如何调用psync命令：

如果从节点之前未执行过slaveof或最近执行了slaveof no one，则从节点发送命令为psync ? -1，向主节点请求全量复制；
如果从节点之前执行了slaveof，则发送命令为psync <runid> <offset>，其中runid为上次复制的主节点的runid，offset为上次复制截止时从节点保存的复制偏移量。

（2）主节点根据收到的psync命令，及当前服务器状态，决定执行全量复制还是部分复制：

如果主节点版本低于Redis2.8，则返回-ERR回复，此时从节点重新发送sync命令执行全量复制；
如果主节点版本够新，且runid与从节点发送的runid相同，且从节点发送的offset之后的数据在复制积压缓冲区中都存在，则回复+CONTINUE，表示将进行部分复制，从节点等待主节点发送其缺少的数据即可；
如果主节点版本够新，但是runid与从节点发送的runid不同，或从节点发送的offset之后的数据已不在复制积压缓冲区中(在队列中被挤出了)，则回复+FULLRESYNC <runid> <offset>，表示要进行全量复制，其中runid表示主节点当前的runid，offset表示主节点当前的offset，从节点保存这两个值，以备使用。

部分插入演示

在下面的演示中，网络中断几分钟后恢复，断开连接的主从节点进行了部分复制；为了便于模拟网络中断，本例中的主从节点在局域网中的两台机器上。

网络中断

网络中断一段时间后，主节点和从节点都会发现失去了与对方的连接（关于主从节点对超时的判断机制，后面会有说明）；此后，从节点便开始执行对主节点的重连，由于此时网络还没有恢复，重连失败，从节点会一直尝试重连。

主节点日志如下：

从节点日志如下：

网络恢复

网络恢复后，从节点连接主节点成功，并请求进行部分复制，主节点接收请求后，二者进行部分复制以同步数据。

主节点日志如下：

从节点日志如下：

心跳机制

在命令传播阶段，除了发送写命令，主从节点还维持着心跳机制：PING和REPLCONF ACK。心跳机制对于主从复制的超时判断、数据安全等有作用。

1.主->从：PING

每隔指定的时间，主节点会向从节点发送**PING命令**，这个PING命令的作用，主要是为了让从节点进行超时判断。

PING发送的频率由repl-ping-slave-period参数控制，单位是秒，默认值是10s。

关于该PING命令究竟是由主节点发给从节点，还是相反，有一些争议；因为在Redis的官方文档中，对该参数的注释中说明是从节点向主节点发送PING命令，如下图所示：

但是根据该参数的名称(含有ping-slave)，以及代码实现，我认为该PING命令是主节点发给从节点的。相关代码如下：

2. 从->主：REPLCONF ACK

在命令传播阶段，从节点会向主节点发送**REPLCONF ACK命令，**频率是每秒1次；命令格式为：REPLCONF ACK {offset}，其中offset指从节点保存的复制偏移量。REPLCONF ACK命令的作用包括：

（1）实时监测主从节点网络状态：该命令会被主节点用于复制超时的判断。此外，在主节点中使用info Replication，可以看到其从节点的状态中的lag值，代表的是主节点上次收到该REPLCONF ACK命令的时间间隔，在正常情况下，该值应该是0或1，如下图所示：

（2）检测命令丢失：从节点发送了自身的offset，主节点会与自己的offset对比，如果从节点数据缺失（如网络丢包），主节点会推送缺失的数据（这里也会利用复制积压缓冲区）。注意，**offset和复制积压缓冲区，不仅可以用于部分复制，也可以用于处理命令丢失等情形；区别在于前者是在断线重连后进行的，而后者是在主从节点没有断线的情况下进行的。**

（3）辅助保证从节点的数量和延迟：Redis主节点中使用min-slaves-to-write和min-slaves-max-lag参数，来保证主节点在不安全的情况下不会执行写命令；所谓不安全，是指从节点数量太少，或延迟过高。例如min-slaves-to-write和min-slaves-max-lag分别是3和10，含义是如果从节点数量小于3个，或所有从节点的延迟值都大于10s，则主节点拒绝执行写命令。而这里从节点延迟值的获取，就是通过主节点接收到REPLCONF ACK命令的时间来判断的，即前面所说的info Replication中的lag值。

问题

读写分离及其中的问题

在主从复制基础上实现的读写分离，可以实现Redis的读负载均衡：由主节点提供写服务，由一个或多个从节点提供读服务（多个从节点既可以提高数据冗余程度，也可以最大化读负载能力）；在读负载较大的应用场景下，可以大大提高Redis服务器的并发量。下面介绍在使用Redis读写分离时，需要注意的问题。

（1）延迟与不一致问题

前面已经讲到，由于主从复制的命令传播是异步的，延迟与数据的不一致不可避免。如果应用对数据不一致的接受程度程度较低，可能的优化措施包括：优化主从节点之间的网络环境（如在同机房部署）；监控主从节点延迟（通过offset）判断，如果从节点延迟过大，通知应用不再通过该从节点读取数据；使用集群同时扩展写负载和读负载等。

在命令传播阶段以外的其他情况下，从节点的数据不一致可能更加严重，例如连接在数据同步阶段，或从节点失去与主节点的连接时等。从节点的slave-serve-stale-data参数便与此有关：它控制这种情况下从节点的表现；如果为yes（默认值），则从节点仍能够响应客户端的命令，如果为no，则从节点只能响应info、slaveof等少数命令。该参数的设置与应用对数据一致性的要求有关；如果对数据一致性要求很高，则应设置为no。

（2）数据过期问题

在单机版Redis中，存在两种删除策略：

惰性删除：服务器不会主动删除数据，只有当客户端查询某个数据时，服务器判断该数据是否过期，如果过期则删除。
定期删除：服务器执行定时任务删除过期数据，但是考虑到内存和CPU的折中（删除会释放内存，但是频繁的删除操作对CPU不友好），该删除的频率和执行时间都受到了限制。

在主从复制场景下，为了主从节点的数据一致性，从节点不会主动删除数据，而是由主节点控制从节点中过期数据的删除。由于主节点的惰性删除和定期删除策略，都不能保证主节点及时对过期数据执行删除操作，因此，当客户端通过Redis从节点读取数据时，很容易读取到已经过期的数据。

Redis 3.2中，从节点在读取数据时，增加了对数据是否过期的判断：如果该数据已过期，则不返回给客户端；将Redis升级到3.2可以解决数据过期问题。

（3）故障切换问题

在没有使用哨兵的读写分离场景下，应用针对读和写分别连接不同的Redis节点；当主节点或从节点出现问题而发生更改时，需要及时修改应用程序读写Redis数据的连接；连接的切换可以手动进行，或者自己写监控程序进行切换，但前者响应慢、容易出错，后者实现复杂，成本都不算低。

（4）总结

在使用读写分离之前，可以考虑其他方法增加Redis的读负载能力：如尽量优化主节点（减少慢查询、减少持久化等其他情况带来的阻塞等）提高负载能力；使用Redis集群同时提高读负载能力和写负载能力等。如果使用读写分离，可以使用哨兵，使主从节点的故障切换尽可能自动化，并减少对应用程序的侵入。

复制超时问题

主从节点复制超时是导致复制中断的最重要的原因之一，本小节单独说明超时问题，下一小节说明其他会导致复制中断的问题。

超时判断意义

在复制连接建立过程中及之后，主从节点都有机制判断连接是否超时，其意义在于：

（1）如果主节点判断连接超时，其会释放相应从节点的连接，从而释放各种资源，否则无效的从节点仍会占用主节点的各种资源（输出缓冲区、带宽、连接等）；此外连接超时的判断可以让主节点更准确的知道当前有效从节点的个数，有助于保证数据安全（配合前面讲到的min-slaves-to-write等参数）。

（2）如果从节点判断连接超时，则可以及时重新建立连接，避免与主节点数据长期的不一致。

判断机制

主从复制超时判断的核心，在于repl-timeout参数，该参数规定了超时时间的阈值（默认60s），对于主节点和从节点同时有效；主从节点触发超时的条件分别如下：

（1）主节点：每秒1次调用复制定时函数replicationCron()，在其中判断当前时间距离上次收到各个从节点REPLCONF ACK的时间，是否超过了repl-timeout值，如果超过了则释放相应从节点的连接。

（2）从节点：从节点对超时的判断同样是在复制定时函数中判断，基本逻辑是：

如果当前处于连接建立阶段，且距离上次收到主节点的信息的时间已超过repl-timeout，则释放与主节点的连接；
如果当前处于数据同步阶段，且收到主节点的RDB文件的时间超时，则停止数据同步，释放连接；
如果当前处于命令传播阶段，且距离上次收到主节点的PING命令或数据的时间已超过repl-timeout值，则释放与主节点的连接。

需要注意的坑

下面介绍与复制阶段连接超时有关的一些实际问题：

（1）数据同步阶段：在主从节点进行全量复制bgsave时，主节点需要首先fork子进程将当前数据保存到RDB文件中，然后再将RDB文件通过网络传输到从节点。如果RDB文件过大，主节点在fork子进程+保存RDB文件时耗时过多，可能会导致从节点长时间收不到数据而触发超时；此时从节点会重连主节点，然后再次全量复制，再次超时，再次重连……这是个悲伤的循环。为了避免这种情况的发生，除了注意Redis单机数据量不要过大，另一方面就是适当增大repl-timeout值，具体的大小可以根据bgsave耗时来调整。

（2）命令传播阶段：如前所述，在该阶段主节点会向从节点发送PING命令，频率由repl-ping-slave-period控制；该参数应明显小于repl-timeout值(后者至少是前者的几倍)。否则，如果两个参数相等或接近，网络抖动导致个别PING命令丢失，此时恰巧主节点也没有向从节点发送数据，则从节点很容易判断超时。

（3）慢查询导致的阻塞：如果主节点或从节点执行了一些慢查询（如keys *或者对大数据的hgetall等），导致服务器阻塞；阻塞期间无法响应复制连接中对方节点的请求，可能导致复制超时。

复制中断问题

主从节点超时是复制中断的原因之一，除此之外，还有其他情况可能导致复制中断，其中最主要的是复制缓冲区溢出问题。

复制缓冲区溢出

前面曾提到过，在全量复制阶段，主节点会将执行的写命令放到复制缓冲区中，该缓冲区存放的数据包括了以下几个时间段内主节点执行的写命令：bgsave生成RDB文件、RDB文件由主节点发往从节点、从节点清空老数据并载入RDB文件中的数据。当主节点数据量较大，或者主从节点之间网络延迟较大时，可能导致该缓冲区的大小超过了限制，此时主节点会断开与从节点之间的连接；这种情况可能引起全量复制->复制缓冲区溢出导致连接中断->重连->全量复制->复制缓冲区溢出导致连接中断……的循环。

复制缓冲区的大小由client-output-buffer-limit slave {hard limit} {soft limit} {soft seconds}配置，默认值为client-output-buffer-limit slave 256MB 64MB 60，其含义是：如果buffer大于256MB，或者连续60s大于64MB，则主节点会断开与该从节点的连接。该参数是可以通过config set命令动态配置的（即不重启Redis也可以生效）。

当复制缓冲区溢出时，主节点打印日志如下所示：

需要注意的是，复制缓冲区是客户端输出缓冲区的一种，主节点会为每一个从节点分别分配复制缓冲区；而复制积压缓冲区则是一个主节点只有一个，无论它有多少个从节点。

各场景下复制的选择及优化技巧

在介绍了Redis复制的种种细节之后，现在我们可以来总结一下，在下面常见的场景中，何时使用部分复制，以及需要注意哪些问题。

（1）第一次建立复制

此时全量复制不可避免，但仍有几点需要注意：如果主节点的数据量较大，应该尽量避开流量的高峰期，避免造成阻塞；如果有多个从节点需要建立对主节点的复制，可以考虑将几个从节点错开，避免主节点带宽占用过大。此外，如果从节点过多，也可以调整主从复制的拓扑结构，由一主多从结构变为树状结构（中间的节点既是其主节点的从节点，也是其从节点的主节点）；但使用树状结构应该谨慎：虽然主节点的直接从节点减少，降低了主节点的负担，但是多层从节点的延迟增大，数据一致性变差；且结构复杂，维护相当困难。

（2）主节点重启

主节点重启可以分为两种情况来讨论，一种是故障导致宕机，另一种则是有计划的重启。

主节点宕机

主节点宕机重启后，runid会发生变化，因此不能进行部分复制，只能全量复制。

实际上在主节点宕机的情况下，应进行故障转移处理，将其中的一个从节点升级为主节点，其他从节点从新的主节点进行复制；且故障转移应尽量的自动化，后面文章将要介绍的哨兵便可以进行自动的故障转移。

安全重启：debug reload

在一些场景下，可能希望对主节点进行重启，例如主节点内存碎片率过高，或者希望调整一些只能在启动时调整的参数。如果使用普通的手段重启主节点，会使得runid发生变化，可能导致不必要的全量复制。

为了解决这个问题，Redis提供了debug reload的重启方式：重启后，主节点的**runid和offset都不受影响，**避免了全量复制。

如下图所示，debug reload重启后runid和offset都未受影响：

但debug reload是一柄双刃剑：它会清空当前内存中的数据，重新从RDB文件中加载，这个过程会导致主节点的阻塞，因此也需要谨慎。

（3）从节点重启

从节点宕机重启后，其保存的主节点的runid会丢失，因此即使再次执行slaveof，也无法进行部分复制。

（4）网络中断

如果主从节点之间出现网络问题，造成短时间内网络中断，可以分为多种情况讨论。

第一种情况：网络问题时间极为短暂，只造成了短暂的丢包，主从节点都没有判定超时（未触发repl-timeout）；此时只需要通过REPLCONF ACK来补充丢失的数据即可。

第二种情况：网络问题时间很长，主从节点判断超时（触发了repl-timeout），且丢失的数据过多，超过了复制积压缓冲区所能存储的范围；此时主从节点无法进行部分复制，只能进行全量复制。为了尽可能避免这种情况的发生，应该根据实际情况适当调整复制积压缓冲区的大小；此外及时发现并修复网络中断，也可以减少全量复制。

第三种情况：介于前述两种情况之间，主从节点判断超时，且丢失的数据仍然都在复制积压缓冲区中；此时主从节点可以进行部分复制。

复制相关的配置

这一节总结一下与复制有关的配置，说明这些配置的作用、起作用的阶段，以及配置方法等；通过了解这些配置，一方面加深对Redis复制的了解，另一方面掌握这些配置的方法，可以优化Redis的使用，少走坑。

配置大致可以分为主节点相关配置、从节点相关配置以及与主从节点都有关的配置，下面分别说明。

（1）与主从节点都有关的配置

首先介绍最特殊的配置，它决定了该节点是主节点还是从节点：

\1) slaveof <masterip> <masterport>：Redis启动时起作用；作用是建立复制关系，开启了该配置的Redis服务器在启动后成为从节点。该注释默认注释掉，即Redis服务器默认都是主节点。

\2) repl-timeout 60：与各个阶段主从节点连接超时判断有关，见前面的介绍。

（2）主节点相关配置

\1) repl-diskless-sync no：作用于全量复制阶段，控制主节点是否使用diskless复制（无盘复制）。所谓diskless复制，是指在全量复制时，主节点不再先把数据写入RDB文件，而是直接写入slave的socket中，整个过程中不涉及硬盘；diskless复制在磁盘IO很慢而网速很快时更有优势。需要注意的是，截至Redis3.0，diskless复制处于实验阶段，默认是关闭的。

\2) repl-diskless-sync-delay 5：该配置作用于全量复制阶段，当主节点使用diskless复制时，该配置决定主节点向从节点发送之前停顿的时间，单位是秒；只有当diskless复制打开时有效，默认5s。之所以设置停顿时间，是基于以下两个考虑：(1)向slave的socket的传输一旦开始，新连接的slave只能等待当前数据传输结束，才能开始新的数据传输 (2)多个从节点有较大的概率在短时间内建立主从复制。

\3) client-output-buffer-limit slave 256MB 64MB 60：与全量复制阶段主节点的缓冲区大小有关，见前面的介绍。

\4) repl-disable-tcp-nodelay no：与命令传播阶段的延迟有关，见前面的介绍。

\5) masterauth <master-password>：与连接建立阶段的身份验证有关，见前面的介绍。

\6) repl-ping-slave-period 10：与命令传播阶段主从节点的超时判断有关，见前面的介绍。

\7) repl-backlog-size 1mb：复制积压缓冲区的大小，见前面的介绍。

\8) repl-backlog-ttl 3600：当主节点没有从节点时，复制积压缓冲区保留的时间，这样当断开的从节点重新连进来时，可以进行部分复制；默认3600s。如果设置为0，则永远不会释放复制积压缓冲区。

\9) min-slaves-to-write 3与min-slaves-max-lag 10：规定了主节点的最小从节点数目，及对应的最大延迟，见前面的介绍。

（3）从节点相关配置

\1) slave-serve-stale-data yes：与从节点数据陈旧时是否响应客户端命令有关，见前面的介绍。

\2) slave-read-only yes：从节点是否只读；默认是只读的。由于从节点开启写操作容易导致主从节点的数据不一致，因此该配置尽量不要修改。

单机内存大小限制

在深入学习Redis（2）：持久化一文中，讲到了fork操作对Redis单机内存大小的限制。实际上在Redis的使用中，限制单机内存大小的因素非常之多，下面总结一下在主从复制中，单机内存过大可能造成的影响：

（1）切主：当主节点宕机时，一种常见的容灾策略是将其中一个从节点提升为主节点，并将其他从节点挂载到新的主节点上，此时这些从节点只能进行全量复制；如果Redis单机内存达到10GB，一个从节点的同步时间在几分钟的级别；如果从节点较多，恢复的速度会更慢。如果系统的读负载很高，而这段时间从节点无法提供服务，会对系统造成很大的压力。

（2）从库扩容：如果访问量突然增大，此时希望增加从节点分担读负载，如果数据量过大，从节点同步太慢，难以及时应对访问量的暴增。

（3）缓冲区溢出：（1）和（2）都是从节点可以正常同步的情形（虽然慢），但是如果数据量过大，导致全量复制阶段主节点的复制缓冲区溢出，从而导致复制中断，则主从节点的数据同步会全量复制->复制缓冲区溢出导致复制中断->重连->全量复制->复制缓冲区溢出导致复制中断……的循环。

（4）超时：如果数据量过大，全量复制阶段主节点fork+保存RDB文件耗时过大，从节点长时间接收不到数据触发超时，主从节点的数据同步同样可能陷入全量复制->超时导致复制中断->重连->全量复制->超时导致复制中断……的循环。

此外，主节点单机内存除了绝对量不能太大，其占用主机内存的比例也不应过大：最好只使用50%-65%的内存，留下30%-45%的内存用于执行bgsave命令和创建复制缓冲区等。

info Replication

在Redis客户端通过info Replication可以查看与复制相关的状态，对于了解主从节点的当前状态，以及解决出现的问题都会有帮助。

主节点：

从节点：

对于从节点，上半部分展示的是其作为从节点的状态，从connectd_slaves开始，展示的是其作为潜在的主节点的状态。

info Replication中展示的大部分内容在文章中都已经讲述，这里不再详述。

总结

1、主从复制的作用：宏观的了解主从复制是为了解决什么样的问题，即数据冗余、故障恢复、读负载均衡等。

2、主从复制的操作：即slaveof命令。

3、主从复制的原理：主从复制包括了连接建立阶段、数据同步阶段、命令传播阶段；其中数据同步阶段，有全量复制和部分复制两种数据同步方式；命令传播阶段，主从节点之间有PING和REPLCONF ACK命令互相进行心跳检测。

4、应用中的问题：包括读写分离的问题（数据不一致问题、数据过期问题、故障切换问题等）、复制超时问题、复制中断问题等，然后总结了主从复制相关的配置，其中repl-timeout、client-output-buffer-limit slave等对解决Redis主从复制中出现的问题可能会有帮助。

主从复制虽然解决或缓解了数据冗余、故障恢复、读负载均衡等问题，但其缺陷仍很明显：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制；这些问题的解决，需要哨兵和集群的帮助。

哨兵机制

深入学习Redis（4）：哨兵 - 编程迷思 - 博客园 (cnblogs.com)

哨兵模式下，使用redisTemplate编码爱好者-CSDN博客redistemplate 哨兵

作用

在介绍哨兵之前，首先从宏观角度回顾一下Redis实现高可用相关的技术。它们包括：持久化、复制、哨兵和集群，其主要作用和解决的问题是：

持久化：持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
复制：复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。
哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。
集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

哨兵

Redis Sentinel，即Redis哨兵，在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。下面是Redis官方文档对于哨兵功能的描述：

监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

这里对“客户端”一词在文章中的用法做一个说明：在前面的文章中，只要通过API访问redis服务器，都会称作客户端，包括redis-cli、Java客户端Jedis等；为了便于区分说明，本文中的客户端并不包括redis-cli，而是比redis-cli更加复杂：redis-cli使用的是redis提供的底层接口，而客户端则对这些接口、功能进行了封装，以便充分利用哨兵的配置提供者和通知功能。

架构

典型的哨兵架构图如下所示：

它由两部分组成，哨兵节点和数据节点：

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
数据节点：主节点和从节点都是数据节点。

部署

这一部分将部署一个简单的哨兵系统，包含1个主节点、2个从节点和3个哨兵节点。方便起见：所有这些节点都部署在一台机器上（局域网IP：192.168.92.128），使用端口号区分；节点的配置尽可能简化。

1. 部署主从节点

哨兵系统中的主从节点，与普通的主从节点配置是一样的，并不需要做任何额外配置。下面分别是主节点（port=6379）和2个从节点（port=6380/6381）的配置文件，配置都比较简单，不再详述。

#redis-6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
 
#redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 192.168.92.128 6379
 
#redis-6381.conf
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 192.168.92.128 6379

配置完成后，依次启动主节点和从节点：

redis-server redis-6379.conf
redis-server redis-6380.conf
redis-server redis-6381.conf

节点启动后，连接主节点查看主从状态是否正常，如下图所示：

2. 部署哨兵节点

哨兵节点本质上是特殊的Redis节点。

3个哨兵节点的配置几乎是完全一样的，主要区别在于端口号的不同（26379/26380/26381），下面以26379节点为例介绍节点的配置和启动方式；配置部分尽量简化，更多配置会在后面介绍。

#sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
sentinel monitor mymaster 192.168.92.128 6379 2

其中，sentinel monitor mymaster 192.168.92.128 6379 2 配置的含义是：该哨兵节点监控192.168.92.128:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。

哨兵节点的启动有两种方式，二者作用是完全相同的：

redis-sentinel sentinel-26379.conf``redis-server sentinel-26379.conf ``--sentinel

按照上述方式配置和启动之后，整个哨兵系统就启动完毕了。可以通过redis-cli连接哨兵节点进行验证，如下图所示：可以看出26379哨兵节点已经在监控mymaster主节点(即192.168.92.128:6379)，并发现了其2个从节点和另外2个哨兵节点。

此时如果查看哨兵节点的配置文件，会发现一些变化，以26379为例：

其中，dir只是显式声明了数据和日志所在的目录（在哨兵语境下只有日志）；known-slave和known-sentinel显示哨兵已经发现了从节点和其他哨兵；带有epoch的参数与配置纪元有关（配置纪元是一个从0开始的计数器，每进行一次领导者哨兵选举，都会+1；领导者哨兵选举是故障转移阶段的一个操作，在后文原理部分会介绍）。

演示故障转移

哨兵的4个作用中，配置提供者和通知需要客户端的配合，本文将在下一章介绍客户端访问哨兵系统的方法时详细介绍。这一小节将演示当主节点发生故障时，哨兵的监控和自动故障转移功能。

（1）首先，使用kill命令杀掉主节点：

（2）如果此时立即在哨兵节点中使用info Sentinel命令查看，会发现主节点还没有切换过来，因为哨兵发现主节点故障并转移，需要一段时间。

（3）一段时间以后，再次在哨兵节点中执行info Sentinel查看，发现主节点已经切换成6380节点。

但是同时可以发现，哨兵节点认为新的主节点仍然有2个从节点，这是因为哨兵在将6380切换成主节点的同时，将6379节点置为其从节点；虽然6379从节点已经挂掉，但是由于哨兵并不会对从节点进行客观下线（其含义将在原理部分介绍），因此认为该从节点一直存在。当6379节点重新启动后，会自动变成6380节点的从节点。下面验证一下。

（4）重启6379节点：可以看到6379节点成为了6380节点的从节点。

（5）在故障转移阶段，哨兵和主从节点的配置文件都会被改写。

对于主从节点，主要是slaveof配置的变化：新的主节点没有了slaveof配置，其从节点则slaveof新的主节点。

对于哨兵节点，除了主从节点信息的变化，纪元(epoch)也会变化，下图中可以看到纪元相关的参数都+1了。

系统搭建总结

哨兵系统的搭建过程，有几点需要注意：

（1）哨兵系统中的主从节点，与普通的主从节点并没有什么区别，故障发现和转移是由哨兵来控制和完成的。

（2）哨兵节点本质上是redis节点。

（3）每个哨兵节点，只需要配置监控主节点，便可以自动发现其他的哨兵节点和从节点。

（4）在哨兵节点启动和故障转移阶段，各个节点的配置文件会被重写(config rewrite)。

（5）本章的例子中，一个哨兵只监控了一个主节点；实际上，一个哨兵可以监控多个主节点，通过配置多条sentinel monitor即可实现。

客户端访问

深入学习Redis（4）：哨兵 - 编程迷思 - 博客园 (cnblogs.com)

基本原理

（1）定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：通过向主从节点发送info命令获取最新的主从结构；通过发布订阅功能获取其他哨兵节点的信息；通过向其他节点发送ping命令进行心跳检测，判断是否下线。

（2）主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。

（3）客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。

需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

（4）选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。

（5）故障转移：选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：

在从节点中选择新的主节点：选择的原则是，首先过滤掉不健康的从节点；然后选择优先级最高的从节点(由slave-priority指定)；如果优先级无法区分，则选择复制偏移量最大的从节点；如果仍无法区分，则选择runid最小的从节点。
更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
将已经下线的主节点(即6379)设置为新的主节点的从节点，当6379重新上线后，它会成为新的主节点的从节点。

通过上述几个关键概念，可以基本了解哨兵的工作原理。为了更形象的说明，下图展示了领导者哨兵节点的日志，包括从节点启动到完成故障转移。

配置

（1） sentinel monitor {masterName} {masterIp} {masterPort} {quorum}

sentinel monitor是哨兵最核心的配置，在前文讲述部署哨兵节点时已说明，其中：masterName指定了主节点名称，masterIp和masterPort指定了主节点地址，quorum是判断主节点客观下线的哨兵数量阈值：当判定主节点下线的哨兵数量达到quorum时，对主节点进行客观下线。建议取值为哨兵数量的一半加1。

（2） sentinel down-after-milliseconds {masterName} {time}

sentinel down-after-milliseconds与主观下线的判断有关：哨兵使用ping命令对其他节点进行心跳检测，如果其他节点超过down-after-milliseconds配置的时间没有回复，哨兵就会将其进行主观下线。该配置对主节点、从节点和哨兵节点的主观下线判定都有效。

down-after-milliseconds的默认值是30000，即30s；可以根据不同的网络环境和应用要求来调整：值越大，对主观下线的判定会越宽松，好处是误判的可能性小，坏处是故障发现和故障转移的时间变长，客户端等待的时间也会变长。例如，如果应用对可用性要求较高，则可以将值适当调小，当故障发生时尽快完成转移；如果网络环境相对较差，可以适当提高该阈值，避免频繁误判。

（3） sentinel parallel-syncs {masterName} {number}

sentinel parallel-syncs与故障转移之后从节点的复制有关：它规定了每次向新的主节点发起复制操作的从节点个数。例如，假设主节点切换完成之后，有3个从节点要向新的主节点发起复制；如果parallel-syncs=1，则从节点会一个一个开始复制；如果parallel-syncs=3，则3个从节点会一起开始复制。

parallel-syncs取值越大，从节点完成复制的时间越快，但是对主节点的网络负载、硬盘负载造成的压力也越大；应根据实际情况设置。例如，如果主节点的负载较低，而从节点对服务可用的要求较高，可以适量增加parallel-syncs取值。parallel-syncs的默认值是1。

（4） sentinel failover-timeout {masterName} {time}

sentinel failover-timeout与故障转移超时的判断有关，但是该参数不是用来判断整个故障转移阶段的超时，而是其几个子阶段的超时，例如如果主节点晋升从节点时间超过timeout，或从节点向新的主节点发起复制操作的时间(不包括复制数据的时间)超过timeout，都会导致故障转移超时失败。

failover-timeout的默认值是180000，即180s；如果超时，则下一次该值会变为原来的2倍。

（5）除上述几个参数外，还有一些其他参数，如安全验证相关的参数，这里不做介绍。

实践建议

（1）哨兵节点的数量应不止一个，一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈；另一方面减少对下线的误判。此外，这些不同的哨兵节点应部署在不同的物理机上。

（2）哨兵节点的数量应该是奇数，便于哨兵通过投票做出“决策”：领导者选举的决策、客观下线的决策等。

（3）各个哨兵节点的配置应一致，包括硬件、参数等；此外，所有节点都应该使用ntp或类似服务，保证时间准确、一致。

（4）哨兵的配置提供者和通知客户端功能，需要客户端的支持才能实现，如前文所说的Jedis；如果开发者使用的库未提供相应支持，则可能需要开发者自己实现。

（5）当哨兵系统中的节点在docker（或其他可能进行端口映射的软件）中部署时，应特别注意端口映射可能会导致哨兵系统无法正常工作，因为哨兵的工作基于与其他节点的通信，而docker的端口映射可能导致哨兵无法连接到其他节点。例如，哨兵之间互相发现，依赖于它们对外宣称的IP和port，如果某个哨兵A部署在做了端口映射的docker中，那么其他哨兵使用A宣称的port无法连接到A。

总结

本文首先介绍了哨兵的作用：监控、故障转移、配置提供者和通知；然后讲述了哨兵系统的部署方法，以及通过客户端访问哨兵系统的方法；再然后简要说明了哨兵实现的基本原理；最后给出了关于哨兵实践的一些建议。

在主从复制的基础上，哨兵引入了主节点的自动故障转移，进一步提高了Redis的高可用性；但是哨兵的缺陷同样很明显：哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要我们对从节点做额外的监控、切换操作。

此外，哨兵仍然没有解决写操作无法负载均衡、及存储能力受到单机限制的问题；这些问题的解决需要使用集群。

集群

万字真言：Springboot使用RedisTemplate Cluster集群正确姿势bugpool的博客-CSDN博客redistemplate 集群

在前面的文章中，已经介绍了Redis的几种高可用技术：持久化、主从复制和哨兵，但这些方案仍有不足，其中最主要的问题是存储能力受单机限制，以及无法实现写操作的负载均衡。

Redis集群解决了上述问题，实现了较为完善的高可用方案。本文将详细介绍集群，主要内容包括：集群的作用；集群的搭建方法及设计方案；集群的基本原理；客户端访问集群的方法；以及其他实践中需要的集群知识（集群扩容、故障转移、参数优化等）。

集群的作用

集群，即Redis Cluster，是Redis 3.0开始引入的分布式存储方案。

集群由多个节点(Node)组成，Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点：只有主节点负责读写请求和集群信息的维护；从节点只进行主节点数据和状态信息的复制。

集群的作用，可以归纳为两点：

1、数据分区：数据分区(或称数据分片)是集群最核心的功能。

集群将数据分散到多个节点，一方面突破了Redis单机内存大小的限制，存储容量大大增加；另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。

Redis单机内存大小受限问题，在介绍持久化和主从复制时都有提及；例如，如果单机内存太大，bgsave和bgrewriteaof的fork操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出……。

2、高可用：集群支持主从复制和主节点的自动故障转移（与哨兵类似）；当任一节点发生故障时，集群仍然可以对外提供服务。

本文内容基于Redis 3.0.6。

集群的搭建

这一部分我们将搭建一个简单的集群：共6个节点，3主3从。方便起见：所有节点在同一台服务器上，以端口号进行区分；配置从简。3个主节点端口号：7000/7001/7002，对应的从节点端口号：8000/8001/8002。

集群的搭建有两种方式：（1）手动执行Redis命令，一步步完成搭建；（2）使用Ruby脚本搭建。二者搭建的原理是一样的，只是Ruby脚本将Redis命令进行了打包封装；在实际应用中推荐使用脚本方式，简单快捷不容易出错。下面分别介绍这两种方式。

执行Redis命令搭建集群

集群的搭建可以分为四步：

（1）启动节点：将节点以集群模式启动，此时节点是独立的，并没有建立联系；

（2）节点握手：让独立的节点连成一个网络；

（3）分配槽：将16384个槽分配给主节点；

（4）指定主从关系：为从节点指定主节点。

实际上，前三步完成后集群便可以对外提供服务；但指定从节点后，集群才能够提供真正高可用的服务。

（1）启动节点

集群节点的启动仍然是使用redis-server命令，但需要使用集群模式启动。下面是7000节点的配置文件（只列出了节点正常工作关键配置，其他配置(如开启AOF)可以参照单机节点进行）：

#redis-7000.conf
port 7000
cluster-enabled yes
cluster-config-file "node-7000.conf"
logfile "log-7000.log"
dbfilename "dump-7000.rdb"
daemonize yes

其中的cluster-enabled和cluster-config-file是与集群相关的配置。

cluster-enabled yes**：**Redis实例可以分为单机模式(standalone)和集群模式(cluster)；cluster-enabled yes可以启动集群模式。在单机模式下启动的Redis实例，如果执行info server命令，可以发现redis_mode一项为standalone，如下图所示：

集群模式下的节点，其redis_mode为cluster，如下图所示：

cluster-config-file**：该参数指定了集群配置文件的位置。每个节点在运行过程中，会维护一份集群配置文件；每当集群信息发生变化时（如增减节点），集群内所有节点会将最新信息更新到该配置文件；当节点重启后，会重新读取该配置文件，获取集群信息，可以方便的重新加入到集群中。也就是说，当Redis节点以集群模式启动时，会首先寻找是否有集群配置文件，如果有则使用文件中的配置启动，如果没有，则初始化配置并将配置保存到文件中。**集群配置文件由Redis节点维护，不需要人工修改。

编辑好配置文件后，使用redis-server命令启动该节点：

redis-server redis-7000.conf

节点启动以后，通过cluster nodes命令可以查看节点的情况，如下图所示。

其中返回值第一项表示节点id，由40个16进制字符串组成，节点id与主从复制一文中提到的runId不同：Redis每次启动runId都会重新创建，但是节点id只在集群初始化时创建一次，然后保存到集群配置文件中，以后节点重新启动时会直接在集群配置文件中读取。

其他节点使用相同办法启动，不再赘述。需要特别注意，在启动节点阶段，节点是没有主从关系的，因此从节点不需要加slaveof配置。

（2）节点握手

节点启动以后是相互独立的，并不知道其他节点存在；需要进行节点握手，将独立的节点组成一个网络。

节点握手使用cluster meet {ip} {port}命令实现，例如在7000节点中执行cluster meet 192.168.72.128 7001，可以完成7000节点和7001节点的握手；注意ip使用的是局域网ip而不是localhost或127.0.0.1，是为了其他机器上的节点或客户端也可以访问。此时再使用cluster nodes查看：

在7001节点下也可以类似查看：

同理，在7000节点中使用cluster meet命令，可以将所有节点加入到集群，完成节点握手：

cluster meet 192.168.72.128 7002
cluster meet 192.168.72.128 8000
cluster meet 192.168.72.128 8001
cluster meet 192.168.72.128 8002

执行完上述命令后，可以看到7000节点已经感知到了所有其他节点：

通过节点之间的通信，每个节点都可以感知到所有其他节点，以8000节点为例：

（3）分配槽

在Redis集群中，借助槽实现数据分区，具体原理后文会介绍。集群有**16384个槽，槽是数据管理和迁移的基本单位。当数据库中的16384个槽都分配了节点时，集群处于上线状态（ok）；如果有任意一个槽没有分配节点，则集群处于下线状态（fail）。**

cluster info命令可以查看集群状态，分配槽之前状态为fail：

分配槽使用cluster addslots命令，执行下面的命令将槽（编号0-16383）全部分配完毕：

redis-cli -p 7000 cluster addslots {0..5461}
redis-cli -p 7001 cluster addslots {5462..10922}
redis-cli -p 7002 cluster addslots {10923..16383}

此时查看集群状态，显示所有槽分配完毕，集群进入上线状态：

（4）指定主从关系

集群中指定主从关系不再使用slaveof命令，而是使用cluster replicate命令；参数使用节点id。

通过cluster nodes获得几个主节点的节点id后，执行下面的命令为每个从节点指定主节点：

redis-cli -p 8000 cluster replicate be816eba968bc16c884b963d768c945e86ac51ae
redis-cli -p 8001 cluster replicate 788b361563acb175ce8232569347812a12f1fdb4
redis-cli -p 8002 cluster replicate a26f1624a3da3e5197dde267de683d61bb2dcbf1

此时执行cluster nodes查看各个节点的状态，可以看到主从关系已经建立。

使用Ruby脚本搭建集群

在{REDIS_HOME}/src目录下可以看到redis-trib.rb文件，这是一个Ruby脚本，可以实现自动化的集群搭建。

（1）安装Ruby环境

以Ubuntu为例，如下操作即可安装Ruby环境：

apt-get install ruby #安装ruby环境``gem install redis #gem是ruby的包管理工具，该命令可以安装ruby-redis依赖

（2）启动节点

与第一种方法中的“启动节点”完全相同。

（3）搭建集群

redis-trib.rb脚本提供了众多命令，其中create用于搭建集群，使用方法如下：

./redis-trib.rb ``create` `--replicas 1 192.168.72.128:7000 192.168.72.128:7001 192.168.72.128:7002 192.168.72.128:8000 192.168.72.128:8001 192.168.72.128:8002

其中：--replicas=1表示每个主节点有1个从节点；后面的多个{ip:port}表示节点地址，前面的做主节点，后面的做从节点。使用redis-trib.rb搭建集群时，要求节点不能包含任何槽和数据。

执行创建命令后，脚本会给出创建集群的计划，如下图所示；计划包括哪些是主节点，哪些是从节点，以及如何分配槽。

输入yes确认执行计划，脚本便开始按照计划执行，如下图所示。

集群方案设计

设计集群方案时，至少要考虑以下因素：

（1）高可用要求：根据故障转移的原理，至少需要3个主节点才能完成故障转移，且3个主节点不应在同一台物理机上；每个主节点至少需要1个从节点，且主从节点不应在一台物理机上；因此高可用集群至少包含6个节点。

（2）数据量和访问量：估算应用需要的数据量和总访问量(考虑业务发展，留有冗余)，结合每个主节点的容量和能承受的访问量(可以通过benchmark得到较准确估计)，计算需要的主节点数量。

（3）节点数量限制：Redis官方给出的节点数量限制为1000，主要是考虑节点间通信带来的消耗。在实际应用中应尽量避免大集群；如果节点数量不足以满足应用对Redis数据量和访问量的要求，可以考虑：(1)业务分割，大集群分为多个小集群；(2)减少不必要的数据；(3)调整数据过期策略等。

（4）适度冗余：Redis可以在不影响集群服务的情况下增加节点，因此节点数量适当冗余即可，不用太大。

集群的原理

集群最核心的功能是数据分区，因此首先介绍数据的分区规则；然后介绍集群实现的细节：通信机制和数据结构；最后以cluster meet(节点握手)、cluster addslots(槽分配)为例，说明节点是如何利用上述数据结构和通信机制实现集群命令的。

数据分区方案

数据分区有顺序分区、哈希分区等，其中哈希分区由于其天然的随机性，使用广泛；集群的分区方案便是哈希分区的一种。

哈希分区的基本思路是：对数据的特征值（如key）进行哈希，然后根据哈希值决定数据落在哪个节点。常见的哈希分区包括：哈希取余分区、一致性哈希分区、带虚拟节点的一致性哈希分区等。

衡量数据分区方法好坏的标准有很多，其中比较重要的两个因素是(1)数据分布是否均匀(2)增加或删减节点对数据分布的影响。由于哈希的随机性，哈希分区基本可以保证数据分布均匀；因此在比较哈希分区方案时，重点要看增减节点对数据分布的影响。

（1）哈希取余分区

哈希取余分区思路非常简单：计算key的hash值，然后对节点数量进行取余，从而决定数据映射到哪个节点上。该方案最大的问题是，当新增或删减节点时，节点数量发生变化，系统中所有的数据都需要重新计算映射关系，引发大规模数据迁移。

（2）一致性哈希分区

一致性哈希算法将整个哈希值空间组织成一个虚拟的圆环，如下图所示，范围为0-2^32-1；对于每个数据，根据key计算hash值，确定数据在环上的位置，然后从此位置沿环顺时针行走，找到的第一台服务器就是其应该映射到的服务器。

图片来源：一致性哈希算法原理 - lpfuture - 博客园

与哈希取余分区相比，一致性哈希分区将增减节点的影响限制在相邻节点。以上图为例，如果在node1和node2之间增加node5，则只有node2中的一部分数据会迁移到node5；如果去掉node2，则原node2中的数据只会迁移到node4中，只有node4会受影响。

一致性哈希分区的主要问题在于，当节点数量较少时，增加或删减节点，对单个节点的影响可能很大，造成数据的严重不平衡。还是以上图为例，如果去掉node2，node4中的数据由总数据的1/4左右变为1/2左右，与其他节点相比负载过高。

（3）带虚拟节点的一致性哈希分区

该方案在一致性哈希分区的基础上，引入了虚拟节点的概念。Redis**集群使用的便是该方案，其中的虚拟节点称为槽（slot）。**槽是介于数据和实际节点之间的虚拟概念；每个实际节点包含一定数量的槽，每个槽包含哈希值在一定范围内的数据。引入槽以后，数据的映射关系由数据hash->实际节点，变成了数据hash->槽->实际节点。

在使用了槽的一致性哈希分区中，槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点之间的关系，增加或删除节点对系统的影响很小。仍以上图为例，系统中有4个实际节点，假设为其分配16个槽(0-15)；槽0-3位于node1，4-7位于node2，以此类推。如果此时删除node2，只需要将槽4-7重新分配即可，例如槽4-5分配给node1，槽6分配给node3，槽7分配给node4；可以看出删除node2后，数据在其他节点的分布仍然较为均衡。

槽的数量一般远小于2^32，远大于实际节点的数量；在Redis集群中，槽的数量为16384。

下面这张图很好的总结了Redis集群将数据映射到实际节点的过程：

图片修改自：三张图秒懂Redis集群设计原理_咖啡男孩之SRE之路-CSDN博客_redis 设计原理

（1）Redis对数据的特征值（一般是key）计算哈希值，使用的算法是CRC16。

（2）根据哈希值，计算数据属于哪个槽。

（3）根据槽与节点的映射关系，计算数据属于哪个节点。

节点通信机制

集群要作为一个整体工作，离不开节点之间的通信。

两个端口

在哨兵系统中，节点分为数据节点和哨兵节点：前者存储数据，后者实现额外的控制功能。在集群中，没有数据节点与非数据节点之分：所有的节点都存储数据，也都参与集群状态的维护。为此，集群中的每个节点，都提供了两个TCP端口：

普通端口：即我们在前面指定的端口(7000等)。普通端口主要用于为客户端提供服务（与单机节点类似）；但在节点间数据迁移时也会使用。
集群端口：端口号是普通端口+10000（10000是固定值，无法改变），如7000节点的集群端口为17000。集群端口只用于节点之间的通信，如搭建集群、增减节点、故障转移等操作时节点间的通信；不要使用客户端连接集群接口。为了保证集群可以正常工作，在配置防火墙时，要同时开启普通端口和集群端口。

Gossip协议

节点间通信，按照通信协议可以分为几种类型：单对单、广播、Gossip协议等。重点是广播和Gossip的对比。

广播是指向集群内所有节点发送消息；优点是集群的收敛速度快(集群收敛是指集群内所有节点获得的集群信息是一致的)，缺点是每条消息都要发送给所有节点，CPU、带宽等消耗较大。

Gossip协议的特点是：在节点数量有限的网络中，每个节点都“随机”的与部分节点通信（并不是真正的随机，而是根据特定的规则选择通信的节点），经过一番杂乱无章的通信，每个节点的状态很快会达到一致。Gossip协议的优点有负载(比广播)低、去中心化、容错性高(因为通信有冗余)等；缺点主要是集群的收敛速度慢。

消息类型

集群中的节点采用固定频率（每秒10次）的定时任务进行通信相关的工作：判断是否需要发送消息及消息类型、确定接收节点、发送消息等。如果集群状态发生了变化，如增减节点、槽状态变更，通过节点间的通信，所有节点会很快得知整个集群的状态，使集群收敛。

节点间发送的消息主要分为5种：meet消息、ping消息、pong消息、fail消息、publish消息。不同的消息类型，通信协议、发送的频率和时机、接收节点的选择等是不同的。

MEET消息：在节点握手阶段，当节点收到客户端的CLUSTER MEET命令时，会向新加入的节点发送MEET消息，请求新节点加入到当前集群；新节点收到MEET消息后会回复一个PONG消息。
PING消息：集群里每个节点每秒钟会选择部分节点发送PING消息，接收者收到消息后会回复一个PONG消息。PING消息的内容是自身节点和部分其他节点的状态信息；作用是彼此交换信息，以及检测节点是否在线。PING消息使用Gossip协议发送，接收节点的选择兼顾了收敛速度和带宽成本，具体规则如下：(1)随机找5个节点，在其中选择最久没有通信的1个节点(2)扫描节点列表，选择最近一次收到PONG消息时间大于cluster_node_timeout/2的所有节点，防止这些节点长时间未更新。
PONG消息：PONG消息封装了自身状态数据。可以分为两种：第一种是在接到MEET/PING消息后回复的PONG消息；第二种是指节点向集群广播PONG消息，这样其他节点可以获知该节点的最新信息，例如故障恢复后新的主节点会广播PONG消息。
FAIL消息：当一个主节点判断另一个主节点进入FAIL状态时，会向集群广播这一FAIL消息；接收节点会将这一FAIL消息保存起来，便于后续的判断。
PUBLISH消息：节点收到PUBLISH命令后，会先执行该命令，然后向集群广播这一消息，接收节点也会执行该PUBLISH命令。

数据结构

节点需要专门的数据结构来存储集群的状态。所谓集群的状态，是一个比较大的概念，包括：集群是否处于上线状态、集群中有哪些节点、节点是否可达、节点的主从状态、槽的分布……

节点为了存储集群状态而提供的数据结构中，最关键的是clusterNode和clusterState结构：前者记录了一个节点的状态，后者记录了集群作为一个整体的状态。

clusterNode

clusterNode结构保存了一个节点的当前状态，包括创建时间、节点id、ip和端口号等。每个节点都会用一个clusterNode结构记录自己的状态，并为集群内所有其他节点都创建一个clusterNode结构来记录节点状态。

下面列举了clusterNode的部分字段，并说明了字段的含义和作用：

typedef struct clusterNode {
    //节点创建时间
    mstime_t ctime;
 
    //节点id
    char name[REDIS_CLUSTER_NAMELEN];
 
    //节点的ip和端口号
    char ip[REDIS_IP_STR_LEN];
    int port;
 
    //节点标识：整型，每个bit都代表了不同状态，如节点的主从状态、是否在线、是否在握手等
    int flags;
 
    //配置纪元：故障转移时起作用，类似于哨兵的配置纪元
    uint64_t configEpoch;
 
    //槽在该节点中的分布：占用16384/8个字节，16384个比特；每个比特对应一个槽：比特值为1，则该比特对应的槽在节点中；比特值为0，则该比特对应的槽不在节点中
    unsigned char slots[16384/8];
 
    //节点中槽的数量
    int numslots;
 
    …………
 
} clusterNode;

除了上述字段，clusterNode还包含节点连接、主从复制、故障发现和转移需要的信息等。

clusterState

clusterState结构保存了在当前节点视角下，集群所处的状态。主要字段包括：

typedef struct clusterState {
 
    //自身节点
    clusterNode *myself;
 
    //配置纪元
    uint64_t currentEpoch;
 
    //集群状态：在线还是下线
    int state;
 
    //集群中至少包含一个槽的节点数量
    int size;
 
    //哈希表，节点名称->clusterNode节点指针
    dict *nodes;
  
    //槽分布信息：数组的每个元素都是一个指向clusterNode结构的指针；如果槽还没有分配给任何节点，则为NULL
    clusterNode *slots[16384];
 
    …………
     
} clusterState;

除此之外，clusterState还包括故障转移、槽迁移等需要的信息。

集群命令的实现

这一部分将以cluster meet(节点握手)、cluster addslots(槽分配)为例，说明节点是如何利用上述数据结构和通信机制实现集群命令的。

cluster meet

假设要向A节点发送cluster meet命令，将B节点加入到A所在的集群，则A节点收到命令后，执行的操作如下：

\1) A为B创建一个clusterNode结构，并将其添加到clusterState的nodes字典中

\2) A向B发送MEET消息

\3) B收到MEET消息后，会为A创建一个clusterNode结构，并将其添加到clusterState的nodes字典中

\4) B回复A一个PONG消息

\5) A收到B的PONG消息后，便知道B已经成功接收自己的MEET消息

\6) 然后，A向B返回一个PING消息

\7) B收到A的PING消息后，便知道A已经成功接收自己的PONG消息，握手完成

\8) 之后，A通过Gossip协议将B的信息广播给集群内其他节点，其他节点也会与B握手；一段时间后，集群收敛，B成为集群内的一个普通节点

通过上述过程可以发现，集群中两个节点的握手过程与TCP类似，都是三次握手：A向B发送MEET；B向A发送PONG；A向B发送PING。

cluster addslots

集群中槽的分配信息，存储在clusterNode的slots数组和clusterState的slots数组中，两个数组的结构前面已做介绍；二者的区别在于：前者存储的是该节点中分配了哪些槽，后者存储的是集群中所有槽分别分布在哪个节点。

cluster addslots命令接收一个槽或多个槽作为参数，例如在A节点上执行cluster addslots {0..10}命令，是将编号为0-10的槽分配给A节点，具体执行过程如下：

\1) 遍历输入槽，检查它们是否都没有分配，如果有一个槽已分配，命令执行失败；方法是检查输入槽在clusterState.slots[]中对应的值是否为NULL。

\2) 遍历输入槽，将其分配给节点A；方法是修改clusterNode.slots[]中对应的比特为1，以及clusterState.slots[]中对应的指针指向A节点

\3) A节点执行完成后，通过节点通信机制通知其他节点，所有节点都会知道0-10的槽分配给了A节点

客户端访问集群

在集群中，数据分布在不同的节点中，客户端通过某节点访问数据时，数据可能不在该节点中；下面介绍集群是如何处理这个问题的。

redis-cli

当节点收到redis-cli发来的命令(如set/get)时，过程如下：

（1）计算key属于哪个槽：CRC16(key) & 16383

集群提供的cluster keyslot命令也是使用上述公式实现，如：

（2）判断key所在的槽是否在当前节点：假设key位于第i个槽，clusterState.slots[i]则指向了槽所在的节点，如果clusterState.slots[i]==clusterState.myself，说明槽在当前节点，可以直接在当前节点执行命令；否则，说明槽不在当前节点，则查询槽所在节点的地址(clusterState.slots[i].ip/port)，并将其包装到MOVED错误中返回给redis-cli。

（3）redis-cli收到MOVED错误后，根据返回的ip和port重新发送请求。

下面的例子展示了redis-cli和集群的互动过程：在7000节点中操作key1，但key1所在的槽9189在节点7001中，因此节点返回MOVED错误(包含7001节点的ip和port)给redis-cli，redis-cli重新向7001发起请求。

上例中，redis-cli通过-c指定了集群模式，如果没有指定，redis-cli无法处理MOVED错误：

Smart客户端

redis-cli这一类客户端称为Dummy客户端，因为它们在执行命令前不知道数据在哪个节点，需要借助MOVED错误重新定向。与Dummy客户端相对应的是Smart客户端。

Smart客户端（以Java的JedisCluster为例）的基本原理：

（1）JedisCluster初始化时，在内部维护slot->node的缓存，方法是连接任一节点，执行cluster slots命令，该命令返回如下所示：

（2）此外，JedisCluster为每个节点创建连接池(即JedisPool)。

（3）当执行命令时，JedisCluster根据key->slot->node选择需要连接的节点，发送命令。如果成功，则命令执行完毕。如果执行失败，则会随机选择其他节点进行重试，并在出现MOVED错误时，使用cluster slots重新同步slot->node的映射关系。

下面代码演示了如何使用JedisCluster访问集群(未考虑资源释放、异常处理等)：

public static void test() {
   Set<HostAndPort> nodes = new HashSet<>();
   nodes.add(new HostAndPort("192.168.72.128", 7000));
   nodes.add(new HostAndPort("192.168.72.128", 7001));
   nodes.add(new HostAndPort("192.168.72.128", 7002));
   nodes.add(new HostAndPort("192.168.72.128", 8000));
   nodes.add(new HostAndPort("192.168.72.128", 8001));
   nodes.add(new HostAndPort("192.168.72.128", 8002));
   JedisCluster cluster = new JedisCluster(nodes);
   System.out.println(cluster.get("key1"));
   cluster.close();
}

注意事项如下：

（1）JedisCluster中已经包含所有节点的连接池，因此JedisCluster要使用单例。

（2）客户端维护了slot->node映射关系以及为每个节点创建了连接池，当节点数量较多时，应注意客户端内存资源和连接资源的消耗。

（3）Jedis较新版本针对JedisCluster做了一些性能方面的优化，如cluster slots缓存更新和锁阻塞等方面的优化，应尽量使用2.8.2及以上版本的Jedis。

实践须知

集群伸缩

实践中常常需要对集群进行伸缩，如访问量增大时的扩容操作。Redis集群可以在不影响对外服务的情况下实现伸缩；伸缩的核心是槽迁移：修改槽与节点的对应关系，实现槽**(即数据)在节点之间的移动。**例如，如果槽均匀分布在集群的3个节点中，此时增加一个节点，则需要从3个节点中分别拿出一部分槽给新节点，从而实现槽在4个节点中的均匀分布。

增加节点

假设要增加7003和8003节点，其中8003是7003的从节点；步骤如下：

（1）启动节点：方法参见集群搭建

（2）节点握手：可以使用cluster meet命令，但在生产环境中建议使用redis-trib.rb的add-node工具，其原理也是cluster meet，但它会先检查新节点是否已加入其它集群或者存在数据，避免加入到集群后带来混乱。

redis-trib.rb add-node 192.168.72.128:7003 192.168.72.128 7000
redis-trib.rb add-node 192.168.72.128:8003 192.168.72.128 7000

（3）迁移槽：推荐使用redis-trib.rb的reshard工具实现。reshard自动化程度很高，只需要输入redis-trib.rb reshard ip:port (ip和port可以是集群中的任一节点)，然后按照提示输入以下信息，槽迁移会自动完成：

待迁移的槽数量：16384个槽均分给4个节点，每个节点4096个槽，因此待迁移槽数量为4096
目标节点id：7003节点的id
源节点的id：7000/7001/7002节点的id

（4）指定主从关系：方法参见集群搭建

减少节点

假设要下线7000/8000节点，可以分为两步：

（1）迁移槽：使用reshard将7000节点中的槽均匀迁移到7001/7002/7003节点

（2）下线节点：使用redis-trib.rb del-node工具；应先下线从节点再下线主节点，因为若主节点先下线，从节点会被指向其他主节点，造成不必要的全量复制。

redis-trib.rb del-node 192.168.72.128:7001 {节点8000的id}
redis-trib.rb del-node 192.168.72.128:7001 {节点7000的id}

ASK错误

集群伸缩的核心是槽迁移。在槽迁移过程中，如果客户端向源节点发送命令，源节点执行流程如下：

图片来源：《Redis设计与实现》

客户端收到ASK错误后，从中读取目标节点的地址信息，并向目标节点重新发送请求，就像收到MOVED错误时一样。但是二者有很大区别：ASK错误说明数据正在迁移，不知道何时迁移完成，因此重定向是临时的，SMART客户端不会刷新slots缓存；MOVED错误重定向则是(相对)永久的，SMART客户端会刷新slots缓存。

故障转移

在哨兵一文中，介绍了哨兵实现故障发现和故障转移的原理。虽然细节上有很大不同，但集群的实现与哨兵思路类似：通过定时任务发送PING消息检测其他节点状态；节点下线分为主观下线和客观下线；客观下线后选取从节点进行故障转移。

与哨兵一样，集群只实现了主节点的故障转移；从节点故障时只会被下线，不会进行故障转移。因此，使用集群时，应谨慎使用读写分离技术，因为从节点故障会导致读服务不可用，可用性变差。

这里不再详细介绍故障转移的细节，只对重要事项进行说明：

节点数量：在故障转移阶段，需要由主节点投票选出哪个从节点成为新的主节点；从节点选举胜出需要的票数为N/2+1；其中N为主节点数量(包括故障主节点)，但故障主节点实际上不能投票。因此为了能够在故障发生时顺利选出从节点，集群中至少需要3个主节点(且部署在不同的物理机上)。

故障转移时间：从主节点故障发生到完成转移，所需要的时间主要消耗在主观下线识别、主观下线传播、选举延迟等几个环节；具体时间与参数cluster-node-timeout有关，一般来说：

故障转移时间(毫秒) ≤ 1.5 * cluster-node-timeout + 1000

cluster-node-timeout的默认值为15000ms(15s)，因此故障转移时间会在20s量级。

集群的限制及应对方法

由于集群中的数据分布在不同节点中，导致一些功能受限，包括：

（1）key批量操作受限：例如mget、mset操作，只有当操作的key都位于一个槽时，才能进行。针对该问题，一种思路是在客户端记录槽与key的信息，每次针对特定槽执行mget/mset；另外一种思路是使用Hash Tag，将在下一小节介绍。

（2）keys/flushall等操作：keys/flushall等操作可以在任一节点执行，但是结果只针对当前节点，例如keys操作只返回当前节点的所有键。针对该问题，可以在客户端使用cluster nodes获取所有节点信息，并对其中的所有主节点执行keys/flushall等操作。

（3）事务/Lua脚本：集群支持事务及Lua脚本，但前提条件是所涉及的key必须在同一个节点。Hash Tag可以解决该问题。

（4）数据库：单机Redis节点可以支持16个数据库，集群模式下只支持一个，即db0。

（5）复制结构：只支持一层复制结构，不支持嵌套。

Hash Tag

Hash Tag原理是：当一个key包含 {} 的时候，不对整个key做hash，而仅对 {} 包括的字符串做hash。

Hash Tag可以让不同的key拥有相同的hash值，从而分配在同一个槽里；这样针对不同key的批量操作(mget/mset等)，以及事务、Lua脚本等都可以支持。不过Hash Tag可能会带来数据分配不均的问题，这时需要：(1)调整不同节点中槽的数量，使数据分布尽量均匀；(2)避免对热点数据使用Hash Tag，导致请求分布不均。

下面是使用Hash Tag的一个例子；通过对product加Hash Tag，可以将所有产品信息放到同一个槽中，便于操作。

参数优化

cluster_node_timeout

cluster_node_timeout参数在前面已经初步介绍；它的默认值是15s，影响包括：

（1）影响PING消息接收节点的选择：值越大对延迟容忍度越高，选择的接收节点越少，可以降低带宽，但会降低收敛速度；应根据带宽情况和应用要求进行调整。

（2）影响故障转移的判定和时间：值越大，越不容易误判，但完成转移消耗时间越长；应根据网络状况和应用要求进行调整。

cluster-require-full-coverage

前面提到，只有当16384个槽全部分配完毕时，集群才能上线。这样做是为了保证集群的完整性，但同时也带来了新的问题：当主节点发生故障而故障转移尚未完成，原主节点中的槽不在任何节点中，此时会集群处于下线状态，无法响应客户端的请求。

cluster-require-full-coverage参数可以改变这一设定：如果设置为no，则当槽没有完全分配时，集群仍可以上线。参数默认值为yes，如果应用对可用性要求较高，可以修改为no，但需要自己保证槽全部分配。

redis-trib.rb

redis-trib.rb提供了众多实用工具：创建集群、增减节点、槽迁移、检查完整性、数据重新平衡等；通过help命令可以查看详细信息。在实践中如果能使用redis-trib.rb工具则尽量使用，不但方便快捷，还可以大大降低出错概率。

脑裂问题

应用实践

分布式锁

Redis分布式锁 - 知乎 (zhihu.com)

SETNX 命令

SET if Not eXists，即如果 key 不存在，才会设置它的值，否则什么也不做。

如何释放锁？

使用 DEL 命令删除这个 key 即可。

如果造成「死锁」怎么解决？

给这个 key 设置一个「过期时间」：

SETNX key 1
EXPIRE key seconds

这个方案也有问题，因为获取锁和设置过期时间分成两步了，不是原子性操作，有可能获取锁成功但设置时间失败，怎么解决？

# 设置键值的同时，设置过期时间，单位秒，如果key已经存在，SETEX命令将覆写旧值。
SETEX key seconds value

# 设置键值的同时，设置过期时间，单位毫秒，如果key已经存在，PSETEX命令将覆写旧值。
PSETEX key milliseconds value

# EX：key在多少秒之后过期
# PX：key在多少毫秒之后过期
# NX：当key不存在的时候，才创建key，效果等同于setnx
# XX：当key存在的时候，覆盖key
SET key value [EX seconds|PX milliseconds] [NX|XX]

试想这样一种场景：

客户端 1 加锁成功，开始操作共享资源
客户端 1 操作共享资源的时间，「超过」了锁的过期时间，锁被「自动释放」
客户端 2 加锁成功，开始操作共享资源
客户端 1 操作共享资源完成，释放锁（但释放的是客户端 2 的锁）

看到了么，这里存在两个严重的问题：

锁过期：客户端 1 操作共享资源耗时太久，导致锁被自动释放，之后被客户端 2 持有
释放别人的锁：客户端 1 操作共享资源完成后，却又释放了客户端 2 的锁

第一个问题，可能是我们评估操作共享资源的时间不准确导致的。

例如，操作共享资源的时间「最慢」可能需要 15s，而我们却只设置了 10s 过期，那这就存在锁提前过期的风险。过期时间太短，那增大冗余时间，例如设置过期时间为 20s，这样总可以了吧？这样确实可以「缓解」这个问题，降低出问题的概率，但依旧无法「彻底解决」问题。

锁过期时间不好评估怎么办？

加锁时，先设置一个过期时间，然后我们开启一个「守护线程」，定时去检测这个锁的失效时间，如果锁快要过期了，操作共享资源还未完成，那么就自动对锁进行「续期」，重新设置过期时间。

Redisson

是一个 Java 语言实现的 Redis SDK 客户端，在使用分布式锁时，它就采用了「自动续期」的方案来避免锁过期，这个守护线程我们一般也把它叫做「看门狗」线程。

第二个问题在于，一个客户端释放了其它客户端持有的锁。

锁被别人释放怎么办?

解决办法是：客户端在加锁时，设置一个只有自己知道的「唯一标识」。

例如，可以是自己的线程 ID，也可以是一个 UUID：

// 锁的VALUE设置为UUID
127.0.0.1:6379> SET lock $uuid EX 20 NX
OK

这里假设 20s 操作共享时间完全足够，先不考虑锁自动过期的问题。

之后，在释放锁时，要先判断这把锁是否还归自己持有，伪代码可以这么写：

// 锁是自己的，才释放
if redis.get("lock") == $uuid:
    redis.del("lock")

这里释放锁使用的是 GET + DEL 两条命令，这时，又会遇到原子性问题。

可以用Lua脚本把两步操作做拼装：

# KEYS[1]是当前key的名称，ARGV[1]可以是当前线程的ID
if redis.call("get",KEYS[1]) == ARGV[1]
then
    return redis.call("del",KEYS[1])
else
    return 0
end

小结

基于 Redis 的实现分布式锁，前面遇到的问题，以及对应的解决方案：

死锁：设置过期时间
过期时间评估不好，锁提前过期：守护线程，自动续期
锁被别人释放：Lua脚本，先检查锁，再释放锁

以上场景都是锁在「单个」Redis 实例中可能产生的问题，并没有涉及到 Redis 的部署架构细节。而我们在使用 Redis 时，一般会采用主从集群 + 哨兵的模式部署，这样做的好处在于，当主库异常宕机时，哨兵可以实现「故障自动切换」，把从库提升为主库，继续提供服务，以此保证可用性。

那当「主从发生切换」时，这个分布锁会依旧安全吗？

试想这样的场景：

客户端 1 在主库上执行 SET 命令，加锁成功
此时，主库异常宕机，SET 命令还未同步到从库上（主从复制是异步的）
从库被哨兵提升为新主库，这个锁在新的主库上，丢失了！

Redlock（红锁）

Redlock 的方案基于 2 个前提：

不再需要部署从库和哨兵实例，只部署主库
但主库要部署多个，官方推荐至少 5 个实例

也就是说，想使用 Redlock，你至少要部署 5 个 Redis 实例，而且都是主库，它们之间没有任何关系，都是一个个孤立的实例。

注意：不是部署 Redis Cluster，就是部署 5 个简单的 Redis 实例。

Redlock 具体如何使用呢？

整体的流程是这样的，一共分为 5 步：

客户端先获取「当前时间戳T1」
客户端依次向这 5 个 Redis 实例发起加锁请求（SET 命令），且每个请求会设置超时时间（毫秒级，要远小于锁的有效时间），如果某一个实例加锁失败（包括网络超时、锁被其它人持有等各种异常情况），就立即向下一个 Redis 实例申请加锁
如果客户端从 >=3 个（大多数）以上 Redis 实例加锁成功，则再次获取「当前时间戳T2」，如果 T2 - T1 < 锁的过期时间，此时，认为客户端加锁成功，否则认为加锁失败
加锁成功，去操作共享资源
加锁失败，向「全部节点」发起释放锁请求（Lua 脚本释放锁）

key有效时长

总结一下，有 4 个重点：

客户端在多个 Redis 实例上申请加锁
必须保证大多数节点加锁成功
大多数节点加锁的总耗时，要小于锁设置的过期时间
释放锁，要向全部节点发起释放锁请求

为什么要在多个实例上加锁？

本质上是为了「容错」，部分实例异常宕机，剩余的实例加锁成功，整个锁服务依旧可用。

为什么大多数加锁成功，才算成功？

多个 Redis 实例一起来用，其实就组成了一个「分布式系统」。

如果存在「故障」节点，只要大多数节点正常，那么整个系统依旧是可以提供正确服务的。

为什么步骤 3 加锁成功后，还要计算加锁的累计耗时？

因为操作的是多个节点，所以耗时肯定会比操作单个实例耗时更久，而且，因为是网络请求，网络情况是复杂的，有可能存在延迟、丢包、超时等情况发生，网络请求越多，异常发生的概率就越大。

所以，即使大多数节点加锁成功，但如果加锁的累计耗时已经「超过」了锁的过期时间，那此时有些实例上的锁可能已经失效了，这个锁就没有意义了。

为什么释放锁，要操作所有节点？

在某一个 Redis 节点加锁时，可能因为「网络原因」导致加锁失败。

例如，客户端在一个 Redis 实例上加锁成功，但在读取响应结果时，网络问题导致读取失败，那这把锁其实已经在 Redis 上加锁成功了。

所以，释放锁时，不管之前有没有加锁成功，需要释放「所有节点」的锁，以保证清理节点上「残留」的锁。

大佬的理解

eids分布式锁其实是靠SETNX这个命令来实现的，即如果 key 不存在，才会设置它的值，否则什么也不做。不过这个命令可能会造成死锁，所以这个时候可以用setex命令来设置一个过期时间，且这个命令是原子性的。

不过，这里会存在两个严重的问题：一个是业务还没处理完锁就过期了，一个是还可能释放别人的锁。

第一个问题，加锁时，先设置一个过期时间，然后我们开启一个「守护线程」，定时去检测这个锁的失效时间，如果锁快要过期了，操作共享资源还未完成，那么就自动对锁进行「续期」，重新设置过期时间。Redisson里就采用了「自动续期」的方案来避免锁过期，这个守护线程我们一般也把它叫做「看门狗」线程。
第二个问题，可以在客户端在加锁时，设置一个只有自己知道的「唯一标识」。可以是自己的线程 ID，也可以是一个 UUID。然后解锁的时候用Lua脚本，先判断锁是不是当前线程，再解锁。

我们项目里的应用主要是在提交单据时，和单据进行审批时，进行加锁。我们有个云审部门专门负责审批流，单据每进行一次审批，云审部门都会生产一个回调方法，我们进行消费。这里因为网络波动的原因云审系统可能会重试或者是业务需求有个联岗审批同时审批两次单据，这些情况下会生产两个回调方法，就是消息重复发生。所以我们这边用锁限制住了。

这个锁最大的缺点就是它加锁时只作用在一个Redis节点上，即使Redis通过sentinel保证高可用，如果这个master节点由于某些原因发生了主从切换，那么就会出现锁丢失的情况。加锁的key还没有同步到slave节点。这种情况出现的很少，所以我们的业务可以接受，如果业务不能接受，可以考虑redlock红锁。

redlock就是部署N个完全独立、没有主从关系的Redis master节点。

客户端先获取「当前时间戳T1」
客户端依次向这 5 个 Redis 实例发起加锁请求（SET 命令），且每个请求会设置超时时间（毫秒级，要远小于锁的有效时间），如果某一个实例加锁失败（包括网络超时、锁被其它人持有等各种异常情况），就立即向下一个 Redis 实例申请加锁
如果客户端从 >=3 个（大多数）以上 Redis 实例加锁成功，则再次获取「当前时间戳T2」，如果 T2 - T1 < 锁的过期时间，此时，认为客户端加锁成功，否则认为加锁失败
加锁成功，去操作共享资源
加锁失败，向「全部节点」发起释放锁请求（Lua 脚本释放锁）

多级缓存

redis多级缓存 - 掘金 (juejin.cn)

布隆过滤器

布隆过滤器，这一篇给你讲的明明白白-阿里云开发者社区 (aliyun.com)

什么是 BloomFilter

布隆过滤器（英语：Bloom Filter）是 1970 年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。主要用于判断一个元素是否在一个集合中。

通常我们会遇到很多要判断一个元素是否在某个集合中的业务场景，一般想到的是将集合中所有元素保存起来，然后通过比较确定。链表、树、散列表（又叫哈希表，Hash table）等等数据结构都是这种思路。但是随着集合中元素的增加，我们需要的存储空间也会呈现线性增长，最终达到瓶颈。同时检索速度也越来越慢，上述三种结构的检索时间复杂度分别为$O(n)$，$O(logn)$，$O(1)$。

这个时候，布隆过滤器（Bloom Filter）就应运而生。

布隆过滤器原理

了解布隆过滤器原理之前，先回顾下 Hash 函数原理。

哈希函数

哈希函数的概念是：将任意大小的输入数据转换成特定大小的输出数据的函数，转换后的数据称为哈希值或哈希编码，也叫散列值。下面是一幅示意图：

所有散列函数都有如下基本特性：

如果两个散列值是不相同的（根据同一函数），那么这两个散列值的原始输入也是不相同的。这个特性是散列函数具有确定性的结果，具有这种性质的散列函数称为单向散列函数。
散列函数的输入和输出不是唯一对应关系的，如果两个散列值相同，两个输入值很可能是相同的，但也可能不同，这种情况称为“散列碰撞（collision）”。

但是用 hash表存储大数据量时，空间效率还是很低，当只有一个 hash 函数时，还很容易发生哈希碰撞。

布隆过滤器数据结构

BloomFilter 是由一个固定大小的二进制向量或者位图（bitmap）和一系列映射函数组成的。

在初始状态时，对于长度为 m 的位数组，它的所有位都被置为0，如下图所示：

当有变量被加入集合时，通过 K 个映射函数将这个变量映射成位图中的 K 个点，把它们置为 1（假定有两个变量都通过 3 个映射函数）。

查询某个变量的时候我们只要看看这些点是不是都是 1 就可以大概率知道集合中有没有它了

如果这些点有任何一个 0，则被查询变量一定不在；
如果都是 1，则被查询变量很可能存在

为什么说是可能存在，而不是一定存在呢？那是因为映射函数本身就是散列函数，散列函数是会有碰撞的。

误判率

布隆过滤器的误判是指多个输入经过哈希之后在相同的bit位置1了，这样就无法判断究竟是哪个输入产生的，因此误判的根源在于相同的 bit 位被多次映射且置 1。

这种情况也造成了布隆过滤器的删除问题，因为布隆过滤器的每一个 bit 并不是独占的，很有可能多个元素共享了某一位。如果我们直接删除这一位的话，会影响其他的元素。(比如上图中的第 3 位)

特性

一个元素如果判断结果为存在的时候元素不一定存在，但是判断结果为不存在的时候则一定不存在。
布隆过滤器可以添加元素，但是不能删除元素。因为删掉元素会导致误判率增加。

添加与查询元素步骤

添加元素

将要添加的元素给 k 个哈希函数
得到对应于位数组上的 k 个位置
将这k个位置设为 1

查询元素

将要查询的元素给k个哈希函数
得到对应于位数组上的k个位置
如果k个位置有一个为 0，则肯定不在集合中
如果k个位置全部为 1，则可能在集合中

优点

相比于其它的数据结构，布隆过滤器在空间和时间方面都有巨大的优势。布隆过滤器存储空间和插入/查询时间都是常数 $O(K)$，另外，散列函数相互之间没有关系，方便由硬件并行实现。布隆过滤器不需要存储元素本身，在某些对保密要求非常严格的场合有优势。

布隆过滤器可以表示全集，其它任何数据结构都不能；

缺点

但是布隆过滤器的缺点和优点一样明显。误算率是其中之一。随着存入的元素数量增加，误算率随之增加。但是如果元素数量太少，则使用散列表足矣。

另外，一般情况下不能从布隆过滤器中删除元素。我们很容易想到把位数组变成整数数组，每插入一个元素相应的计数器加 1, 这样删除元素时将计数器减掉就可以了。然而要保证安全地删除元素并非如此简单。首先我们必须保证删除的元素的确在布隆过滤器里面。这一点单凭这个过滤器是无法保证的。另外计数器回绕也会造成问题。

在降低误算率方面，有不少工作，使得出现了很多布隆过滤器的变种。

布隆过滤器使用场景和实例

在程序的世界中，布隆过滤器是程序员的一把利器，利用它可以快速地解决项目中一些比较棘手的问题。

如网页 URL 去重、垃圾邮件识别、大集合中重复元素的判断和缓存穿透等问题。

布隆过滤器的典型应用有：

数据库防止穿库。 Google Bigtable，HBase 和 Cassandra 以及 Postgresql 使用BloomFilter来减少不存在的行或列的磁盘查找。避免代价高昂的磁盘查找会大大提高数据库查询操作的性能。
业务场景中判断用户是否阅读过某视频或文章，比如抖音或头条，当然会导致一定的误判，但不会让用户看到重复的内容。
缓存宕机、缓存击穿场景，一般判断用户是否在缓存中，如果在则直接返回结果，不在则查询db，如果来一波冷数据，会导致缓存大量击穿，造成雪崩效应，这时候可以用布隆过滤器当缓存的索引，只有在布隆过滤器中，才去查询缓存，如果没查询到，则穿透到db。如果不在布隆器中，则直接返回。
WEB拦截器，如果相同请求则拦截，防止重复被攻击。用户第一次请求，将请求参数放入布隆过滤器中，当第二次请求时，先判断请求参数是否被布隆过滤器命中。可以提高缓存命中率。Squid 网页代理缓存服务器在 cache digests 中就使用了布隆过滤器。Google Chrome浏览器使用了布隆过滤器加速安全浏览服务
Venti 文档存储系统也采用布隆过滤器来检测先前存储的数据。
SPIN 模型检测器也使用布隆过滤器在大规模验证问题时跟踪可达状态空间。

代码

Guava 中的 BloomFilter

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>23.0</version>
</dependency>

public class GuavaBloomFilterDemo {

    public static void main(String[] args) {
        //后边两个参数：预计包含的数据量，和允许的误差值
        BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), 100000, 0.01);
        for (int i = 0; i < 100000; i++) {
            bloomFilter.put(i);
        }
        System.out.println(bloomFilter.mightContain(1));
        System.out.println(bloomFilter.mightContain(2));
        System.out.println(bloomFilter.mightContain(3));
        System.out.println(bloomFilter.mightContain(100001));

        //bloomFilter.writeTo();
    }
}

面试题大全

缓存数据一致性

共有五种方案：

先更新数据库，后更新缓存
先更新缓存，后更新数据库
先删除缓存，后更新数据库
先更新数据库，后删除缓存
延时双删
加锁，没有加锁搞不定的事
引入消息队列处理

缓存为啥是删除，而不是更新？

如果是更新，存在分布式事务问题，可能出现修改了缓存，数据库修改失败的情况或者双写顺序混乱的情况。只删除缓存的话，就算数据库修改失败以及顺序错乱，下次查询会直接取数据库的数据，也不会出现脏数据。

方案一：多线程情况下顺序错乱，造成不一致。

方案二：更新缓存失败，更新数据库成功，二者不一致。

方案三：

在这里插入图片描述

原因是，A事务清空了缓存，在没来得及更新数据库的时候，B去查到了旧数据放到了数据库里面，不一致。

方案四：

在这里插入图片描述

这样可以在清楚缓存之后保证一致，但清除缓存之前一直得到的是旧数据。最主要是一旦更新数据库之后，清除缓存之前，线程挂掉，那么数据就会保留之前的旧数据，一样会有不一致的情况。可以在finily中写最后一次删除可以优化此问题。

方案五：

redis缓存为什么要延时双删_第4张图片

大体上思路与后删一致，只是加入了先删和延时，延时双删依旧会存在旧缓存的问题。只是以前会让事务大量返回旧数据，加了先删会让其他书屋去查数据库，将比较而言事务拿到的旧数据更少，但是增大了对数据库的请求。

方案六：加锁影响性能，尽量不要用的好。

方案七：系统耦合性太强，MQ坏了，会影响到Redis，不推荐。

推荐：方案四、方案五，用Finilly来处理删除中间报错的问题，保证删除成功。方案五的不一致更少一点，但是对系统的压力大，方案四则相反。

redis缓存为什么要延时双删 - it610.com

缓存穿透

原因：

缓存和数据库中都没有此数据，导致大量请求落到数据库上，常见与黑客攻击。

方法：

1.前端设置禁止一直请求，验证码。

2.不存在的值返回一个null放到缓存。

2.布隆过滤器，将所有存在的数据Hash到一个足够大的bitmap中。每次请求都要判断，不存在则一定不存在，存在则不一定存在。

缓存雪崩

原因：

缓存在同一时间点大量失效，缓存重启，第一次启动服务，造成大量请求落到数据库上。

方法：

1.缓存过期时间错开

2.个人设计的思路，多级缓存+bitmap，即request->redis->guava->mysql。

假设请求量特别大，足以造成雪崩，那么前一分钟的请求量一定也是极大的。每次在redis中存入的数据，在即将过期时（设置前1分钟即可）存入guava，guava有效时间>redis即将过期时间+更新redis时间。用bitmap存储redis过期flag，每个请求首先判断bitmap中key是否过期，一旦过期将将请求二级缓存。

这样一来，在缓存过期的时间内，第一个来的请求发现bitmap中=0，但缓存过期，它只需要CAS的方式去将过期flag由1设置为0，失败则重新回到判断bitmap是否为0。设置成1之后，去数据库中查询新的数据，其余剩下的大量请求都会去访问临时的二级缓存。等一级缓存中的数据被重新插入进去后，二级缓存很快也会过期，程序重新恢复一级缓存运行。

3.缓存预热，参照我之前写的预热注解

4.加互斥锁

缓存击穿

同一时间大量请求一个接口，缓存失效或者初次启动，缓存不存在数据库中存在。

热点数据永不失效，或者在深更半夜更新。

其他解决方案同缓存雪崩2、3、4。

待整理...

(2条消息) Redis面试题（2020最新版）_ThinkWon的博客-CSDN博客_redis面试题

(2条消息) 2021年Redis面试题（持续更新）_GEEK-BANANA-CSDN博客_redis面试题2021

(2条消息) 面试还搞不懂redis，快看看这40道面试题（含答案和思维导图）_程序员追风的博客-CSDN博客

(2条消息) 面了6家大厂，我把问烂了的Redis常见面试题总结了一下（带答案）_敖丙-CSDN博客_redis面试题总结

kabit

关注

2
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
Redis知识汇总

写在前面：1.本文内容并不都是我自己写的，其中部分是我在网上收录的知识点，部分是我自己的观点。2.有些引用的知识点，我会在章节前面加上引用连接，如果没加是真的是我忘记了。3.原作者发现哪里是您的内容，我没有加连接，请联系我，我火速添加链接。4.如有哪里知识缺漏缺漏、错误、图片挂掉请及时私信我，我立即修改。5.知识是免费的，我不过是搬运整理者，取于网络，还于网络。希望大家学习顺利。感谢：♥Redis教程 - Redis知识体系详解♥ | Java 全栈知识体系 (pdai.tech
复制链接

扫一扫