1、redis部署
停掉mysql服务
如果在纯净的环境下，make的时候需要安装gcc和make
redis服务常用命令
2、redis主从同步
复制文件发送到接收主机server2，server3
server2，server3接收到文件后，和11master端一样的配置方法
3、redis主从复制
设置11为master，12，13为slave
在12上
其他slave节点以此类推
此时在master端11上
slave角色只能读，并没有修改的权限
在master端
在slave端会同步内容
4、Redis高可用
redis主从切换
redis 主从原理：基于rdb 快照实现。
在执行主从的时候，slave和master要先做一个认证，发起一个同步请求，master会执行一个bgsave(异步模式)/save(阻塞模式)，异步模式的时候，bgsave会做一个rdb快照,然后把rdb快照发给slave,slave会做一个动作，清掉slave端所有的数据（flushall）,然后slave会再次加载快照；
快照做完之后，还会有变更数据，所以放在缓存里面，然后接下来会用replicationfeedslave()增量函数 一条一条发给slave,然后再给slave端做同步，因此，redis主从是基于rdb快照格式出现的。
redis和mysql的二进制日志的差别是其数据类型不同。
redis主从基于rdb快照格式实现
一主多从的架构中，redis里自带高可用切换
2表示必须要两个节点说master出故障了才能发起故障切换；
当第一个节点发现master出现故障会进入一种主观下线状态，当第二个节点发现master出现故障 会再次进入一种主观下线状态；
两次的主观下线会触发一次客观下线，这个时候master会开始真正进行主从切换，三个节点就设置为2，两个节点就设置为1
拷贝修改后的文件到其他节点
注：必须在启动前拷贝过去，启动后文件会发生改变，拷贝过去会报错
其他主机直接启动服务，无需更改配置文件（哨兵模式）
此时，再开启一个终端11并关闭master
当master出问题时，redis集群会自动切换master
当原来的master再次启动后，会以slave的身份加入集群
在切换的时候可能会出现的问题：
客户端到master没什么问题，master 到slave端的网络如果出现故障，这个时候集群就会以为master出现问题，把master踢出去，选举出新的master；
当网络又恢复正常，原来的master会同步当前集群的配置，把自己变成slave，接入到新的master；
然而客户端到master是好的，这个时候，客户端会持续往master里写入数据，这些写入的数据就会因此而丢失。
解决方法：
必需保证后端有两个slave可以写；
添加 min-slave-to-write=2 到配置文件，保证在主从切换的时候 客户端不要给master里面写 ，如果master发现都连不上两个slave 就不要往里面写入数据了，避免数据丢失。
5、Redis集群
无中心化设计：每个节点都可以接入集群，不管是主从都可以进行读写，在接入集群之后都可以做调度，做重定向。但是，它的整合度太高，二次开发成本太高。
自动生成集群脚本（会在当前的目录里生成对应的配置文件和数据）
启动自动生成脚本
查看帮助命令（redis-cli --help）
获取集群状态
获取集群详细信息
redis-cli --cluster作用：将16384个存储数据的哈希槽均摊到三个master上进行存储，每个节点都会分配到一定的哈希槽。
连接集群
关闭redis，集群中对应的master和slave就会自动切换
down掉30002
此时，数据保存在30005上不会丢失
再次启动脚本，被down掉的30002会重新恢复，并且恢复后会成为slave
导致集群不可用的情况：
（1）16384个哈希槽不完整时，集群不可用
（2）同一个集群的半数master同时挂掉时，集群不可用
再添加两个redis实例
在线添加集群节点
添加master节点
新的master节点没有hash槽
添加slave节点
给新增的master节点迁移hash槽
新增节点完成
注：在删除某个master节点时，要先将该节点上的哈希槽迁移到别的maser节点，否则会导致哈希槽不完整，从而导致集群不可用。
