Redis高级
2022-08-19 10:22:45 1 举报AI智能生成
登录查看完整内容
Redis高级特性，持久化，复制，数据备份与恢复，安全，管道技术，数据类型，布隆过滤器，哨兵，集群
作者其他创作
大纲/内容
存储在内存中的数据库数据以文件形式存储到硬盘，并在有需要时根据这些文件的内容实施数据恢复
定义
默认使用AOF模式
save 900 1 900秒内发生一次save 300 10 300秒内发生10次save 60 10000 60秒内发生10000dbfilename dump.rdb 快照名dir ./ 快照路径
会阻塞用户请求处理的性能
save
后台fork一个进程，非阻塞做持久化操作，不会影响用户请求处理
bgsave
手动快照
全量持久化方式，可以创建出经过压缩的时间点二进制快照文件，并通过载入文件中的二进制数据来实施数据恢复
恢复速度快
二进制格式文件体积小
优点
消耗大量计算资源和内存资源
生成间隔较长，停机时数据丢失量较大
缺点
RDB快照：snapshotting
执行一个写命令，就对AOF文件执行一次冲洗
always
每隔1s，就对AOF文件执行一次冲洗操作，默认
everysec
不主动对AOF文件执行冲洗操作，由操作系统决定何时对AOF进行冲洗
no
appendfsync 冲洗频率
AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件
至少要达到64M才会自动重写
auto‐aof‐rewrite‐min‐size 64mb
自上一次重写后文件大小增长了100%则再次触发重写
auto‐aof‐rewrite‐percentage 100
AOF重写配置
显式地触发AOF重写
BGREWRITEAOF 命令
触发方式
AOF重写
服务器每次执行完写命令之后，都会以协议文本的方式将被执行的命令追加到AOF文件的末尾，恢复时是重新执行这些命令
原理
恢复速度慢
数据库体积较大，进行AOF文件重写将占用大量资源，并导致服务器被短暂地阻塞
存储的是协议文本
根据策略决定数据安全性
AOF追加：appendonly
Redis混合持久化开关
aof-use-rdb-preamble yes
AOF重写时不在单纯地将内存数据转换为命令存储在AOF中，而是将这一刻之前的数据做RDB快照处理，并且将RDB快照内容和增量的AOF修改数据命令存在一起，都写入新的AOF文件。
通过AOF文件包含的RDB数据来实现快速的数据恢复操作，又可以通过AOF文件包含的AOF数据来将丢失数据的时间窗口限制在1s之内
RDB-AOF混合持久化
1、停止处理客户端发送的命令请求
2、根据服务器的持久化配置选项，决定是否执行数据保存操作
3、服务器进程退出
动作
SHUTDOWN关闭Redis服务器
持久化
从服务器默认只读，设置从服务器只读
replica-read-only
无须硬盘的复制
repl-diskless-sync yes
从服务器至少达到N个才让从服务器执行写操作
min-replicas-to-write N
从服务器与主服务器最后一次成功通信的间隔低于M秒才向从服务器发送写命令
min-replicas-max-lag M
配置
设置从服务器
REPLICAOF host port
查看服务器当前担任的角色
ROLE
命令
主服务器存储的写命令都是在执行BGSAVE命令之后执行的，所以当从服务器载入完RDB文件，并执行完主服务器存储在缓冲区中的所有写命令之后，主从服务器包含的数据库数据将完全相同
完整同步
每当主服务器执行完一个写命令之后，它就会将相同的写命令或者具有相同效果的写命令发送给从服务器执行
在线更新
队列默认1M
repl-backlog-size
当一个Redis服务器成为另一个服务器的主服务器时，它会把每个被执行的写命令都记录到一个特定长度的先进先出队列中。从服务器重新连接主服务器检测缺失命令在队列中，就执行缺失的命令。
部分同步
数据同步
（一写多读）
提升读性能
增加从服务器的数量，可以降低系统在遭遇灾难故障时丢失数据的可能性
安全性
同时使用Redis的复制功能和Sentinel功能，在主服务器停机时，将会自动挑选一个从服务器作为新的主服务器，以此来继续为客户提供服务，避免造成整个系统停机
可用性
复制
使用正常服务器替换下线服务器以维持系统正常运转的操作，一般被称为故障转移
Sentinel可以通过心跳检测的方式监视多个主服务器以及它们属下的所有从服务器，并在某个主服务器下线时自动对其实施故障转移。
开3个Sentinel或者说开奇数个，Sentinel的原理就是一直监视着master是否在线，如果挂掉，sentinel的集群会选举中一个领头的sentinel，然后由领头的sentinel 执行slaveof命令，让slave作为master，然后sentinel集群继续监视着新的master， 老的master还是会一直监控着，如果启动了，那么老的master会作为新master的slave。
主观下线：sentinel发现master没有在指定时间返回信息，这种情况被认为主线下线。
客观下线：sentinel询问sentinel的集群，看一下其他的sentinel是否也标记这master是否下线，如果标记sentinel下线的个数达到一个阀值，sentinel会将master标记为客观下线，这个时候能会选取领头的sentinel。由领头的sentinel选取master下面的一个slave去作为新的master。
sentinel判断master下线的两种标准
因为Sentinel网络使用客观下线机制来判断一个主服务器是否真的已经下线了，所以为了让这种机制能够有效地运作，用户需要将quorum参数的值设置为Sentinel数量的半数以上，从而形成一种少数服从多数的投票机制。
投票机制
说明
监视的主服务器的ip地址，以及sentinel标记客观下线的阀值
sentinel monitor <master-name> <ip> <port> <quorum>
获取所有被监视主服务器的信息
SENTINEL masters
取消对给定主服务器的监视
SENTINEL remove <master-name>
获取被监视主服务器的从服务器信息
SENTINEL slaves
获取其他Sentinel的相关信息
SENTINEL sentinels
重置主服务器状态
SENTINEL reset <pattern>
SENTINEL failover <master-name>
检查可用Sentinel的数量
SENTINEL ckquorum
哨兵 sentinel
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为新的主节点，否正整个集群将停止运作，因为没有对应的服务器承接相应的哈希槽
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 集群不保证数据的强一致性
简介
查询帮助
redis-cli --cluster help
创建集群给出各个节点的IP地址和端口号
redis-cli --cluster create <ip1>:<port1> ... <ipN>:<portN>
查看集群信息
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>
集群管理工具
集群cluster
在后台异步保存当前数据库的数据到磁盘
BGSAVE
同步保存数据到硬盘
SAVE
备份
CONFIG GET dir
获取 redis 目录
将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务
恢复
数据备份与恢复
设置redis.conf文件中的requirepass pass 设置密码
获取密码：CONFIG get requirepass
设置密码：CONFIG set requirepass pass
redis默认没有密码，可以通过requirepass设置密码
AUTH password
redis可以连接，但是不能操作需要输入密码
./redis-cli 127.0.0.1 -p 6379 -a pass
连接时输入密码
redis设置密码时
安全
在服务端未响应时，客户端可以继续向服务端发送请求，并最终一次性读取所有服务端的响应
提高了 redis 服务的性能
优势
管道技术
获取位图指定索引的值
GETBIT bitmap offset
设置二进制位的值，返回该索引位置的原始值
SETBIT bitmap offset value
获取位图指定范围（start到end，单位为字节，如果不指定就是获取全部）位值为1的个数
BITCOUNT bitmap [start end]
多个bitmap的and、or、not、xor操作并将结果保存到destkey中
BITOP and|or|not|xor destkey key [key...]
计算位图指定范围第一个偏移量对应的值等于targetBit的位置
BITPOS key targetBit [start] [end]
基本命令
setbit key offset value
bitcount key [start end]
独立用户访问统计，用户行为记录
应用场景
Bitmaps位图
添加地理位置的坐标
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
获取附近的人
计算用户直线距离
使用场景
GEO（地理位置信息）
添加消息到末尾
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]
反向获取消息列表，ID 从大到小
XREVRANGE
以阻塞或非阻塞方式获取消息列表
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 ...]
为消费者组设置新的最后递送消息ID
XGROUP SETID
删除消费者
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
消费者组相关
消息队列
Stream
数据类型
组成可以当作一个位数组和几个无偏的 hash 函数（计算的 hash 比较均匀），每次添加 key 的时候，会把 key 通过多次 hash 来计算所的到的位置，如果当前位置不是 0 则表示存在，这也正式它的不准确性。
介绍
巧妙的使用hash算法和bitmap位存储的方式，极大的节约了空间
特点
由于主要用的是hash算法的特点，所有满足和hash算法相同的规则：当过滤器返回 true时（表示很有可能该值是存在的），有一定概率是误判的，即可能不存在；当过滤器返回false时（表示确定不存在），是可以完全相信的
判断
https://github.com/RedisBloom/RedisBloom
插件
有一定的误识别率
删除困难
布隆过滤器
Redis高级
0 条评论
回复 删除
下一页
