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 可以查看是否是主机或从机,从机挂在哪个主机上
-
详细操作
- 拷贝多个redis.conf文件
- 开启daemonize yes
- 修改Pid文件名字
- 指定端口,就是修改端口号
- 修改Log文件名字
- 修改Dump.rdb名字
3.2 一主二仆
演示问题?
-
切入点问题?slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来,那之前的123是否也可以复制
可以
-
从机是否可以写?set可否?
不可以
-
主机shutdown后情况如何?从机是上位还是原地待命
主机挂掉,从机全部原地待命,需要手动配置一个从机上位做主机(也就是反客为主)
-
主机又回来了后,主机新增记录,从机还能否顺利复制?
主机回来后,从机会再次连到主,可以复制;上位的从机不能,它上位之后,主机回来,它还是主机
-
其中一台从机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 怎么设置哨兵模式
-
调整结构,6379带着80、81
-
自定义的/myredis目录下新建sentinel.conf文件,名字绝对不能错
-
配置哨兵内容:
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票的设为主机
-
启动哨兵
启动命令:/usr/local/redis/bin/redis-sentinel.conf /root/myredis/sentinel.conf
-
正常主从演示
-
原有的master挂了
-
投票从选
-
重新主从继续开工,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机器数量的增加也会使这个问题更加严重。