入门

Redis是一种基于Key-Value键值对的在内存数据库。

版本号第二位是奇数则是非稳定版本，偶数则为稳定版本。

常用命令

十大数据类型

Redis的十大数据类型：字符串、哈希表、集合、有序集合、地理空间、基数统计、位图、位域和流。

此处的数据类型指的是Value的数据类型，key的数据类型都是字符串。

Redis字符串(String)，String类型是Redis最基本的数据类型。

Redis列表的底层是双端链表，可以在头部或尾部操作。

Redis的zset和set一样也是string类型元素的集合，且不允许重复的成员。不同的是每个元素都会关联一个double类型的分数，redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的，但分数(score)却可以重复。

命令是不区分大小写的，但是key区分大小写。

为key设置过期时间后，再更改Value的值会默认将过期时间设置为永不过期，可以使用keepttl保留设置前指定键的生存时间。

基数统计用于统计独立访客，而不是访问次数，进行去重。基数统计只会根据输入元素来计算基数，而不会存储输入元素本身。

redis中的流就是redis版本的消息中间件(MQ)。

stream中的消息一旦被消费组里的一个消费者读取了，就不能再被该消费组内的其他消费者读取了，即同一个消费组里的消费者不能消费同一条消息。但不同消费组的消费者可以消费同一条消息。

持久化

可以使用AOF+RDB混合模式来做数据持久化，会以AOF为主，在同时开启RDB和AOF持久化时，重启只会加载AOF文件，不会加载RDB文件。

在AOF+RDB混合模式下，RDB镜像做全量持久化，AOF做增量持久化。

RDB

RDB(Redis Database)：RDB持久性以指定的时间间隔执行数据集的时间点快照。

redis7相对于redis6，RDB的时间频率有了巨大的变化。

执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义。关机(shutdown)时也会生成快照以保证数据一致。因此我们需要手动修改快照的名称，以免被覆盖。

Redis提供了save和bgsave两个命令，实际应用中一般只使用bgsave。因为save在主程序中执行会阻塞当前redis服务器，直到特久化工作完成。执行save命令期间，Redis不能处理其他命令。

RDB优点是适合大规模的数据恢复，且RDB文件在内存中的加载速度要比AOF快得多。

RDB的缺点是快照之后数据可能会丢失，且RDB依赖主程序的fork，当数据量大的时候可能会导致服务请求延迟。

AOF

AOF(Append Only File)：以日志的形式来记录每个写操作，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

默认情况下，redis是没有开启AOF的。开启AOF功能需要设置配置：appendonly yes。

AOF会有一个AOF缓存区，会将命令先放入AOF缓存中进行保存，到达一定数量后再写入AOF文件。

随着写入AOF内容的增加，文件内容逐渐增加，为避免文件膨胀，会根据规则进行命令的合并（又称AOF重写），从而起到AOF文件压缩的目的。

AOF的优势是更好的保护数据不丢失、性能高、可做紧急恢复。

AOF的缺点是相同数据集的数据而言AOF文件要远大于RDB文件，恢复速度慢于RDB，运行效率要慢于RDB。

AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。

写回策略

1. Always：同步写回，每个写命令执行完立刻同步地将日志写回磁盘。
2. everysec：每秒写回一次。
3. no：由操作系统控制何时写回。

事务

事务可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其他命令插入。

Redis事务是单独的隔离操作，没有隔离级别的概念，不保证原子性，没有执行到一半进行回滚的能力，拥有排他性。

Redis事务出错时，当输入命令就检测出采用全体都不执行，当运行时异常仅不执行错误命令，其他命令能够正常执行。

管道

管道(pipeline)可以一次性发送多条命令给服务端，服务端依次处理完完毕后，通过一条响应一次性将结果返回，通过减少客户端与Redis的通信次数来实现降低往返延时时间。

管道命令是在Linux处写好一个文本，再使用cat cmd.txt | redis-cli -a 111111 --pipe进行执行的。

管道中一次发送的命令不宜过多，否则服务器会专注于此次发送的管道中的命令，导致无法处理其他命令。

与原生批处理的差异

1. 原生批量命令是原子性（例如：mset,mget)，管道是非原子性。
2. 原生批量命令一次只能执行一种命令，管道支持批量执行不同命令。
3. 原生批命令是服务端实现，而管道需要服务端与客户端共同完成。

复制

主从复制，master以写为主，slave以读为主，当master数据变化的时候，自动将新的数据异步同步到其他的slave数据库。

主从复制用于读写分离、容灾恢复、数据备份和水平扩容支撑高并发。

配从机不配主机，从机需要指定自己的主机。

如果主机有配置密码，则从机需要设置校验密码，否则主机会拒绝从机的访问请求。

从机只能读数据，不能写数据。

从机启动时获取主机的所有数据，后续跟随主机进行修改。

主机shutdown后，从机数据正常使用，等待主机重新开启。

配置文件后持久生效，命令仅当次生效，重启后失效。

从机关闭时会在日志文件中记录offset，当从机启动往主机请求数据时，主机只会把offset以后的数据复制给从机，类似断点续传。

上一个slave可以是下一个slave的master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master，可以有效减轻主master的写压力。值得注意的是这个中间的slave仍然不能写数据。

中途变更转向，会清除之前的数据，重新拷贝最新的。

复制的缺点是复制延时，信号衰减，还要面临主机出现故障应该如何处理的问题。

哨兵

哨兵负责监控后台主机是否故障，如果故障则根据投票数将某一个从机转换为主机，继续对外服务。

哨兵用于主从监控，消息通知、故障处理和配置中心。

由于网络不可靠，部分哨兵可能会因为网络堵塞而误以为主机出现故障，因此我们需要一个哨兵集群互相沟通来确认主机是否真的出现故障，这时就需要哨兵进行投票。

由于在哨兵模式下，主机可能会变成从机，因此主机的配置文件也需要配置masterauth项访问密码。

哨兵的配置文件在启动后会添加更多的信息，例如同一个集群的其他哨兵和主机对应的从机。

在主从机切换的时候，哨兵会动态的修改Redis的配置文件。

当主节点被判断客观下线以后，各个哨兵节点会进行协商先选举出一个领导者哨兵节点并由该节点从从机中选取新的主机。

选举领导者哨兵的算法是Raft算法，基本思路是先到先得，即在一轮选举中，哨兵A向哨兵B发送成为领导者的申请，如果此前哨兵B没有同意过其他哨兵，则会同意哨兵A成为领导者。

从从机中选取主机的步骤：首先优先级最高、其次是最大的offset，即选取版本最新的，最后是最小的Run ID。

哨兵使用建议

1. 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用。
2. 哨兵节点的数量应该是奇数。
3. 各个哨兵节点的配置应一致。
4. 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射。
5. 哨兵集群+主从复制，并不能保证数据零丢失。

集群

由于数据量过大，单个Master复制集难以承担，因此需要对多个复制集进行集群，形成水平扩展。每个复制集只负责存储整个数据集的一部分，这就是Redis的集群，其作用是提供在多个Redis节点间共享数据的程序集。

Redis集群是一个提供在多个Redis节点间共享数据的数据集。

Redis集群支持多个Master,每个Master又可以挂载多个Slave，支持读写分离、支持数据的高可用和支持海量数据的读写存储功能。

客户端与Redis的节点连接，不再需要连接集群中的所有节点，只需要任意连接集群中的一个可用节点即可。

使用Redis集群时，我们会将存储的数据分散到多态Redis机器中，这称为一个分片。

一致性哈希算法的优点是容错性和拓展性，缺点是数据倾斜问题。

集群使用的是哈希槽的分区算法，解决了一致性哈希算法的均匀分配问题。

Redis集群不保证强一致性，这意味着在特定的条件下，Redis集群可能会丢掉一些被系统收到的写入请求命令。

连接集群时需要加上-c，这样才能转发到正确的槽位。如redis-cli -a 1111 -p 6381 -c。

新区间分配的是断开的，因为重新分配的成本太高，前面的各自分一部分出来。

集群分片的最大槽数是16384

1. 如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
2. Redis的集群主节点数量基本不可能超过1000个。
3. 槽位越少，节点越少的情况下，压缩比高，容易传输。

SpringBoot整合Redis

传输数据时需要序列化。