Redis(3)

Redis事务

开启事务： MULYTI ##会将所有操作放入一个队列

执行事务:  EXEC   ##开始执行队列里面的命令

放弃事务： DISCARD ##放弃事务快里面的命令

如果队列中一个命令执行错误(例如 qqwe 123类似于java的Error)所有命令均会失败（全体失败）

如果队列中一个命令执行异常（例如对字符串 +1  类似java的Exception）只有该命名会执行失败，其他命令正常执行。

Redis Watch 监控

悲观锁/乐观锁/CAS(check and set )

悲观锁：对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。

乐观锁介绍：（乐观锁主要用于抢红包，淘宝抢购，秒杀之类）

乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。那么如何实现乐观锁呢，一般来说有以下2种方式： 

1. 使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。在数据更新之前判断版本号

     2.增加时间戳

watch：监视一个或多个key，如果在事务执行之前这些key被其他命令改动过，那么事务将会被打断

unwatch：取消watch对所有key的监视

Redis的发布/订阅

publish c1 helloword ##发布

subscribe  c1 c2 c3 ##订阅 c1 可收到消息helloworld

psubscribe  news* ##支持通配符 以news开头的

Redis的Master/Slaver（主写从读）

一主二从

1.配从库不配主库

2.从库配置：slaveof 主库IP 端口号 (从库每次与master断开之后，都需要重新连接  info replication ##查看信息  )

3.配置文件：

1）.每个从库都复制一份redis.conf文件

2）在conf文件中开启deamonize  yes

3）指定pid文件名字

4）指定端口号

5）Log日志文件名

6）dump.rdb文件名

4.启动

1）各自用各自的配置文件启动服务，客户端启动 

 info replication ##查看信息

2）主库(6379)增加模拟数据，从库 slaveof  127.0.0.1 6379备份主库数据

case1：丛机会把主机所有数据copy一份，不管丛机什么时候slaveof主机。

case2：主机挂掉，丛机待命。主机恢复后，仍然是master。

case2：从机挂掉，需要重新与主机相连才能恢复数据。

薪火相传

上一个slave可以是下一个slave的Master，Slave同样可以接收其他Slave的连接与同步请求，那么该Slave为下一个的master，可以有效减轻主master

的写压力

从机中途变更转向：会清初之前的数据，重新建立拷贝最新的 依然是命令 slaveof 主机ip 端口号

反客为主

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

复制原理

Slave连接成功到master会向后台发送一个sync的命令，master收到命令后，开启存盘进程，将整个数据集送到slave，以完成同步

全量复制：slave服务收到master传来的文件，将其全盘存到内存中

增量复制：Master将新的指令集传给slave。完成同步 。但只要是重新连接到master都会全量复制。

哨兵模式*

1、哨兵机制简介(反客为主的自动版)

1）Sentinel(哨兵) 进程是用于监控 Redis 集群中 Master 主服务器工作的状态

2）在 Master 主服务器发生故障的时候，可以实现 Master 和 Slave 服务器的切换，保证系统的高可用（High Availability）

①新建sentinel.conf文件，编辑 sentinel monitor  被监控的主机 (pid)  主机ip   端口号

②启动哨兵 Redis-sentinel  /配置文件

哨兵会监控配置的主机，当主机挂掉时，会通过投票选举的方式将其中的一个从机推成主机。

缺点

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