Redis第二天

Java操作Redis

导入依赖

<packaging>pom</packaging>

<!-- https://mvnrepository.com/artifact/redis.clients/jedis -->
        <dependency>
            <groupId>redis.clients</groupId>
            <artifactId>jedis</artifactId>
            <version>4.1.1</version>
        </dependency>

连接使用

Jedis jedis=new Jedis("master",6379);
jedis.set("k","v");

命令说明： 

 

 

 

 HASH散列

 

设置单个字段

HSET key field value

HSETNX key field value

key的filed不存在的情况下执行，key不存在直接创建

设置多个字段

HMSET key field value [field value ...]

返回字段个数

HLEN key

判断字段是否存在

HEXISTS key field

key或者field不存在，返回0

返回字段值： HGET key field

返回多个字段值： HMGET key field [field ...]

返回所有的键值对： HGETALL key

返回所有字段名： HKEYS key

返回所有值： HVALS key

在字段对应的值上进行整数的增量计算： HINCRBY key field increment

在字段对应的值上进行浮点数的增量计算： HINCRBYFLOAT key field increment

删除指定的字段： HDEL key field [field ...]

 

存储某一批相同数据前加上标记中间以冒号分割

存储对象 应该选择hash(具体按需求)

redis做缓存使用,所缓存的数据 需要加上TTL 每次访问当前数据都需要更新TTL

持久化机制

数据再内存和磁盘之间的相互转换

RDB

redis默认持久化机制时RDB

把redis存储再内存中的数据以快照(备份)存储到磁盘

默认:存储策略(不会进行叠加,某一个生效之后 计数和计时会归零)

save 3600 1
​
save 300 100
​
save 60 10000
​

关闭默认RDB(关闭自动策略 可以手动实现)

1.通过命令 config save ""
2.修改配置文件redis.conf
放开save ""

手动触发RDB机制

save bgsave

save :会阻塞客户端的响应

bgsave:后台执行不会阻塞

进入到客户端 执行 save bgsave
关闭redis服务默认执行rdb策略

优点和缺点

优点

完全备份 不同版本的恢复

容灾

缺点

在下一次没有持久化之前 所有的内容全部消失

folk过程非常耗时，会造成毫秒级不能响应客户端请求

AOF

默认时RDB持久化机制 需要手动开启AOF

在配置文件中修改appendonly no 改成yes

就吃话策略是默认的以追加的方式 进行写入到文件

每执行依次命令就会写一次(写入到缓存,一秒钟执行依次刷新 把缓存中的内容保存到磁盘aof文件)

Always：服务器每写入一个命令，就调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，也不会丢失任何已经成功执行的命令数据 Everysec（默认）：服务器每一秒重调用一次fdatasync，将缓冲区里面的命令写入到硬盘。这种模式下，服务器出现故障，最多只丢失一秒钟内的执行的命令数据 No：服务器不主动调用fdatasync，由操作系统决定何时将缓冲区里面的命令写入到硬盘。这种模式下，服务器遭遇意外停机时，丢失命令的数量是不确定的 运行速度：always的速度慢，everysec和no都很快

AOF重写或合并

AOF文件会把命令原模原样进行存储

1.会导致文件过大

2.命令重复

set a a
set a a

3.命令相互抵消

set a a
del a

4.命令简化

lset l a
lset l b
lset l c
lmset l a b c

重写

重写执行之后 会把内容存储为二进制

下一次进行append还是以String进行存储

手动:在命令行执行送BGREWRITEAOF

自动:达到触发机制默认执行

auto-aof-rewrite-min-size <size>，触发AOF重写所需的最小体积：只要在AOF文件的体积大于等于size时，才会考虑是否 需要进行AOF重写，这个选项用于避免对体积过小的AOF文件进行重写 ​ auto-aof-rewrite-percentage <percent>，指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof- rewrite-min-size指定的体积，并且超过上一次重写之后的AOF文件体积的percent %时，就会触发AOF重写。（如果服务 器刚刚启动不久，还没有进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来作为基准值）。将这个值设置 为0表示关闭自动AOF重写

优点

写入机制，默认fysnc每秒执行，性能很好不阻塞服务，最多丢失一秒的数据
重写机制，优化AOF文件
如果误操作了（FLUSHALL等），只要AOF未被重写，停止服务移除AOF文件尾部FLUSHALL命令，重启Redis，可以将数据集恢复到 FLUSHALL 执行之前的状态

缺点

相同数据集，AOF文件体积较RDB大了很多
恢复数据库速度叫RDB慢（文本，命令重演）

主从分离 主从复制

redis复制到其他节点

scp -r redis node1:`/usr/local/soft/`

首先给先启动主服务器 启动从服务器

主从关系 现有主 再有从

把master当成主节点 node1当成从节点

# 启动master
cd /usr/local/soft/redis/bin
redis-server redis.conf 
# 启动node1
cd /usr/local/soft/redis/bin
./redis-server --port 6380 --slaveof master 6379

主节点可以读写 从节点只能读

从节点是为了降低服务器读的压力 可以有一台可以有多台

主从节点可以相互替换

注意:主从关系中

如果想要实现主节点->从节点 需要先走从节点->主节点(一旦先执行主节点->从节点 redis服务就没有写的功能了 都是从节点)

主节点->从节点
命令行输入:slaveof host port
从节点->主节点
命令行输入:slaveof no one

启动从节点客户端

./redis-server -p port