Redis-事务
Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证：
- 事务是一个单独的隔离操作，事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
- 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行
事务的上个步骤：
- 开启事务：以MULTI开启一个事务
- 命令入队：将多个命令添加到命令队列中，接到这些命令不会立即执行，而是放到等待执行的事务队列中
- 执行事务：有EXEC执行事务。（或者DISCARD取消执行）
事务相关指令：
|
执行事务出现的四种情况：
- 正常执行：队列中所有的指令全部会被执行。
- 全部取消：队列中的所有指令全部会被取消。
- 全体连坐：如果指令集中有一条在加入队列时报错，则队列中的所有指令全部取消。
- 冤头债主：如果指令已经加入到队列中，但执行失败，只有当前指令失败，其它继续执行。
redis事务的三个特性：
- 单独的隔离性：事务中的所有的命令都会序列化，按顺序执行，事务在执行过程中，不会被其它客户端发送过来的命令请求所打断
- 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新。
- 不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚
watch监控
watch监控表示对需要操作的key添加一个乐观锁，防止另一个用户进行修改，导致结果错误。
- 悲观锁
- 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会被block直到它拿到锁。传统的关系型数据库里面就用到了很多这种锁，比如行锁，表锁，读锁，写锁等，都是在操作之前先上锁。
- 乐观锁
- 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。提交的版本号必须大于当前版本号才可以提交
在访问以写入为目的数据的时候（SOL中的SELECT FOR UPDATE),关系数据库会对被访同的数据行进行加锁，直到事务被提交（Commit）
或者被回滚（ROLLBACK）为止，如果有其他客户端试图对被加锁的数据行进行写入，那么该客户端将被阻塞、直到第一个事务执行完毕为止。加锁在实际使用中非常有效，基本上所有关系数据库都实现了这种加锁功能，它的缺点在于，持有锁的客户端运行越慢，等待解锁的客户端被阻塞的时间就越长。因为加锁有可能会造成长时间的等待，所以Redis为了尽可能地减少客户端的等待时间，并不会在执行WATCH命令时对数据进行加锁，相反地，Redis只会在数据已经被其他客户端抢先修改了的情况下，通知执行了WATCH命令的客户端，
Redis-主从复制
什么是主从复制？
主从复制，是用来建立一个和主数据库（master）完全一样的数据库环境，称为从数据库(slave)。
主从复制的作用和使用场合一般有几个：
- 容灾恢复，主数据库服务器故障后，可迅速从从数据库恢复
- 读写分离、主数据库主要做写的操作，从数据库做读的操作
主从复制应用场景
- 电子商务网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是”多读少写”。
- 对于这种场景，我们可以使如下这种架构
我们将一台Redis服务器作主库(Matser)，其他三台作为从库(Slave)，主库只负责写数据，每次有数据更新都将更新的数据同步到它所有的从库，而从库只负责读数据。这样一来，就有了两个好处：
-
- 数据被复制成了了好几份，就算有一台机器出现故障，也可以使用其他机器的数据快速恢复。
- 读写分离，不仅可以提高服务器的负载能力，并且可以根据读请求的规模自由增加或者减少从库的数量，棒极了；
注意事项：
在Redis主从模式中，一台主库可以拥有多个从库，但是一个从库只能隶属于一个主库
主从复制实现方式
- 一主二仆
- 薪火相传
- 反客为主
一主二仆
一个Master两个或多个Slave
在多台机器上配置好redis环境，并修改相应的配置文件
只需要在从数据库加配置如下代码：
slaveof 主数据库地址 主数据库端口
例如：slaveof 127.0.0.1 6379
如果设置了密码：
masterauth 主库密码
示例在一台机器上面实现一主二仆：
这里是用的windows版本的redis,然后可以根据Windows Service Documentation.docx文档建立后台服务
当主库意外关闭时，从库是什么情况？
当主库关闭时，从库继续保持从库状态，但是和主库的连接丢失，不能在同步更新数据。如果主库恢复，从库也会恢复到连接状态。 当从库1关闭时，主库和从库N都不受影响。但是当从库重新恢复时，丢失和主库的连接状态，必须重新关联。
薪火相传
什么是薪火相传？
上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻master的写压力
中途变更转向:会清除之前的数据，重新建立拷贝最新的
slaveof 新主库IP 新主库端口
薪火相传－演示
1.打开三台服务器（－主二仆）
2.从客户端连接三台服务器，通过指令info replication查询状态
3.将6381的主机修改成6380
语法：slaveof 主机IP 端口
4.再查看效果
反客为主
什么是反客为主？
使当前数据库停止与其他数据库的同步，转成主数据库
指令：SLAVEOF no one
演示：
- 打开三个服务器
- 打开相应的三个客户端
- 将主服务器客户端shutdown
- 将第二个客户端(6380)SLAVEOF no one，反客为主
- 将其他的客户端指向新的master（SLAVEOF 127.0.0.1 6380）
主从复制执行过程：
- 当一个从数据库启动时，会向主数据库发送sync命令。
- Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步。
- 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
- 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步。
- 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行。