Lnmp架构之Redis服务

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节点，否则会导致哈希槽不完整，从而导致集群不可用。