Redis学习笔记

Redis的官方网站是https://redis.io/,也有中文的网站 http://www.redis.cn/
Redis 当前的稳定版本是3.2(具体是3.2.9),最新版本是4.0。

在本文你将看到:
1. Redis的基础知识,如redis的数据类型,redis的安装配置,redis的主要参数设置等等。
2. Redis的主从复制,以及Redis的自动主从切换的高可用架构(Sentinel)
3. Redis的集群高可用架构,即Redis Cluster(包含主从自动切换和数据分片)
4. Redis的监控
5. Redis的docker化。
6. Redis 4.0的新特性

一、Redis基础知识

1. redis是一个内存数据库,是key value的方式记录数据。redis是单进程单线程,所以只占用一个cpu,所以在监控时候,多CPU主机的平均使用cpu可能使用率低,但是可能redis进程使用的那个cpu已经打满。
redis的主要操作命令工具是redis-cli,提供交互命令行,类似sqlplus,进行数据的操作。

redis数据类型主要有如下5种:(其他还有bitmap,hyperloglog等等,这里不做讨论)
1.1 string类型:
• set 插入或者修改(注1:不能存相同的字符串;注2:无序,无左右)
• get 获取
• del 删除

应用场景:一般的key-value。注,一个value最大可以容纳512Mb长度的string值。

1.2 list类型
• lpush/rpush 将值插入左端/右端 (注:list可以存储多个相同的串)
• lrange 获取给定范围的列表中的值
• lindex 获取列表中的某个值
• lpop 从左边弹出列表中的一个值(注:pop之后,值就不在列表中了)

注,最多可以包含2^32个元素。

1.3 set类型
• sadd 插入(set通过hash列表保证自己存储的每个字符串是不同的,无序,无左右)
• smember 列出所有member
• sismember 判断是否为member
• srem移除

使用场景:你我的共同朋友,共同爱好等等

1.4 hash类型
• hset 插入
• hget 获取指定hash列
• hgetall 获取所有hash列的所有键值
• hdel 如果给定键存在于hash列里面,则删除这个键。

1.5 zset类型(有序集合)
• zadd
• zrange
• zrangebyscore
• zrem

使用场景:排行榜,投票等等

2.持久化
2.1 RDB,类似snapshot。
当符合一定条件时 redis 会folk一个进程,利用copy on write原理,自动将内存中的所有数据生成一份副本并保存到硬盘上。
过程:
遍历每个DB,遍历每个db的dict,获取每个dictEntry
获取key后查询expire,如过期就丢弃
将数据的key,value,expiretime等写入文件
计算checksum,通过checksum交换旧的rdb文件。

执行的前提条件:
1)配置自动快照的规则
2)用户执行了 SAVE 或 BGSAVE 命令
3)执行 FLUSHALL 命令
4)执行复制时
缺点:一旦 redis 程序退出,会丢失最后一次快照以后更改的所有数据。

相关参数有:
save 60 100
stop-write-on-bysave-error no
rdbcompression yes
dbfilename dump.rdb

注,bgsave
如果redis在虚拟机上,那么bgsave时间可能会加长。
redis进程每占用1G内存,bgsave创建子进程所需要的时间增加10~20ms
save和bgsave的区别:save一直阻塞到快照生成。而bgsave由子进程完成。

RDB文件解析:
以db0中只存在set msg “hello”为例:

2.2 AOF,类似归档,起到追加的作用。
注,每次数操作都会调用flushApendOnlyFile来刷新AOF,每次操作都需要fsync,前台线程阻塞。
注,选用ssd将明显提高aof的性能。

相关参数有:
appendonly yes
appendsync everysec
no-appendsync-on-rewrite no
auto-aof-rewrite-percent 100
auto-aof-rewrite-min-size 64mb
dir ~/

AOF文件解析:

也就是如下:
select 0 ##选择db0
set col2 v2 ##插入key-value,col2-v2。

AOF重写(BGREWRITEAOF):
目的:减少AOF文件大小
触发条件:
1. 发起命令bgrewriteaof
2. aof文件的大小增长超过一定比例,且aof文件实际大小超过一定

注,目前key的条目不多于64,如果多于64个条目,会进行拆分。

2.3 数据完整性
如果允许几分钟的数据丢失。可以采用rdb,如果需要持续记录,那么可以采用aof。另外,从性能考虑,由于aof是持续写,可以将aof放在备库,主库只有rdb。

注,redis server异常crash后重启,将进行如下优先级操作:
如果只配置了aof,启动时加载aof
如果同步配置了aof和rdb,启动时只加载aof
如果只配置了rdb,启动时加载rdb的dump文件。

注,在linux 6(centos 6,redhat 6,oel 6)中,重启redis可以用/etc/init.d/redis-server restart命令,但是这个命令在重启的时候是不save的。就会导致如果不开aof,会丢失上次save之后的数据。
正确的做法是redis-cli之后,用shutdown命令(默认带save),或者shutdown save命令。不要用shutdown nosave。

如果在中途开启AOF,比较好的方式是:
a. 动态的修改CONFIG SET appendonly yes,此时会生成appendonly.aof 文件,不仅包含修改之前的值,还包含修改之后的值。
b. 修改redis.conf的值为appendonly yes
c. 在有停机窗口的时候,重启redis。

掉电导致AOF或者rdb文件损坏,相关修复工具:
redis-check-aof 检查、修复aof(会删除出错命令之后(含)所有的命令)
redis-check-dump 检查、修复rdb

3. Redis的key过期(expire)。
我们可以设置某个key过期:

上面的测试中,ttl key,返回-1表示不会expire,-2表示已经expired。大于0的数字表示剩余时间。另外可以看到,当set新值之后覆盖了原来的值,则设置在原来key上的expire也被取消了。

注1. Redis keys过期后叫volatile(在后面谈到设置maxmemory-policy的时候,会提到这个词),过期删除有两种方式:被动和主动方式。

注2.expire的限制:只能应用于整个键,而不能对键的某一部分数据做expire。也就是说,expire 列,不能expire 行。

注3. RDB对过期key的处理:过期key对RDB没有任何影响

注4. AOF对过期key的处理:过期key对AOF没有任何影响

不过期的话,到达maxmemory之后,所有和内存增加的操作都会报错。在64bit系统下,maxmemory默认设置为0表示不限制Redis内存使用,在32bit系统下,maxmemory隐式不能超过3GB。 所以在64位系统中,默认值是个危险的值。

当memory使用量到达maxmemory之后,将根据设置的maxmemory-policy的方式,进行内存回收。
maxmemory-policy可以设置的值有:
1. noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令(大部分的写入指令,但DEL和几个例外)
2. allkeys-lru: 尝试回收最少使用的键(LRU),使得新添加的数据有空间存放。
3. volatile-lru: 尝试回收最少使用的键(LRU),但仅限于在过期集合的键,使得新添加的数据有空间存放。
4. allkeys-random: 回收随机的键使得新添加的数据有空间存放。
5. volatile-random: 回收随机的键使得新添加的数据有空间存放,但仅限于在过期集合的键。
6. volatile-ttl: 回收在过期集合的键,并且优先回收存活时间(TTL)较短的键,使得新添加的数据有空间存放。

注,redis采用的LRU算法是近似LRU算法,LRU的采样率通过设置如maxmemory-samples 5来确定。新版本的redis的近似LRU算法,在同等的maxmemory-samples条件下,比旧版本的好很多。

4 redis的安装。
4.1 主机相关参数配置(注, for Linux 7):
4.1.1. 选择文件系统至少为ext4,xfs更佳。

4.1.2. 关闭numa,关闭redis所在文件系统/分区的atime选项。

4.1.3. 如果是非SSD,设置文件系统IO调度方式为deadline,如果是SSD则为noop。

4.1.4. 调整kernel。
4.1.4.1 检查当前操作系统使用的tuned profile
cat /etc/tuned/active_profile
virtual-guest

4.1.4.2. 建立一个目录用来放for redis的tuned profile
mkdir /etc/tuned/for_redis

4.1.4.3. 将当前系统默认的tune profile复制到for redis 下:
cp /usr/lib/tuned/virtual-guest/tuned.conf /etc/tuned/for_redis/

4.1.4.4.修改/etc/tuned/for_redis/
[main]
include=throughput-performance

[vm]
transparent_hugepages=never

[sysctl]
vm.dirty_ratio = 30
vm.swappiness = 30
vm.overcommit_memory = 1

net.core.somaxconn = 65535

4.1.4.5.指定tuned profile为for_redis
tuned-adm profile for_redis

4.1.4.6.重启主机。

4.2 下载、解压redis:
mkdir /root/redis_install
cd /root/redis_install
wget http://download.redis.io/releases/redis-3.2.9.tar.gz
tar -zxvf /root/redis_install/redis-3.2.9.tar.gz
cd /root/redis_install/redis-3.2.9
make
make test
注,make test时如果报错You need tcl 8.5 or newer in order to run the Redis test,则需要yum install tcl,正常情况下,如果make test通过,则显示如下:
make install
mkdir -p /etc/redis
mkdir -p /var/redis
mkdir -p /var/redis/6379
cp /root/redis_install/redis-3.2.9/redis.conf /etc/redis/redis_6379.conf
修改redis_6379.conf

启动:redis-server /etc/redis/redis_6379.conf
连接:redis-cli -a oracleblog -h 192.168.56.108 -p 6380 (注,oracleblog就是在requiepass中设置的密码)
关闭:192.168.56.108:6379> shutdown save

5. 一个redis最多包含16个db,可以通过select进行跳转,move可以转移key到别的db。

二、redis的主从复制和sentinel

1. 主从复制配置:
我们来配一个1主2从的redis。分别是在3台主机,3个端口上。
主:192.168.56.108 port 6379 –> 从1:192.168.56.109 port 6380 –> 从2:192.168.56.110 port 6381

各个主机上的配置文件:

注1:复制启动过程中,从节点会丢弃旧数据(如果有的话)
注2:实际使中最好让redis主节点只使用50%~60%内存,留30%~45%用于bgsave。
注3:redis不支持主-主复制
注4:redis支持级联主从
注5:info命令看:aof-pending_bio_fsync是否为0,如果为0,表示主从同步正常。aof-pending_bio_fsync的含义是number of fsync pending job in background I/O queue
注6:从网上的测试看,启动复制,比没有复制的TPS会有所降低,在100 client并发的情况下,大约降低30%。响应时间,从0.8毫秒到1.2毫秒。

如何更换故障的主服务器:

2. 高可用架构sentinel配置:
sentinel是redis实例的一个特殊模式,可以通过如下两种方式启动:
redis-sentinel /path/to/sentinel.conf

redis-server /path/to/sentinel.conf –sentinel

Sentinel 原理:

●主观下线(Subjectively Down, 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。
●客观下线(Objectively Down, 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断, 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断。

注,客观下线条件只适用于主服务器。
1 到 3 是自动发现机制:
以 10 秒一次的频率,向被监视的 master 发送 info 命令,根据回复获取 master 当前信息。
以 1 秒一次的频率,向所有 redis 服务器、包含 Sentinel 在内发送 PING 命令,通过回复判断服务器是否在线。
以 2 秒一次的频率,通过向所有被监视的 master,slave 服务器发送当前 Sentinel master 信息的消息。
4 是检测机制,5 和 6 是 failover 机制,7 是更新配置机制。

注:sentinel不建议是单个,因为:
1:即使有一些sentinel进程宕掉了,依然可以进行redis集群的主备切换;
2:如果只有一个sentinel进程,如果这个进程运行出错,或者是网络堵塞,那么将无法实现redis集群的主备切换(单点问题);
3:如果有多个sentinel,redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息

实施步骤:
我们来配一个1主2从的redis。分别是在3台主机,3个端口上。

1. cp /root/redis_install/redis-3.2.9/sentinel.conf /etc/redis/sentinel_6379.conf
2. 按照上面说的配置项进行修改
3. redis-sentinel /etc/redis/sentinel_6379.conf
4. 在其他从节点重复上面的步骤
5. 在主节点redis-cli -p 26379 ping,正常返回pong,在从1节点redis -p 26380 ping,正常返回pong;在从2节点redis-cli -p 26381 ping,正常会返回pong
6. 在从1节点redis-cli -p 26380 sentinel masters,显示如下,注意34行和35行,显示了有2个slave和察觉到了有2个sentinel:

7. 在从1节点运行sentinel slaves mymaster:

8.在从1运行sentinel get-master-addr-by-name :

9. kill掉redis进程,或者运行sentinel failover命令:

在节点1的log中,可以看到:

在节点2的log中可以看到:

在节点3的log中,可以看到:

三、Redis的分片和集群高可用架构

redis的高可用+分片技术,是通过redis cluster来实现的。一般情况下,如果单个或者主从结构,撑不住业务的需求,如单核CPU撑爆,或者内存使用过多,我们一般会将redis拆成多个分片。

1. Redis的分片技术,可以分成
1.1 redis原生分片:



1.2 proxy分片:



1.3 应用程序分片:


我们这里聊的是redis的原生分片,即redis cluster。它可以实现多主多从的架构,多从是为了给主在down掉的时候,实现切换。这个切换在cluster内提供,不需要在额外的使用sentinel。注意:redis集群需要至少6个节点,也就是六台服务器。如果服务器数量不足可在每台服务器上建立多个节点,如2台服务器,每台服务器上建立3个节点。

另外,由于redis cluster官方自带的redis-trib.rb工具不支持密码,因此在配置完成前,不能加密码。

Redis集群不能保证强一致性。产生写操作丢失的第一个原因,是因为主从节点之间使用了异步的方式来同步数据。

一个最小的集群需要最少3个主节点。建议配置至少6个节点:3个主节点和3个从节点。

2. 安装redis cluster:
redis cluster的管理工具是redis-trib。
2.1. 要运行redis-trib要先安装ruby运行环境:
yum -y install ruby

2.2. 接下来安装ruby gems,用它来查找、安装、升级和卸载ruby软件包:
yum -y install rubygems

2.3. 然后通过gem来安装ruby的redis客户端
gem install redis

这一步有可能会失败,大多是因为国内连不上gem官方库,那只能修改gem库为国内的源,如淘宝网的RubyGems镜像:
下面是换源操作:

2.4. 修改各个主机上的redis.conf文件,添加cluster选项:

集群配置:
cluster-enabled <yes/no>: 如果配置”yes”则开启集群功能,此redis实例作为集群的一个节点,否则,它是一个普通的单一的redis实例。
cluster-config-file : 注意:虽然此配置的名字叫“集群配置文件”,但是此配置文件不能人工编辑,它是集群节点自动维护的文件,主要用于记录集群中有哪些节点、他们的状态以及一些持久化参数等,方便在重启时恢复这些状态。通常是在收到请求之后这个文件就会被更新。
cluster-node-timeout : 这是集群中的节点能够失联的最大时间,超过这个时间,该节点就会被认为故障。如果主节点超过这个时间还是不可达,则用它的从节点将启动故障迁移,升级成主节点。注意,任何一个节点在这个时间之内如果还是没有连上大部分的主节点,则此节点将停止接收任何请求。
cluster-slave-validity-factor : 如果设置成0,则无论从节点与主节点失联多久,从节点都会尝试升级成主节点。如果设置成正数,则cluster-node-timeout乘以cluster-slave-validity-factor得到的时间,是从节点与主节点失联后,此从节点数据有效的最长时间,超过这个时间,从节点不会启动故障迁移。假设cluster-node-timeout=5,cluster-slave-validity-factor=10,则如果从节点跟主节点失联超过50秒,此从节点不能成为主节点。注意,如果此参数配置为非0,将可能出现由于某主节点失联却没有从节点能顶上的情况,从而导致集群不能正常工作,在这种情况下,只有等到原来的主节点重新回归到集群,集群才恢复运作。
cluster-migration-barrier :主节点需要的最小从节点数,只有达到这个数,主节点失败时,它从节点才会进行迁移。更详细介绍可以看本教程后面关于副本迁移到部分。
cluster-require-full-coverage <yes/no>:在部分key所在的节点不可用时,如果此参数设置为”yes”(默认值), 则整个集群停止接受操作;如果此参数设置为”no”,则集群依然为可达节点上的key提供读操作。

2.5. 我们分别在3个主机上启动6个实例:
192.168.56.108 : redis_6379.conf + redis_6389.conf
192.168.56.109 : redis_6380.conf + redis_6381.conf
192.168.56.110 : redis_6381.conf + redis_6391.conf

2.6. 创建cluster:

replicas表示需要有几个slave–replicas 1 表示 自动为每一个master节点分配一个slave节点 上面有6个节点,程序会按照一定规则生成 3个master(主),3个slave(从) 。

注,如果遇到ERR Slot xxxx is already busy (Redis::CommandError)的报错,就按照下面的方法解决:

我们来插入数据:
1. 先检查一下哪个是master:

或者下面的命令也可以:

2. 我们登录192.168.56.109:6390进行操作:

注意,这里的redis-cli要用-c参数。不然会报错:

3. 我们来尝试添加节点:
3.1. 先启2个redis实例,实例参数参考原来已经在跑的实例。
3.2. 添加一个实例到cluster,注意,这个是作为master的节点加进去的。

注意这里的df5bf5d030453acddd4db106fda76a1d1687a22f ,我们一会会用到。

添加从节点,注意我们这里用到了刚刚的主节点的mast id

4. 添加完之后,数据并没有重新分布,我们需要reshard。

重新分片命令:
交互式:
/redis-trib.rb reshard [host]:[port]
非交互式:
./redis-trib.rb reshard –from [node-id] –to [node-id] –slots [number of slots] –yes [host]:[port]

注意看下面那些master中0 slot的部分:

再次检查reshard之后的情况,可以看到每个master基本都分到了4096个slot。(因为总共16384 个slot,现在有4个master,如果平均分配,那么每个4096个slots。)

5. 删除节点。步骤相反:删除从节点,reshard数据去不用删除的节点,删除主节点。
删除从节点:

reshard数据:

检查已经是0 slot

删除确认没有slot的主节点

四. Redis的监控:

Redis的监控,主要还是从info命令的返回结果看。

1. 内存使用
如果 Redis 使用的内存超出了可用的物理内存大小,那么 Redis 很可能系统会被 OOM Killer 杀掉。针对这一点,你可以通过 info 命令对 used_memory 和 used_memory_peak 进行监控,为使用内存量设定阈值,并设定相应的报警机制。当然,报警只是手段,重要的是你得预先计划好,当内存使用量过大后,你应该做些什么,是清除一些没用的冷数据,还是把 Redis 迁移到更强大的机器上去。

2. 持久化
如果因为你的机器或 Redis 本身的问题导致 Redis 崩溃了,那么你唯一的救命稻草可能就是 dump 出来的 rdb文件了,所以,对 Redis dump 文件进行监控也是很重要的。你可以通过对 rdb_last_save_time 进行监控,了解你最近一次 dump 数据操作的时间,还可以通过对 rdb_changes_since_last_save 进行监控来知道如果这时候出现故障,你会丢失多少数据。

3. 主从复制
如果你设置了主从复制模式,那么你最好对复制的情况是否正常做一些监控,主要是对 info 输出中的 master_link_status 进行监控,如果这个值是 up,那么说明同步正常,如果是 down,那么你就要注意一下输出的其它一些诊断信息了。

4. Fork 性能
当 Redis 持久化数据到磁盘上时,它会进行一次 fork 操作,通过 fork 对内存的 copy on write 机制最廉价的实现内存镜像。但是虽然内存是 copy on write 的,但是虚拟内存表是在 fork 的瞬间就需要分配,所以 fork 会造成主线程短时间的卡顿(停止所有读写操作),这个卡顿时间和当前 Redis 的内存使用量有关。通常 GB 量级的 Redis 进行 fork 操作的时间在毫秒级。你可以通过对 info 输出的 latest_fork_usec 进行监控来了解最近一次 fork 操作导致了多少时间的卡顿。

5. 配置一致
Redis 支持使用 CONFIG SET 操作来实现运行实的配置修改,这很方便,但同时也会导致一个问题。就是通过这个命令动态修改的配置,是不会同步到你的配置文件中去的。所以当你因为某些原因重启 Redis 时,你使用 CONFIG SET 做的配置修改就会丢失掉,所以我们最好保证在每次使用 CONFIG SET 修改配置时,也把配置文件一起相应地改掉。为了防止人为的失误,所以我们最好对配置进行监控,使用 CONFIG GET 命令来获取当前运行时的配置,并与 redis.conf 中的配置值进行对比,如果发现两边对不上,就启动报警。

6. 监控服务
-Sentinel
Sentinel 是 Redis 自带的工具,它可以对 Redis 主从复制进行监控,并实现主挂掉之后的自动故障转移。在转移的过程中,它还可以被配置去执行一个用户自定义的脚本,在脚本中我们就能够实现报警通知等功能

-Redis Live
Redis Live 是一个更通用的 Redis 监控方案,它的原理是定时在 Redis 上执行 MONITOR 命令,来获取当前 Redis 当前正在执行的命令,并通过统计分析,生成web页面的可视化分析报表。

7. 数据分布
弄清 Redis 中数据存储分布是一件很难的是,比如你想知道哪类型的 key 值占用内存最多。下面是一些工具,可以帮助你对 Redis 的数据集进行分析。

-Redis-sampler
Redis-sampler 是 Redis 作者开发的工具,它通过采样的方法,能够让你了解到当前Redis 中的数据的大致类型,数据及分布状况。

-Redis-audit
Redis-audit 是一个脚本,通过它,我们可以知道每一类 key 对内存的使用量。它可以提供的数据有:某一类 key 值的访问频率如何,有多少值设置了过期时间,某一类 key 值使用内存的大小,这很方便让我们能排查哪些 key 不常用或者压根不用。

-Redis-rdb-tools
Redis-rdb-tools 跟 Redis-audit 功能类似,不同的是它是通过对 rdb 文件进行分析来取得统计数据的。

五、Redis的Docker化:

1.docker上安装redis
先search一下有哪些redis:

开始pull镜像:

建议pull的时候,选择一个比较好的fuckgfw网络,不然总是会报错:

安装并启动redis,且设置appendonly为yes,注意我们这里把容器内的/data目录映射到本地目录/Users/[username]/redisdata下,用于做持久化:

登录redis主机后运行redis-cli:

或者运行docker run -it redis:latest redis-cli也可以:

2.备份,迁移和克隆docker镜像:
2.1 检查原有信息:

2.1 停下container,并将container commit成images:

2.3 检查一下images是否已经建立

2.4 将container-backup 这个image做成tar文件:

2.5 我们这里将备份的东西,load进去,并且成为redis_2

2.6 docker run创建第二个redis,注意这里第二个redis的端口映射为26379,不修改的话,会和第一个redis的端口冲突。

2.7 启动第二个redis

2.8 检查2个redis已经部署好了。

六、Redis 4.0的新特性

1. Module的支持。
module可以在不改变redis源代码主分支的基础上,通过高层抽象的API挂载外部模块,来提供更多的功能,我的理解,这是类似postgresSQL的hook。

2. PSYNC v2
PSYNC(Partial Replication,增量同步)得到改进。
之前是从库尝试发送 psync 命令到主库,主库判断是否满足 psync 条件, 满足就返回 +CONTINUE 进行增量同步, 否则返回 +FULLRESYNC runid offfset。

虽然psync 可以解决短时间主从同步断掉重连问题,但以下几个场景仍然是需要全量同步:
a). 主库/从库有重启过。因为 runnid 重启后就会丢失,所以当前机制无法做增量同步。
b). 从库提升为主库。其他从库切到新主库全部要全量不同数据,因为新主库的 runnid 跟老的主库是不一样的

psync v2增加了一个replid2,来记录是从哪个master做同步的,这个replid2是从master的replid继承过来的。如果之前这两个曾经属于同一个主库(多级也允许), 那么新主库的 replid2 就是之前主库的 replid。只要之前是同一主库且新主库的同步进度比这个从库还快就允许增量同步。
因此上述的第二点,从库提升为主库之后,还是可以使用增量同步。

3. 缓存回收策略改进。
增加了LFU(Last Frequently Used)缓存回收策略。最不常用的缓存数据进行清理。

4. 非阻塞性DEL和FLUSHALL/FLUSHDB
在 Redis 4.0 之前, 用户在使用 DEL 命令删除体积较大的键, 又或者在使用 FLUSHDB 和 FLUSHALL 删除包含大量键的数据库时, 都可能会造成服务器阻塞。
redis 4.0提供了unlink命令来替代del命令。这个命令可以异步的删除大量key且不会阻塞。(注,为了保留向前的兼容性,del命令仍然保留)
同时,redis 4.0还提供了flushdb async和flushall async,两个命令的async选项,来提供异步的删除大量key。

redis 4.0还提供了一个交换db的命令swapdb,如swapdb 0 1,就可以将db0和db1交换。原来在db0中的key,全部去了db1。

5.支持mixed RDB-AOF的持久化模式。
Redis 就可以同时兼有 RDB 持久化和 AOF 持久化的优点 —— 既能够快速地生成重写文件,也能够在出现问题时,快速地载入数据。

开启混合存储模式后 aof 文件加载的流程如下:
a). aof 文件开头是 rdb 的格式, 先加载 rdb 内容再加载剩余的 aof
b). aof 文件开头不是 rdb 的格式,直接以 aof 格式加载整个文件
判断 aof 文件的前面部分是否为 rdb 格式,只需要判断前 5 个字符是否是 REDIS。这个是因为rdb持久化开头就是REDIS, 同时aof文件开头一定不会是 REDIS(以前的版本文件开头都是*)。

6. 增加了内存检查命令,memory。如memory stats,memory usage,memory purge

7.增加了对NAT的支持。(主要是为了解决redis cluster在docker上的问题)。

更多信息,可见: Redis 4.0 release notesThe first release candidate of Redis 4.0 is out

相关文章

一条评论

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据