关于redis

1.事务机制
1.1 事务介绍
redis是支持事务的。
举一个经典的例子：转账。

A向B汇款，那么A账户会扣钱；B账户会加钱
这两个步骤一定是在一个事务中的，要么都成功，要么都失败。

redis事务是基于队列实现的，创建一个事务队列，然后将事务操作都放入到对列中，最后依次执行。

 

  

   

  1.2 事务的处理机制

在redis中，如果开启了事务，某一条命令执行出错了，此时事务会怎么处理呢？你可能会说了，要么都成功，要么都失败，有一个失败，那就全失败了呗。

这么想不能算错，但是redis对于命令执行错误有两种解决方式：

• 语法错误(编译)
• 执行错误(运行)

1.2.1 语法错误
也就是执行命令的语法不对：

  1.2.2 执行错误

命令在执行的发生错误

  上面的事务中，语法是没有问题的，所以在运行之前redis是无法发现错误的，但是在执行的时候出现了错误，因此只会错误的命令不执行，而正确的命令会执行。

 1.3 springboot整合事务操作

1）修改redisconfig配置类，开启事务控制

 2）自定义方法，测试事务效果

 2. 持久化机制

2.1 场景分析
redis是将数据存放到内存中的，一旦服务器宕机重启，内存中的数据就会消失，为了避免这种事情发生，redis提供了持久化机制，将内存中的数据存放到磁盘上，避免数据意外丢失。

redis提供了两种持久化机制，AOF和RDB。

2.2.RDB快照
2.2.1 概述
RDB是redis默认的持久化机制，基于快照的思想，当符合一定条件(自动或者手动)时，redis就会将这一刻的内存数据进行快照并保存到磁盘上，产生一个经过压缩的二进制文件，后缀名.rdb的文件

 

 

   

  因为RDB文件是保存在磁盘上的，因此即使Redis进程退出，甚至服务器宕机重启。只要RDB文件存在，就可以利用它来还原Redis数据。

2.2.2 RDB触发条件
在redis.conf文件中配置一些默认的触发机制

1. save "" # 不使用RDB存储 不能主从
2. save 3600 1 #表示一个小时内至少一个键被更改则进行快照
3. save 300 100 #表示5分钟（300秒）内至少100个键被更改则进行快照。
4. save 60 10000 #表示1分钟内至少10000个键被更改则进行快照

 手动执行save或者bgsave命令

在redis客户端手动执行save或者bgsave命令，手动触发RDB快照

 这两个命令都可以触发快照，那么他们两个的区别是什么呢?

• save:同步处理，阻塞redis服务进程，服务器不会执行任何命令，直到RDB文件保存完毕。
• bgsave：会fork一个和主线程一致的子线程复制操作RDB文件，不会阻塞redis服务进程。

redis默认使用的是bgsave来保存快照数据

2.2.3 优缺点
优点：

• 基于二进制文件完成数据备份，占用空间少，便于文件传输
• 能够自定义规则，根据redis繁忙状态进行数据备份

缺点：

• 无法保证数据的完整性，会丢失最后一次快照后的所有数据
• bgsave每次执行都会阻塞redis服务进程创建子线程，频繁执行影响系统的吞吐率

2.3.AOF
2.3.1 概述
RDB方式会出现数据丢失的问题，对于这个问题，可以通过Redis中另外一种持久化方式解决：AOF。

AOF 是reids提供的另外一种持久化方式，与RDB快照记录数据不同的是，当开启AOF持久化后，redis会将客户端发送的所有更改数据的命令记录到磁盘的AOF文件中，这样的话，当redis重启后，通过读取AOF文件，按顺序获取记录的数据修改命令，即可完成数据的恢复。

 

 举个例子，对Redis执行三条写命令：

 

 RDB会将name，cart，lesson三个键值对数据进行保存，而AOF会将set，hset，sadd三个命令保存到AOF文件中。

2.3.2 基础使用
AOF方式需要手动开启，修改redis.conf

 当开启了AOF机制之后，Redis何时向AOF文件中记录内容呢?

对于AOF的触发方式有三种：always，everysec，no。默认使用everysec，可以通过redis.conf中的appendfsync属性进行配置。

开启AOF后，重启redis，进入redis客户端执行多条写命令，这些命令会被保存到appendonly.aof文件中。

此时查看redis/data目录，会新产生一个appendonly.aof文件。 查看文件内容

  通过文件查看，可以看到，在aof文件中，记录了对redis操作的所有写命令，读命令并不会记录。

2.3.3 执行原理
AOF功能实现的真个执行过程可以分为三个部分：命令追加，文件写入，文件同步。

 

  

1.  客户端向redis发送写命令。
2. Redis将接收到的写命令保存到缓冲文件中的末尾，这个过程是命令追加。
3. redis将缓冲区文件内容写入到AOF文件中，这个过程叫文件写入。
4. redis根据策略将AOF文件保存到磁盘，这个过程叫文件同步。
5. 何时将AOF文件同步到磁盘的策略依据就是redis.conf文件中appendfsync属性值：always,everysec,no

• always：每次执行写命令都会将缓冲区文件的内容写入到AOF文件中，并将AOF文件同步到磁盘。该效率最低，安全性最高。
• ererysec：每次执行写命令都会将缓冲区文件的内容写入到AOF文件中，并且每隔一秒会有子线程将AOF文件同步到磁盘，该方式兼备了效率与安全，即使出现宕机重启，也只是丢失不超过两秒的数据。
• no：每次执行写命令都会将缓冲区文件的内容写入到AOF文件中，但并不会将AOF文件进行同步磁盘，同步操作交由操作系统完成(每30秒一次)，该方式最快，但是最不安全。

 2.3.4 AOF重写优化

2.3.4.1 概述
AOF会将对redis操作的所有写命令都记录下来，随着服务器的运行，AOF文件内保存的内容会越来越多，这样就会造成两个比较严重的问题：占用大量内存空间，数据还原花费的时间多。

举个栗子：

当这些命令执行玩，AOF文件中记录5条命令。但是实际生产环境下，写命令会出现非常多，文件的体积会非常大。

为了解决AOF文件巨大的问题，Redis提供了AOF重写机制，当AOF文件体积超过阈值，就会触发AOF重写机制，Redis开启子线程创建一个新的AOF文件替代原来的AOF文件，新的AOF文件不会包含任何浪费空间的冗余命令，只存在恢复当前redis状态的最小命令集合。

2.3.4.2 触发配置
那么AOF文件达到多大时，会将其进行重写呢？对于重写阈值的配置，可以通过修改redis.conf进行配置。

 除了让redis自动执行重写外，也可以手动让其进行执行：bgrewriteaof

2.4.RDB与AOF对比

1. RDB是默认开启的，AOF需要手动开启。
2. RDB性能优于AOF。
3. AOF安全性由于RDB。
4. AOF优先级高于RDB.
5. RDB存储某个时刻的数据快照，AOF存储写命令。
6. RDB在配置触发状态会丢失最后一次快照以后更改的所有数据；AOF默认使用everysec，每秒保存一次，最多丢失两秒以内的数据。

3.高可用-主从复制
3.1.问题概述
通过持久化机制的学习，可以发现，不管是RDB还是AOF，都不能百分百的避免数据的丢失。关键是现在只有一台服务器，持久化数据都是保存在这台服务器上，假设这台服务器的磁盘损坏，数据仍然会全部丢失。 那这个问题该怎么解决呢？

那我们想一下，现在所有持久化数据只是保存在一台服务器上，能不能让它们同时保存在多台服务器上，这样即使一台服务器出现问题，仍然可以从其他服务器同步数据。

这样就需要当一台服务器中数据更新后，可以自动的将更新的数据同步到其他服务器上， 这就是所谓的复制。

 

 3.2.复制搭建&使用

 关键步骤：

（1）安装依赖环境及安装Redis

  （2）创建目录

  将资料中配置文件复制到 conf 文件夹下

（3）启动Redis master节点
————————————————
版权声明：本文为CSDN博主「小程同学哦」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_45891099/article/details/125901587