一、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机器数量的增加也会使这个问题更加严重。