Redis

1.Redis的事务

第一次接触到事务是在MySQL的学习中。在这里，我们开启事务并进行一系列的读写操作。事务的作用，就是让这一系列的操作拥有统一的结果，要么全部成功，要不全部失败（准确来说是让这一系列的操作全不生效）。
而在Redis中的事务，是指把一系列的命令看作一个整体，然后按照顺序一次性的执行。

multi    					// 开启事务
set   ...   				//命令1入队
get   ...   				//命令2入队
sadd  ...   				//命令3入队
exec 						// 执行事务
discard						// 取消事务

如上，在Redis中，用multi表示开启一个事务，然后所写的一系列命令都将加入这个事务中，最后用exec标明执行这个事务。既然说这是一个事务，也就是说，这些命令要么全部成功，要么全部失败。可以看到，当我们开启一个事务时，所有的操作都不会执行，而是被有序的加入到一个队列中，只有输入事务执行标记exec时，队列中的命令才会依次执行，并在其下展示执行结果。

可以看到，当队列中某个指令出现错误时，它之前的指令也不能生效了。当然，这里的错误是语法本身的问题，但也有出现语法正确，但是在执行过程中出现了错误，这时，就只有执行错误的那条指令不会生效，并不影响其他的指令。

2.Redis的持久化

redis本身运行时数据保存在内存中，在关闭redis的进程或者关闭计算机后数据肯定被会操作系统从内存中清掉。那么如果下次使用redis时怎么获取以前的数据呢？我们在本机使用redis的时候似乎从来没有遇到这样的问题，那是因为redis有着默认的数据持久化机制–RDB。
RDB方式采用的思想是定时将内存中的数据进行快照，并写入dump.rdb文件当中，这个文件当中所存储的就是当前redis环境中的配置以及数据。每次当redis重启之后，redis会先读dump.rdb文件，将数据从硬盘写入到内存中。
在redis的配置文件中有这样一段代码

save 900 1                    //  表示每900秒内有1次更改时，就进行数据的备份
save 300 10
save 60 10000    

缺点： 周期性备份，如果请求量过大，分钟级别的备份周期相对来说较长。若服务器宕机仍会丢失大量数据。

AOF（append only file）是Redis提供了另外一种持久化机制。与RDB记录数据不同，当开启AOF持久化后，Redis会将客户端发送的所有更改数据的命令，记录到磁盘中的AOF文件。 这样的话，当Redis重启后，通过读取AOF文件，按顺序获取到记录的数据修改命令，即可完成数据恢复。

appendfsync参数，三个取值：

always: 每个事件周期都同步刷新一次
everysec: 每一秒都同步刷新一次
no: 我只管写，让操作系统自己决定什么时候真正写入吧

在记录写操作时，很有可能出现对同一数据的多次操作，那么记录所有的操作时没有意义的。完全可以直接记录该数据的最终状态，这样不仅减少AOF文件占用的存储空间，也减少了还原数据时的时间。这种操作，叫做AOF的重写。

3.Redis主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)。数据的复制是单向的，只能由主节点到从节点。
默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。
作用:
读写分离；只能主写从读
容灾恢复；如果主机挂了，根据数据同步，把其备机设置为新的主机。

Redis主从复制分为以下三种方式：
一、当master服务器与slave服务器正常连接时，master服务器会发送数据命令流给slave服务器,将自身数据的改变复制到slave服务器。
二、当因为各种原因master服务器与slave服务器断开后，slave服务器在重新连上master服务器时会尝试重新获取断开后未同步的数据即部分同步，或者称为部分复制。
三、如果无法部分同步(比如初次同步)，则会请求进行全量同步，这时master服务器会将自己的rdb文件发送给slave服务器进行数据同步，并记录同步期间的其他写入，再发送给slave服务器，以达到完全同步的目的，这种方式称为全量复制。

哨兵模式

主从模式下，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这种方式并不推荐，实际生产中，我们优先考虑哨兵模式。这种模式下，master宕机，哨兵会自动选举master并将其他的slave指向新的master。