一、Redis的事务
1.是什么
可以一次执行多个命令,本质是一组命令的集合。一个事务中的
所有命令都会序列化,按顺序地串行化执行而不会被其它命令插入,不许加塞
(更多请参见官网事务介绍)
2.能干什么
一个队列中,一次性、顺序性、排他性的执行一系列命令
3.怎么干
摘取官网:
常用如下:
开启一个事务:(MULTI)
添加若干命令加入队列,执行事务(EXEC)
添加操作后不想执行,放弃事务(DISCARD)
一个出错,全体受罚,连坐(一个出错,其它事务内操作均不成功)
谁的命令加入队列时正常执行时报错,则冤头债主,只找它(这里k1的v1不是Integer不能增加)
//和上一个的区别就是这个是加入队列时成功,执行时出错,而上一个加入队列时就出错了
所以说,Redis对事务的支持,是部分支持
watch监控
悲观锁/乐观锁/CAS(Check And Set)
悲观锁(会有点像行锁和表锁)
悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁
乐观锁(一般用乐观锁,还是乐观点好)
乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号(在记录后加一个版本号,通过版本号来判断是否进行了修改)等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,
CAS
redis中使用 check-and-set 操作实现乐观锁
模拟场景:模拟信用卡消费,可用额度:balance,当前欠款:debt
无加塞篡改,先监控再开启multi,保证两笔金额变动在同一个事务内(如果监控的变量在其它事务地方发生了变化,将会报错)
有加塞篡改,监控了key,如果key被修改了,后面一个事务的执行失效(以前一个事务执行结果为准)
UNWATCH(WATCH之后的设值是模拟其它终端进行了修改,实际操作中可用通过boolean等变量来控制,当有人修改时,放弃监控,再获取最新的进行监控修改,直到没有人修改,再开始监控,开启事务)——此命令是取消监控所有key
一旦执行了exec之前加的监控锁都会被取消掉了,不管成功失败,本次操作就清了(操作结束)
小结:
Watch指令,类似乐观锁,事务提交时,如果Key的值已被别的客户端改变,比如某个list已被别的客户端push/pop过了,整个事务队列都不会被执行。
通过WATCH命令在事务执行之前监控了多个Keys,倘若在WATCH之后有任何Key的值发生了变化,EXEC命令执行的事务都将被放弃,同时返回Nullmulti-bulk应答以通知调用者事务执行失败
4.事务三阶段
开启:以MULTI开始一个事务
入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面
执行:由EXEC命令触发事务
5.事务三特性
单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
没有隔离级别的概念:队列中的命令没有提交之前都不会实际的被执行,因为事务提交前任何指令都不会被实际执行,也就不存在”事务内的查询要看到事务里的更新,在事务外查询不能看到”这个让人万分头痛的问题。
不保证原子性:redis同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚
二、Redis的发布和订阅
1.是什么
(兼职做一下发布,实际还是做分布式缓存的)
进程间的一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。
2.实例:
先订阅后发布后才能收到消息,
1 可以一次性订阅多个,SUBSCRIBE c1 c2 c3
2 消息发布,PUBLISH c2 hello-redis
===========================================================================================================
3 订阅多个,通配符*, PSUBSCRIBE new*
4 收取消息, PUBLISH new1 redis2015
左边发布,右边获取:
三、主从复制
1.是什么
行话:也就是我们所说的主从复制,主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主
2.能干什么
读写分离 容灾恢复
3.怎么干
配从(库)不配主(库)
从库配置:slaveof 主库IP 主库端口
每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件
info replication
开始实验
拷贝多个redis.conf文件(用于模拟多台机器)
开启daemonize yes
pid文件名字
指定端口
log文件名字
dump.rdb名字
常用3招:其实已经是过时,后面将会由哨兵模式更先进的模式取代
一主二仆
开启3台机器模拟如下:
启动情况如下:
使用 INFO replication
: 查看主/从复制信息(此时还是三台主机身份)
使用 slaveof 192.168.1.1 6379进行主从复制:(后两台使用命令后变为从机)
注意,此时从机是可以取得k1 k2 k3的(即使从机是从k4才开始开启备份),也就是说,从机一旦接管,便从头录到尾
此时查看主机79信息:身份是主机,后跟着两个小弟(从机),再在从机中查看主从复制信息可以看到是slave(从机状态)
假设三台机器都执行相同的命令,思考结果:
//结果:只有主机可以正确执行,从机将会出错。也就是从机无法覆盖主机。
假设主机挂了,思考此时从机是代替主机上位,还是原地待命(假设由你设计,哪种方案)
//主机关机后,从机之前备份的数据是存在的(不然,备份意义何在呢)
可以发现还是从机身份,不过连接状态为down
此时再把主机开启,并且进行操作
//可以发现是可以获取到最新的值的。(主机一旦正常,一切照旧)
假设其中一台从机挂了,另外的从机是正常运作的,而主机当然不受影响:
再把从机启动,发现身份信息翻身为主机了
但是其它机器在80SHUTDOWN期间的操作,80的无从获取的;原因是前面说过的,只要从机断开连接(自己挂了),就要重新和主机连接
不然就认为是一台独立的机器而不是从机(除非写进它的配置文件)
当然了,只要它重新和主机连接,重新作为从机,是可以正常运作的(再增量备份一份,最新的k8也有了):
薪火相传
1.上一个Slave可以是下一个slave的Master,Slave同样可以接收其他slaves的连接和同步请求,
那么该slave作为了链条中下一个的master,可以有效减轻master的写压力。
2.中途变更转向:会清除之前的数据,重新建立拷贝最新的
3.slaveof 新主库IP 新主库端口
原先是80 81挂在79上,变更为81挂80,80依旧挂79
此时查看79主从复制信息:其下只有一个直接从机
在第一台主机上设值,可以看到直接和间接从机都能成功获取(薪火相传是OK的)
查看80的主从复制信息:总体而言是一个slave,但它同时连接了一个slave(包工头还是打工的,但手下还管了人)
反客为主
SLAVEOF no one
使当前数据库停止与其他数据库的同步,转成主数据库
先将上一个实验中间接从机81改回来,使环境正常:
假设主机挂了,我们不再像第一个实验一样,傻傻的等待主机苏醒,而是从从机中选出新主机上位:SLAVEOF no one(不再为奴)
现在主机变更为80,现在81就不傻傻的等了,跟着新主机81混了。格局变更
现在老主机再回来,不过目前80 81已经组成新的格局,老主机再次苏醒,可惜无法入局了:
4.复制原理
仔细区分思考、,是增量还是全量
1.slave启动成功连接到master后会发送一个sync命令
2.Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步
3.全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
4.增量复制:Master继续将收集到的修改指令,依次发送给slave,完成同步
5.但是只要是重新连接master,一次完全同步(全量复制)将被自动执行
5.哨兵模式(sentinel)
是什么
反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库
怎么干
调整结构,6379带着80、81
开始实验之前,依旧恢复原始环境(80 81都跟着79走,可以在79查看是否环境正常)
自定义的/myredis目录下新建sentinel.conf文件,名字绝不能错
配置哨兵,填写内容
vim sentinel进行配置
sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
上面最后一个数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机
启动哨兵
redis-sentinel /myredis/sentinel.conf
上述目录依照各自的实际情况配置,可能目录不同
此时主机出现故障,哨兵开始工作:
选出主机,更换格局:
倘若此时老的主机回来,哨兵模式下会有何变化:
开始启动是master,经哨兵监控调剂,成为从机!
上述实验为监控一个master,实际:一组sentinel能同时监控多个Master
6.复制的缺点
复制延时
由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。