Redis高级思维导图模板_ProcessOn思维导图、流程图

持久化

定义

存储在内存中的数据库数据以文件形式存储到硬盘，并在有需要时根据这些文件的内容实施数据恢复

默认使用AOF模式

RDB快照：snapshotting

save 900 1 900秒内发生一次save 300 10 300秒内发生10次save 60 10000 60秒内发生10000dbfilename dump.rdb 快照名dir ./ 快照路径

手动快照

save

会阻塞用户请求处理的性能

bgsave

后台fork一个进程，非阻塞做持久化操作，不会影响用户请求处理

定义

全量持久化方式，可以创建出经过压缩的时间点二进制快照文件，并通过载入文件中的二进制数据来实施数据恢复

优点

恢复速度快

二进制格式文件体积小

缺点

消耗大量计算资源和内存资源

生成间隔较长，停机时数据丢失量较大

AOF追加：appendonly

appendfsync 冲洗频率

always

执行一个写命令，就对AOF文件执行一次冲洗

everysec

每隔1s，就对AOF文件执行一次冲洗操作，默认

no

不主动对AOF文件执行冲洗操作，由操作系统决定何时对AOF进行冲洗

AOF重写

AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件

触发方式

AOF重写配置

auto‐aof‐rewrite‐min‐size 64mb

至少要达到64M才会自动重写

auto‐aof‐rewrite‐percentage 100

自上一次重写后文件大小增长了100%则再次触发重写

BGREWRITEAOF 命令

显式地触发AOF重写

原理

服务器每次执行完写命令之后，都会以协议文本的方式将被执行的命令追加到AOF文件的末尾，恢复时是重新执行这些命令

缺点

恢复速度慢

数据库体积较大，进行AOF文件重写将占用大量资源，并导致服务器被短暂地阻塞

存储的是协议文本

优点

根据策略决定数据安全性

RDB-AOF混合持久化

aof-use-rdb-preamble yes

Redis混合持久化开关

AOF重写时不在单纯地将内存数据转换为命令存储在AOF中，而是将这一刻之前的数据做RDB快照处理，并且将RDB快照内容和增量的AOF修改数据命令存在一起，都写入新的AOF文件。

优点

通过AOF文件包含的RDB数据来实现快速的数据恢复操作，又可以通过AOF文件包含的AOF数据来将丢失数据的时间窗口限制在1s之内

SHUTDOWN关闭Redis服务器

动作

1、停止处理客户端发送的命令请求

2、根据服务器的持久化配置选项，决定是否执行数据保存操作

3、服务器进程退出

复制

配置

replica-read-only

从服务器默认只读，设置从服务器只读

repl-diskless-sync yes

无须硬盘的复制

min-replicas-to-write N

从服务器至少达到N个才让从服务器执行写操作

min-replicas-max-lag M

从服务器与主服务器最后一次成功通信的间隔低于M秒才向从服务器发送写命令

命令

REPLICAOF host port

设置从服务器

ROLE

查看服务器当前担任的角色

数据同步

完整同步

主服务器存储的写命令都是在执行BGSAVE命令之后执行的，所以当从服务器载入完RDB文件，并执行完主服务器存储在缓冲区中的所有写命令之后，主从服务器包含的数据库数据将完全相同

在线更新

每当主服务器执行完一个写命令之后，它就会将相同的写命令或者具有相同效果的写命令发送给从服务器执行

部分同步

当一个Redis服务器成为另一个服务器的主服务器时，它会把每个被执行的写命令都记录到一个特定长度的先进先出队列中。从服务器重新连接主服务器检测缺失命令在队列中，就执行缺失的命令。

repl-backlog-size

队列默认1M

优点

提升读性能

（一写多读）

安全性

增加从服务器的数量，可以降低系统在遭遇灾难故障时丢失数据的可能性

可用性

同时使用Redis的复制功能和Sentinel功能，在主服务器停机时，将会自动挑选一个从服务器作为新的主服务器，以此来继续为客户提供服务，避免造成整个系统停机

哨兵 sentinel

说明

使用正常服务器替换下线服务器以维持系统正常运转的操作，一般被称为故障转移

Sentinel可以通过心跳检测的方式监视多个主服务器以及它们属下的所有从服务器，并在某个主服务器下线时自动对其实施故障转移。

开3个Sentinel或者说开奇数个，Sentinel的原理就是一直监视着master是否在线，如果挂掉，sentinel的集群会选举中一个领头的sentinel，然后由领头的sentinel 执行slaveof命令，让slave作为master，然后sentinel集群继续监视着新的master，老的master还是会一直监控着，如果启动了，那么老的master会作为新master的slave。

sentinel判断master下线的两种标准

主观下线：sentinel发现master没有在指定时间返回信息，这种情况被认为主线下线。

客观下线：sentinel询问sentinel的集群，看一下其他的sentinel是否也标记这master是否下线，如果标记sentinel下线的个数达到一个阀值，sentinel会将master标记为客观下线，这个时候能会选取领头的sentinel。由领头的sentinel选取master下面的一个slave去作为新的master。

投票机制

因为Sentinel网络使用客观下线机制来判断一个主服务器是否真的已经下线了，所以为了让这种机制能够有效地运作，用户需要将quorum参数的值设置为Sentinel数量的半数以上，从而形成一种少数服从多数的投票机制。

命令

sentinel monitor <master-name> <ip> <port> <quorum>

监视的主服务器的ip地址，以及sentinel标记客观下线的阀值

SENTINEL masters

获取所有被监视主服务器的信息

SENTINEL remove <master-name>

取消对给定主服务器的监视

SENTINEL slaves

获取被监视主服务器的从服务器信息

SENTINEL sentinels

获取其他Sentinel的相关信息

SENTINEL reset <pattern>

重置主服务器状态

SENTINEL failover <master-name>

SENTINEL ckquorum

检查可用Sentinel的数量

集群cluster

简介

redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。

分片

Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位，槽位的信息存储于每个节点中。

Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。HASH_SLOT = CRC16(key) mod 16384

当客户端向一个错误的节点发出了指令，该节点会发现指令的 key 所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。客户端收到指令后除了跳转到正确的节点上去操作，还会同步更新纠正本地的槽位映射表缓存，后续所有 key 将使用新的槽位映射表。

集群中的每个节点都有 1 个至 N 个replica，其中一个结点为主节点（master），而其余的 N-1 个结点为从节点（slave），主节点宕机后其他服务器会选举出其中一个slave为新的主节点，否正整个集群将停止运作，因为没有对应的服务器承接相应的哈希槽

Redis集群选举原理

1.slave发现自己的master变为FAIL

2.将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST 信息

3.其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack

4.尝试failover的slave收集master返回的FAILOVER_AUTH_ACK

5.slave收到超过半数master的ack后变成新Master

从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟•延迟计算公式:DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms•SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下，持有最新数据的slave将会首先发起选举

Redis 集群不保证数据的强一致性

集群管理工具

redis-cli --cluster help

查询帮助

redis-cli --cluster create <ip1>:<port1> ... <ipN>:<portN>

创建集群给出各个节点的IP地址和端口号

redis-cli --cluster info <ip>:<port>

查看集群信息

redis-cli --cluster check <ip>:<port>

检查集群

redis-cli --cluster fix <ip>:<port>

修复槽错误

redis-cli --cluster rebalance <ip>:<port>

负载均衡

redis-cli --cluster add-node <new_host>:<port> <existing_host>:<port>

添加节点

redis-cli --cluster del-node <ip>:<port> <node_id>

移除节点

redis-cli --cluster set-timeout <host>:<port> <milliseconds>

设置超时时间

数据备份与恢复

备份

BGSAVE

在后台异步保存当前数据库的数据到磁盘

SAVE

同步保存数据到硬盘

恢复

获取 redis 目录

CONFIG GET dir

将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务

安全

redis默认没有密码，可以通过requirepass设置密码

设置redis.conf文件中的requirepass pass 设置密码

获取密码：CONFIG get requirepass

设置密码：CONFIG set requirepass pass

redis设置密码时

redis可以连接，但是不能操作需要输入密码

AUTH password

连接时输入密码

./redis-cli 127.0.0.1 -p 6379 -a pass

管道技术

说明

在服务端未响应时，客户端可以继续向服务端发送请求，并最终一次性读取所有服务端的响应

优势

提高了 redis 服务的性能

数据类型

Bitmaps位图

基本命令

GETBIT bitmap offset

获取位图指定索引的值

SETBIT bitmap offset value

设置二进制位的值，返回该索引位置的原始值

BITCOUNT bitmap [start end]

获取位图指定范围（start到end，单位为字节，如果不指定就是获取全部）位值为1的个数

BITOP and|or|not|xor destkey key [key...]

多个bitmap的and、or、not、xor操作并将结果保存到destkey中

BITPOS key targetBit [start] [end]

计算位图指定范围第一个偏移量对应的值等于targetBit的位置

应用场景

独立用户访问统计，用户行为记录

setbit key offset value

bitcount key [start end]

GEO（地理位置信息）

基本命令

GEOADD location_set longitude latitude name [longitude latitude name ...]

添加地理位置的坐标

GEOPOS location_set name [name ...]

获取地理位置的坐标

GEODIST location_set name1 name2 [unit]

计算两个位置之间的距离

GEORADIUS location_set longitude latitude radius unit

根据用户给定的经纬度坐标来获取指定范围内的地理位置集合

GEORADIUSBYMEMBER location_set name radius unit [WITHDIST] [WITHCOORD] [ASC|DESC] [COUNT n]

根据储存在位置集合里面的某个地点获取指定范围内的地理位置集合

GEOHASH

获取指定位置的Geohash值

使用场景

获取附近的人

GEORADIUS location_set longitude latitude radius unit

GEORADIUSBYMEMBER location_set name radius unit [WITHDIST] [WITHCOORD] [ASC|DESC] [COUNT n]

计算用户直线距离

GEODIST location_set name1 name2 [unit]

GEOADD location_set longitude latitude name [longitude latitude name ...]

GEOPOS location_set name [name ...]

Stream

基本命令

消息队列相关

XADD stream id field value [field value ...]

添加消息到末尾

XTRIM stream MAXLEN len

对流进行修剪，限制长度

XDEL stream [id id ... id]

删除消息

XLEN stream

获取流包含的元素数量，即消息长度

XRANGE stream start-id end-id [COUNT n]

获取消息列表，会自动过滤已经删除的消息

XREVRANGE

反向获取消息列表，ID 从大到小

XREAD [BLOCK ms] [COUNT n] STREAMS stream1 stream2 stream3 ... id1 id2 id3 ...

以阻塞或非阻塞方式获取消息列表

消费者组相关

XGROUP CREATE stream group start_id

创建消费者组

XREADGROUP GROUP group consumer [COUNT n] [BLOCK ms] STREAMS stream [stream ...] id [id ...]

读取消费者组中的消息

XACK stream group id [id id ...]

将消息标记为"已处理"

XGROUP SETID

为消费者组设置新的最后递送消息ID

XGROUP DELCONSUMER

删除消费者

XGROUP DESTROY

删除消费者组

XPENDING stream group [start stop count] [consumer]

显示待处理消息的相关信息

XCLAIM stream group new_consumer max_pending_time id [id id ...]

转移消息的归属权

XINFO CONSUMERS stream group-name

查看流和消费者组的相关信息

XINFO GROUPS

打印消费者组的信息

XINFO STREAM

打印流信息

使用场景

消息队列

XADD stream id field value [field value ...]

XREAD [BLOCK ms] [COUNT n] STREAMS stream1 stream2 stream3 ... id1 id2 id3 ...

布隆过滤器

介绍

组成可以当作一个位数组和几个无偏的 hash 函数（计算的 hash 比较均匀），每次添加 key 的时候，会把 key 通过多次 hash 来计算所的到的位置，如果当前位置不是 0 则表示存在，这也正式它的不准确性。

特点

巧妙的使用hash算法和bitmap位存储的方式，极大的节约了空间

判断

由于主要用的是hash算法的特点，所有满足和hash算法相同的规则：当过滤器返回 true时（表示很有可能该值是存在的），有一定概率是误判的，即可能不存在；当过滤器返回false时（表示确定不存在），是可以完全相信的

插件

https://github.com/RedisBloom/RedisBloom

缺点

有一定的误识别率

删除困难