windows版本:https://github.com/MicrosoftArchive/redis/tags (官网没有,只能去github下载,也只有3.2版本以下的)
linux版本: https://download.redis.io/releases/
redis是内存数据库,一旦断电或者宕机,内存中的数据将全部丢失,redis为了解决这个问题,提供了rdb和aof两种方式来持久化数据。
默认情况下redis会把内存里面的数据保存在一个叫做 dump.rdb
二进制的文件里面
rdb也就时把内存中的数据写入到磁盘里面,恢复的时候将rdb二进制快照文件里面的内容加载到内存中。
在redis.conf配置文件里面有个三个save配置属性,意思就是多少秒以内有多少个改动的话就把内存里面的数据写到一个 dump.rdb
文件里面,关闭rdb也只需要注释掉下面三个配置项即可 。
save 900 1 # 900秒有一个改动
save 300 10 # 300秒有10个改动
save 60 10000 # 60秒有10000改动
文件名:dbfilename dump.rdb
文件路径:dir ./
save:在执行的过程中,会阻塞redis服务器,直到rdb文件创建完成,并且会覆盖掉原来的rdb文件。同步操作。
bgsave:redis借助操作系统写时的复制技术,copy-on-write思想,在生成快照的同时,依然可以正常处理其他命令,
仅在生成子进程调用fork函数的时候会有短暂的阻塞。bgsave子进程是由主线程fork出来的,他可以共享主线程的所有数据。
bgsave子进程开启后,会读取主线程的数据,并把它们写入到rdb。异步操作。
rdb的问题:一般来说不可能配置每秒钟有改动就重新写入rdb文件里面,是比较耗费性能的,所有在内存的缓存有改动的时候,
有可能还没有写入rdb文件。
为了解决rdb的问题,从1.1版本开始,appendonly yes
来开启aof功能,默认是关闭的
触发aof有三个选项可配置
appendfsync always # 每次有新的命令就写入到aof文件里面,处理的最慢的也是最安全的
appendfsync everysec # 每秒钟写入一次,最多丢失一秒钟的数据,也是redis官方推荐的
appendfsync no # 交给操作系统去处理,写的比较快但是也是最不安全的
aof文件里面只记录修改文件的命令,get命令不会记录
*号表示执行的命令有几个关键字或者参数,比如set access_token 123456,这条命令一共就是3个
$表示每个关键字或者参数的长度,set就是3,access_token就是12,123456就是6
aof是通过文件追加的方式实现的,为了避免文件越来越大重写耗费性能,新增了重写机制。
auto-aof-rewrite-min-size 64mb # aof文件至少达到64兆才会自动重写,文件太小恢复本来就很快。
auto-aof-rewrite-percentage 100 # aof文件自上一次重写增长了100%再进行重写
重写之后,如果之前有多条命令操作一个key之类的或者原子操作incr key 会最终变成一条记录,
比如 incr readcount了六次,重写之后的appendonly.aof里面之后只有一个set readcount 6的命令。
相比于重写之前,如果要恢复数据的话要执行6次的命令,而现在只需要执行1次即可。一条命令的操作肯定比6次效率高。
手动重写
通过 bgrewriteaof
命令进行手动重写
aof重写也会fork出一个子进程去做(类型与bgsave),先写临时文件最后在rename,所以不会对redis正常命令有太多影响。
此时如果不开启redis4.0的功能混合持久化,这个appendonly.aof文件还是能看懂,不是二进制开启混合持久
化就是类似于rdb文件的二进制文件,下面会讲混合持久化。
rdb文件较小,因为他是二进制文件,恢复快,但是安全性低,可能存在数据丢失的问题。优先级低。aof文件体积大,恢复慢,但是安全性高,最多只会丢失一秒钟的数据。优先级高。
redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据,redis恢复数据采用的是aof方式,为什么rdb恢复速度快不采用?因为rdb文件可能没有aof的数据安全。
在redis4.0版本中,可以开启两种方式的持久化策略,在 redis.conf
配置文件里面可以通过
aof-use-rdb-preamble yes
来开启或关闭,这种方式一定是要先开启aof才可以。
如果开启了混合持久化,aof重写会以rdb方式的二进制重写到appendonly.aof文件里面。
重写之后的appendonly.aof文件是二进制,重写之后有新的命令进来且没有触发到aof的重写机制,后面的命令就是
以aof格式存储到appendonly.aof文件里面的。恢复数据自然是二进制方式的比较快,这样就能达到了安全又恢复快文件又小的效果。
redis宕机重启的时候是通过dump.rdb文件和appendonly.aof文件来恢复数据的,所以只需要定期对这两个文件做备份即可。
在linux中可以通过写crontab定时调度脚本去实现。
pidfile /var/run/redis_6380.pid # 把pid进程号写入pidfile配置的文件
logfile "6380.log"
dir /usr/local/redis‐5.0.3/data/6380 # 指定数据存放目录
# 需要注释掉bind
# bind 127.0.0.1(bind绑定的是自己机器网卡的ip,如果有多块网卡可以配多个ip,代表允许客户端通
过机器的哪些网卡ip去访问,内网一般可以不配置bind,注释掉即可)
3、配置主从复制
# 从ip为192.168.1.1的机器的端口号为6379的redis实例复制数据,Redis 5.0之前使用slaveof
replicaof 192.168.1.1 6379
replica‐read‐only yes # 配置从节点只读,默认是开启的
4、启动从节点
redis‐server redis.conf
5、连接从节点
redis‐cli ‐p 6380
6、测试在6379实例上写数据,6380实例是否能及时同步新修改数据
7、可以自己再配置一个6381的从节点
如果你为master配置了一个slave,不管这个slave是否是第一次连接上Master,它都会发送一个PSYNC命令给
master请求复制数据。
master收到PSYNC命令后,会在后台进行数据持久化通过bgsave生成最新的rdb快照文件,持久化期间,master会继续接收客户端的请求,它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以后,master会把这份rdb文件数据集发送给slave,slave会把接收到的数据进行持久化生成rdb,然后再加载到内存中。然后,master再将之前缓存在内存中的命令发送给slave。
当master与slave之间的连接由于某些原因而断开时,slave能够自动重连Master,如果master收到了多个slave并发连接请求,它只会进行一次持久化,而不是一个连接一次,然后再把这一份持久化的数据发送给多个并发连接的slave。
客户端可以一次性发送多个命令,从而节省网络开销,管道执行多条命令的操作实际上相当于只执行了一条命令。
管道操作并不具备原子性,比如管道三条命令,第二条报错了,不会影响第三条的正常操作。
redis2.6版本支持lua脚本。
public static void main(String[] args) {
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxTotal(20);
config.setMaxIdle(10);
config.setMinIdle(5);
String host = "127.0.0.1";
Integer port = 6370;
JedisPool jedisPool = new JedisPool(config, host, port, 3000, null);
Jedis jedis = jedisPool.getResource();
// System.out.println(jedis.set("address", "beijingshi"));
// System.out.println(jedis.get("address"));
// 管道实例
/* Pipeline pipeline = jedis.pipelined();
for (int i = 0; i < 2; i++) {
jedis.incr("pipelineKey");
jedis.set("test" + i, "111");
// 模拟管道报错
// jedis.setbit("tqz", -1, true);
}
List