Redis事务与主从复制（笔记）

一.Redis事务

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

事务命令：

discard

取消事务

exec

执行事务块内的命令

multi

标记一个事务的开始

unwatch

取消watch命令对所有Key的监控

watch

监视一个或多个key，若在事务执行之前这些key被其他命令改动，那么事务被打断

标记一个事务的开始后，若其中一个命令插入队列出错，则事务中所有命令不会执行。

若事务中获取的是一个不存在的值，执行exec后返回nil,并不影响事务中其他命令的执行。

悲观锁 Pessimistic Lock

很悲观，每次拿数据都认为别人会修改，所以每次拿数据的时候都会上锁。传统关系性数据库用到了很多这种锁机制，如行锁，表锁等，读锁，写锁等，都是在操作之前先上锁。

乐观锁 Optmistic Lock

很乐观，每次拿数据都认为别人不会修改，所以不会上锁，但是在更新的时候会判断别人有没有更新这个数据，可以使用版本号等机制，乐观锁多运用应用类型，可以提高吞吐量。

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

通过watch命令在事务执行之前监控了多个key ,若在watch之后有任何key的值发生了变化，exec命令执行的事务都会被放弃，同时返回Nullmulti-bulk应答以通过调用者事务执行失败。

特性：

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

没有隔离级别的概念：队列中的命令没有提交之前都不会实际的执行，也就不存在“事务内的查询要看到事务里的更新，在事务外的查询不能看到”

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

二.主从复制

常见一主二从

redis> info replication

可查看当前redis是主库还是从库

配从库不配主库

redis> slaveof ip port

设置当前redis是哪个库的从库

从库同步主库数据需要主库和从库的服务都已经启动，主库修改了数据马上会同步到从库。

Slave库不能修改数据，Master库才能修改数据。

Master库shutdown退出了，Slave库不会自动升为Master库。Master库重新启动服务，照样是原来的Master/Slave体系。

Slave库shutdown退出了，在重新启动Slave库服务，并不会自动还原为Slave库，而是Master库，需要重新设置slaceof ip port还原体系。

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

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

slaveof no one

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

复制原理：

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

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

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

增量复制：master继续将新的所有收集到的命令依次传给slave，完成同步。

只要是重新连接master，一次全量复制将被自动执行。

复制的缺点：由于所有写操作都是现在master上操作，然后同步到slave，所有从Master到slave机器上有一定的延迟，当系统很繁忙，延迟问题会更加严重，slave机器数量增加也会加大这个问题。

哨兵模式

redis目录下新建sentinel.conf文件，名字不能错。

vim sentinel.conf

填写内容：

sentinel monitor 被监控主数据库名（自己命名） ip port N

上面最后一个数字N，表示主机挂掉后所有slave投票看让谁接替为主机，得票数多于N的接替。

启动哨兵

redis-sentinel  /.../sentinel.conf