Redis高级应用——2

Redis-事务

Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证：

1. 事务是一个单独的隔离操作，事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
2. 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行

事务的上个步骤：

1. 开启事务：以MULTI开启一个事务
2. 命令入队：将多个命令添加到命令队列中，接到这些命令不会立即执行，而是放到等待执行的事务队列中
3. 执行事务：有EXEC执行事务。（或者DISCARD取消执行）

事务相关指令：

指令	描述
MULTI	标记一个事务块的开始
EXEC	执行所有事务块内的命令。
DISCARD	取消事务，放弃执行事务块内的所有命令。
UNWATCH	取消 WATCH 命令对所有 key 的监视。
WATCH key [key ...]	视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断

执行事务出现的四种情况：

1. 正常执行：队列中所有的指令全部会被执行。
2. 全部取消：队列中的所有指令全部会被取消。
3. 全体连坐：如果指令集中有一条在加入队列时报错，则队列中的所有指令全部取消。
4. 冤头债主：如果指令已经加入到队列中，但执行失败，只有当前指令失败，其它继续执行。

redis事务的三个特性：

1. 单独的隔离性：事务中的所有的命令都会序列化，按顺序执行，事务在执行过程中，不会被其它客户端发送过来的命令请求所打断
2. 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新。
3. 不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

watch监控

watch监控表示对需要操作的key添加一个乐观锁，防止另一个用户进行修改，导致结果错误。

• 悲观锁
  • 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会被block直到它拿到锁。传统的关系型数据库里面就用到了很多这种锁，比如行锁，表锁，读锁，写锁等，都是在操作之前先上锁。
• 乐观锁
  • 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。提交的版本号必须大于当前版本号才可以提交

在访问以写入为目的数据的时候（SOL中的SELECT FOR UPDATE),关系数据库会对被访同的数据行进行加锁，直到事务被提交（Commit）
或者被回滚（ROLLBACK）为止，如果有其他客户端试图对被加锁的数据行进行写入，那么该客户端将被阻塞、直到第一个事务执行完毕为止。加锁在实际使用中非常有效，基本上所有关系数据库都实现了这种加锁功能，它的缺点在于，持有锁的客户端运行越慢，等待解锁的客户端被阻塞的时间就越长。

因为加锁有可能会造成长时间的等待，所以Redis为了尽可能地减少客户端的等待时间，并不会在执行WATCH命令时对数据进行加锁，相反地，Redis只会在数据已经被其他客户端抢先修改了的情况下，通知执行了WATCH命令的客户端，

Redis-主从复制

什么是主从复制？

主从复制，是用来建立一个和主数据库（master）完全一样的数据库环境，称为从数据库(slave)。

主从复制的作用和使用场合一般有几个：

1. 容灾恢复，主数据库服务器故障后，可迅速从从数据库恢复
2. 读写分离、主数据库主要做写的操作，从数据库做读的操作

主从复制应用场景

• 电子商务网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是”多读少写”。
• 对于这种场景，我们可以使如下这种架构

​​​

主从复制应用场景说明

我们将一台Redis服务器作主库(Matser)，其他三台作为从库(Slave)，主库只负责写数据，每次有数据更新都将更新的数据同步到它所有的从库，而从库只负责读数据。这样一来，就有了两个好处：

1. 1. 数据被复制成了了好几份，就算有一台机器出现故障，也可以使用其他机器的数据快速恢复。
   2. 读写分离，不仅可以提高服务器的负载能力，并且可以根据读请求的规模自由增加或者减少从库的数量，棒极了；

注意事项：

在Redis主从模式中，一台主库可以拥有多个从库，但是一个从库只能隶属于一个主库

主从复制实现方式

1. 一主二仆
2. 薪火相传
3. 反客为主

一主二仆

一个Master两个或多个Slave

​

​

具体操作：

在多台机器上配置好redis环境，并修改相应的配置文件

只需要在从数据库加配置如下代码：

slaveof 主数据库地址  主数据库端口

例如：slaveof 127.0.0.1 6379

如果设置了密码：

masterauth 主库密码

示例在一台机器上面实现一主二仆：

这里是用的windows版本的redis,然后可以根据Windows Service Documentation.docx文档建立后台服务

​

​

打开之后找到 redis-server --service-install  和 redis-server --service-uninstall

​

​

​​

​

创建从服务器

​

​

​

启动客户端

​

​实现主仆关系

​

当主库意外关闭时，从库是什么情况？

当主库关闭时，从库继续保持从库状态，但是和主库的连接丢失，不能在同步更新数据。如果主库恢复，从库也会恢复到连接状态。 当从库1关闭时，主库和从库N都不受影响。但是当从库重新恢复时，丢失和主库的连接状态，必须重新关联。

​薪火相传

什么是薪火相传？

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻master的写压力

中途变更转向:会清除之前的数据，重新建立拷贝最新的

​​​

实现方式：

slaveof 新主库IP 新主库端口​

薪火相传－演示

1.打开三台服务器（－主二仆）

​

2.从客户端连接三台服务器，通过指令info replication查询状态

​

3.将6381的主机修改成6380

语法：slaveof 主机IP  端口

​

4.再查看效果

​

反客为主

什么是反客为主？

使当前数据库停止与其他数据库的同步，转成主数据库

指令：SLAVEOF no one

演示：

1. 打开三个服务器
2. 打开相应的三个客户端
3. 将主服务器客户端shutdown
4. 将第二个客户端(6380)SLAVEOF no one，反客为主
5. 将其他的客户端指向新的master（SLAVEOF 127.0.0.1 6380）

主从复制执行过程：

1. 当一个从数据库启动时，会向主数据库发送sync命令。
2. Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步。
3. 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
4. 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步。
5. 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行。

​

​