Redis： 热点 高频 读写
行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动的同步到备机的master/slave机制。master以写为主，slave以读为主。
主要功能就是： 读写分离，容灾恢复
具体怎么玩，往下接着来
- 配从（库）不配主（库）
- 从库配置：
slave主库IP主库端口
每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件
Info replication 得到当前数据库的角色信息
SLAVEOF 列 slaveof 127.0.0.1 3679备份连接到本机的Redis数据库
（中心化过于严重 非中心化操作减轻主机的负担 由于复制延长可能会失贞） - 修改配置文件细节操作
- 拷贝对个Redis.conf文件
- 开启 daemonize yes
- Pid文件名字
- 指定端口
- Log文件名字
- Dump.rdb 名字
- 常用3招
- 一主二仆
init - 薪火相传：（消除中心化 多个连接主机压力太大）
上一个slave可以是下一个slave的master， slave同样可以接受其他消息。slave的连接和同步请求，那么该slave作为了链条中下一个master，可以有效减轻master的写压力。
中途变更专项：会清除之前的数据，重新建立，拷贝最新的
slaveof新主机库IP新主机库端口 - 反客为主
slavefo no one 是当前数据库停止与其他数据库同步，转成在主数据库。形成新的体系。之前的主机回来后又是一个单独的体系
（通过这个命令将丛机转为主机）
复制原理
- slave启动成功连接到master后会发送一个sync命令
- master接到命令启动后台的磁盘进程。同时收集所有接受到的用于修改数据集命令。
在后台进程执行完毕后，master将传送整个数据文件到slave，已完成一次完全同步。
先是（首次）全量复制： 而slave服务在接受到数据库文件数据后，将其存盘并加载到内存缓存中。
后是（其次）增量复制： master继续将新的所有收集到的修改命令依次传给slave，完成同步。
哨兵模式（重点，就是反客为主的升级版）
反客为主的自动版，能够后台监控主机是否故障，如果故障投票数自动将从库转换为主库
如何操作，如下
- 调整结构，6379带着80 ， 81两个端口的备机（我只有一个电脑 只能模拟一下）
- 自定义 /myRedis的目录下新建 sentinel.conf 文件，名字绝不能错
- 配置哨兵， 填写内容：
sentinel monitor host7379 127.0.0.1 6379 1
// sentinel monitor 被监控主机数据库名字 (名字自己起哦） 127.0.0.1 6379 1
// 上面最后一个 1 ，表示主机挂掉后slave投票看让谁接替成为主机，得票数多的成为主机
- 启动哨兵：
Redis-sentinel /myreids/sentinel.conf
// Redis-sentinel 路径 sentinel.conf
一组sentinel能同时监控多个 master
就是有个哨兵在巡岗，谁的数据多谁来做master主库。
touch 创建新文件 sentinel.conf 文件
复制延时
由于所有的写操作都是在master上 操作，然后同步更新到slave上，所以master同步到slave机器有一定的延迟。
当系统很忙的时候，延迟的问题会更加严重，slave机器数量的增加也会是这个问题更加严重