Redis是Remote Dictionary Server的缩写。本质上一个Key/Value数据库，与Memcached类似的NoSQL型数据库，但是数据可以持久化的保存在磁盘上，解决了服务重启后数据丢失的问题，值可以是string(字符串)、list(列表)、sets(集合)或者是ordered sets(被排序的集合)，所有的数据类型都具有push/pop、add/remove、执行服务端的并集、交集、两个sets集中的差别等等操作，这些操作都是具有原子性的，Redis还支持各种不同的排序能力特意设计为从核心支持硬件，几乎没有对硬件的要求或限制。核心在小端格式的硬件上运行，主要是x86/x86_64处理器。客户端库（例如驱动）可以在大端或小端格式的系统中运行。
redis 官网：https://redis.io/
redis 在生产当中一般有四种场景：单机，主从，哨兵，集群。单机模式比较简单，没什么可说的。使用最多的为哨兵和集群。本次基于主从模式和哨兵模式的故障演练。
redis 安装比较简单，安装前需要安装依赖，gcc make tcl。
可以直接 用 yum -y install gcc make tcl 也可以用源码编译或 rpm 包安装，根据自身情况自选。接下来我们先进行 redis 的一主两从环境搭建以及手动故障演练。
主配：
daemonize yes
port 6379
logfile ./redis6379.log
dir ./
bind 192.168.10.1
从1配：
daemonize yes
port 6380
logfile ./redis6380.log
dir ./
bind 192.168.10.1
slaveof 192.168.10.1 6379
slave-read-only yes--设置从库只读
从2配：
daemonize yes
port 6381
logfile ./redis6381.log
dir ./
bind 192.168.10.1
slaveof 192.168.10.1 6379
slave-read-only启动主从：
之后进行登录主节点和两个从节点，进行查看主从信息：可以看到 master的状态为 up。
可以在主库赋值一个key，然后去从库上查看进行验证。主库端口：6379，从库端口：6380，6381
手动切换主从模式故障演练：先关闭主库，进行shutdown。然后在两个从库上进行查看信息，可以看到主库已经down了。
在从库的6380节点上执行 slaveof no one。
然后在6380的从节点上，运行 info 再查看效果：可以看到这个时候从库的角色已经成为主库了，反从为主。
这个时候重新启动刚开始的主库6379端口，可以看到6379已经变成从库了。
最终主库由6379变成了6380。
这个是手动切换一主两从故障演练。接下来进行哨兵模式的搭建，模拟故障自动切换。
再进行哨兵模拟前，将6379恢复为主库，6380恢复为从库。哨兵模式可以自动切换，当主库 down 掉后，从库会自动接管。基于主从开始搭建redis哨兵。由于本次是一主两从，3个节点。所以指定了3个哨兵配置文件：可以单独创建目录将redis的配置文件和redis哨兵得配置文件区分开，避免混淆。如下：
主节点哨兵配置：
port 26379
daemonize yes
logfile "26379.log"
dir "./"
#sentinel监控的IP 端口号 sentinel通过投票后认为mater宕机的数量，此处为至少2个
sentinel monitor mymaster 主库ip 6379 2
#60秒ping不通主节点的信息，主观认为master宕机
sentinel down-after-milliseconds mymaster 60000
#故障转移后重新主从复制，1表示串行，>1并行
sentinel parallel-syncs mymaster 1
#故障转移开始，60秒内没有完成，则认为转移失败
sentinel failover-timeout mymaster 600000
bind 服务器ip
从节点哨兵文件配置（两个从节点的哨兵配置文件是一样的，复制一份就可以了）：
查看redis和哨兵进程（全部在一台机器上搞得），看到进程都已经启动了。
接下来登录哨兵节点，查看哨兵节点和redis节点信息：
./redis-cli -h 服务器ip -p 23679
登录后通过 info 命令查看：
重点在最后关于哨兵sentinel得这一段，可以看到节点信息有一个master主节点，两个slave从节点，三个sentinel哨兵节点。这样就把redis的一主两从结合起来了。
下来模拟故障切换演练，当master挂掉后，让新的slave自动接管，并升级为新的master。登录哨兵节点：执行 info sentinel，可以看到6379为主库，有2个从库，3个哨兵节点。
查看哨兵日志，日志中提示+switch-master mymaster ip 6379 ip 6380，可以看到主库由6379自动切换到了 6380.
此时登录6380查看信息，看看是否成为了新的主库：
登录从库 6381 进行查看，还是从库，没有发生改变。
此时在启动down掉的6379库，看看是变成了主库呢还是成为了新的从库。
故障演练成功。
总结：当主库down掉后，会进行投票选举，由哨兵检测并自动去进行切换。在failover之后，原master修复好后会变为新master的从库，并不会变成独立的一台master。
