Redis的学习(一、Redis的一些常用技术)
与大多数的NoSql不同,Redis是存在事务的,尽管它没有数据库那么强大。Redis的事务是使用MULTI-EXEC的命令组合,使用它可以提供两个重要的保证:
1. 事务是一个被隔离的操作,事务中的方法都会被Redis进行序列化并按顺序执行,事务在执行的过程中不会被其他客户端发生的命令所打断。
2. 事务是一个原子性的操作。要么全部成功,要么全部失败。
Redis使用事务会经过三个过程:
1. 开启事务。
2. 命令进入队列。
3. 执行事务。
命令 | 说明 | 备注 |
multi |
开启事务命令,之后的命令就进入队列,而不会马上被执行。 | 在事务生存期间,所有的Redis关于数据结构的命令都会入队。 |
watch key1 [key2....] | 监听某些键,当被监听的键在事务执行前被修改,则事务会被回滚 | 使用乐观锁 |
unwatch key1 [key2....] | 取消监听某些键。 | -- |
exec | 执行事务,如果被监听的键没有被修改,则采用执行命令,否则就回滚命令。 | 在执行事务队列存储的命令前,Redis会检测被监听的键值有没有发生变化,如果没有则执行命令,否则就回滚事务。 |
discard | 回滚事务 | 回滚进入队列的事务命令,之后就不能再用exec命令提交了。 |
Redis的基础事务
开启事务:multi,执行事务:exec。在他们中间采取进入队列的形式,exec的作用就是一次性发送队列里的命令去执行,而在执行这些命令的时候其他客户端不能再插入任何命令了,这就是Redis的事务机制。
注意:执行事务命令exec执行前,set和get都返回的是QUEUED。说明是放入了队列中,而不是执行,只有exec之后,队列中的内容才会被执行。
注意:如果使用了回滚操作,再使用exec就会报错了,因为discard命令已经取消了事务的命令,也就是说队列中没有要执行的命令了。所以报错了。
使用watch命令监控事务
在Redis中使用watch命令可以决定事务是执行还是回滚。一般而言,我们在multi命令之前使用watch命令监控某些键值对,然后使用multi命令开启事务,执行各类对数据结构进行操作的命令,这个时候这些命令就会进入队列。当Redis使用exec命令执行事务的时候,它首先会比对被watch监控的键值对,如果没有发生变化,那么它会执行事务中的命令,提交事务。如果发生变化,那么它不会执行任何事务中的命令,而去事务回滚。无论事务是否回滚,Redis都会去取消执行事务前的watch命令。
时刻 | 客户端 | 说明 |
T1 | set key1 value1 | 初始化key1 |
T2 | watch key1 | 监控key1的键值对 |
T3 | multi | 开启事务 |
T4 | set key2 value2 | 设置key2的值 |
T5 | exec | 提交事务,Redis会在这个时间点检测key1的值在T2时刻后,有没有被其他命令修改过,如果没有,则提交事务去执行 |
流水线(pipelined)
发布订阅
超时命令
复制
尽管我们说Redis的性能很好,每秒支持10万次左右的读写,但是还是不能应对那些百万次请求/每秒甚至更多的情况,那么我们的解决思路就是多添加一些服务器来分担这些请求。
1. 主从同步基础概念
互联网系统一般都是以主从架构为基础的,所谓主从架构设计的思路大概是:
(1)多个服务器中只有一个主服务器,n个从服务器。主服务器负责写入数据,从服务器用于读取数据。
(2)同时主服务器不负责让外部程序读取数据,从服务器不写入数据,只负责同步主服务器的数据,并让外部程序读取数据。
(3)主服务器写入数据后,即刻将写入数据的命令发送给从服务器,从而使得主从数据同步。
(4)应用程序可以随机读取某一台从服务器的数据,这样就分担了读数据的压力。
(5)当从服务器不工作,不会影响整个系统,当主服务器不工作,可以在从服务器中选出一个服务器作为主服务器。
2. Redis主从同步的过程
(1)先保证主服务器的开启,之后从服务器通过命令或者重启配置项可以同步到主服务器。
(2)从服务器启动之后,读取同步的配置,根据配置决定是否使用当前数据响应客户端,然后发送SYNC命令。当主服务器接收到同步命令时,会执行bgsave命令备份数据,但是主服务器此时不会拒绝客户端的读/写请求,而是将写命令写入缓存区。从服务器未收到主服务器备份的快照文件的时候,会根据其配置决定使用现有数据响应客户端/拒绝。
(3)bgsave命令执行完了之后,开始向从服务器发送备份文件,这个时候从服务器就会丢弃所有的现有数据,开始载入发送过来的快照文件。
(4)当主服务器发送完备份文件后,从服务器就会执行这些写入命令。此时就会把bgsave执行之后的缓存区内的写命令也发送给从服务器,从服务器完成备份文件解析,就开始像往常一样,接收命令,等待命令写入。
(5)缓冲区的命令发送完成后,当主服务器执行第一条写命令后,就同时往服务器发送同步写命令,从服务器就跟主服务器保持一致了。而此时当从服务器完成主服务器发送的缓冲区命令后,就开始等待主服务器的命令了。
哨兵
Redis可以存在多个服务器,并且实现了主从复制的功能。哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。
哨兵的作用
1. 通过发送命令,让Redis返回运行状态。
2. 当哨兵检测到主服务器宕机,会将从服务器切换成主服务器,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让他们切换主机。
现实中,我们常常使用多个哨兵对Redis服务器进行监控,而且哨兵之间也会互相监控,监控其他哨兵是否'活着',这样就变成了多个哨兵模式。
故障切换的过程(failover)
1. 假设主服务器宕机。
2. 哨兵1先监测到这个结果,但是系统并不会马上进行failover操作,这里仅仅是哨兵1主观的认为主机不可用,这个现象被称为主观下线。
3. 当其他一定数量的哨兵也监测到了主机不可用,那么哨兵之间就会发起一次投票,投票的结果由一个哨兵发起,进行failover操作,切换成功后,通过发布订阅模式,让各个哨兵把自己监控的服务器实现切换主机,这个过程称为客观下线。
持续更新!!!