Redis--Day05

Redis的事务

1. 什么是Redis事务

• 可以一次执行多个命令，本质是一组命令的集合。一个事务中的 所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许加塞

2. 能为我们做什么

• 一个队列中，一次性、顺序性、排它性的执行一系列命令

3. 怎么使用呢？

3.1 常用命令

3.2 情况1：正常执行

3.3 情况2：放弃事务

3.4 情况3：全体连坐

3.5 冤头债主

3.6 情况5：watch监控

3.6.1悲观锁/乐观锁

悲观锁 (Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁 select * from sys_user for update

乐观锁 (Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，

乐观锁策略: 提交版本必须大于记录当前版本才能执行更新

3.6.2 初始化信用卡可用余额和欠额

3.6.3 无加塞篡改

先监控在开启multi，保证两笔金额变动在同一个事务内

3.6.4 有加塞篡改

监控了key，如果key被修改了，后面一个事务的执行失效

3.6.5 unwatch

一旦执行了exec，之前加的监控锁都会被取消掉了

3.6.6 小结

• Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变， 比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行
• 通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化， EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败

4. 3个阶段

​ **开启：**以MULTI开始一个事务

​ **入队：**将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面

​ **执行：**由EXEC命令触发事务

5. 3个特性

​ **单独的隔离操作：**事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

​ **没有隔离级别的概念：**队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行， 也就不存在”事务内的查要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题

​ **不保证原子性：**redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

Redis的复制(Master/Slave)（也就是主从复制）

1. 什么是复制？

1.1 官网说明

1.2 行话

行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slave机制，Master以写为主（主机），Slace以读为主（从机，不能写），

2. 有什么作用

读写分离

容灾恢复

3. 怎么使用

3.1 配从不配主

• 配置命令：【SLAVEOF 主库IP 主库端口】

  每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件

  info replication 可以查看是否是主机或从机，从机挂在哪个主机上

• 详细操作

  1. 拷贝多个redis.conf文件
  2. 开启daemonize yes
  3. 修改Pid文件名字
  4. 指定端口，就是修改端口号
  5. 修改Log文件名字
  6. 修改Dump.rdb名字

3.2 一主二仆

演示问题？

1. 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123是否也可以复制

   可以

2. 从机是否可以写？set可否？

   不可以

3. 主机shutdown后情况如何？从机是上位还是原地待命

   主机挂掉，从机全部原地待命，需要手动配置一个从机上位做主机（也就是反客为主）

4. 主机又回来了后，主机新增记录，从机还能否顺利复制？

   主机回来后，从机会再次连到主，可以复制；上位的从机不能，它上位之后，主机回来，它还是主机

5. 其中一台从机down后情况如何？依照原有它能跟上大部队吗？

   可以

3.3 薪火相传

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

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

• Slaveof 新主库IP 新主库端

3.4 反客为主

SLAVEOF no one

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

4. 复制的原理

Slave启动成功连接到master后会发送一个sync命令

Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步

全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步

但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

5. 哨兵模式

5.1 什么是哨兵模式

• 反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

5.2 怎么设置哨兵模式

1. 调整结构，6379带着80、81

2. 自定义的/myredis目录下新建sentinel.conf文件，名字绝对不能错

3. 配置哨兵内容：

   vi进入sentinel.conf下，添加一下信息

   sentinel monitor 被监控主机名字(自己起名字) 127.0.0.1 6379 1

   比如如 sentinel monitor host6379 127.0.0.1 6379 1

   其中，host6379是被监控的主机名；127.0.0.1是被监控主机ip；6379被监控主机端口号；

   1表示投票机制，只要有投1票的从机，就将它直接设置成主机，要是设置为2，那就监控，直到有投2票的，将被投2票的设为主机

4. 启动哨兵

   启动命令：/usr/local/redis/bin/redis-sentinel.conf /root/myredis/sentinel.conf

5. 正常主从演示

6. 原有的master挂了

7. 投票从选

8. 重新主从继续开工，info replication 查查看

• 问题：如果之前的master重启回来，会不会双master冲突？

  不会，因为主机回来之后，会变成从机挂在上位的主机上

5.3 一组sentinel能同时监控多个Master

6. 复制的缺点

• 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

ster重启回来，会不会双master冲突？

不会，因为主机回来之后，会变成从机挂在上位的主机上

5.3 一组sentinel能同时监控多个Master

6. 复制的缺点

• 由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。