1.1 ag真人试玩娱乐官网
行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slave机制，master以写为主，slave以读为主。
1.2 概念
1.2.1 主从复制
主从复制，是指将一台redis服务器的数据，复制到其他的redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower)；数据的复制是单向的，只能由主节点到从节点。master以写为主，slave以读为主。
默认情况下，每台redis服务器都是主节点；
且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能由一个主节点。
1.2.2 主从复制作用
1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2.故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3.负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务(即写redis数据时应用连接主节点，读redis数据时应用连接从节点)，分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高redis服务器的并发量。
4.高可用(集群)基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是redis高可用的基础。
一般来说，要将redis运用于工程项目中，只使用一台redis是万万不能的(宕机)，原因如下：
1.从结构上，单个redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；
2.从容量上，单个redis服务器内存容量有限，就算一台redis服务器内存容量为256g，也不能将所有内存用作redis存储内存，一般来说，单台redis最大使用内存不应该超过20g。
电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是多读少些。
对于这种场景，我们可以使用如下这种架构：
主从复制，读写分离，80%的情况下都是在进行读操作，减缓服务器的压力，架构中经常使用，一主二从。
只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用redis。
2.1 配从不配主
配从库不配主库
2.2 从库配置
- slaveof 主库ip 主库端口
- 每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件
- info replication
2.3 修改配置文件细节操作
1. 拷贝多个redis.conf文件
2. 开启daemonize yes
3.pid文件名字
4.指定端口
5.log文件名字
6.dump.rdb名字
修改完毕之后，启动我们的三个redis服务器，可以通过进程信息查看
2.4 常用三招
2.4.1 一主二仆
1.init
2.一个master两个slave
3.日志查看
主机日志
备机日志
info replication
真实的主从配置应该在配置文件中配置，这样的话是永久的，我们这里使用的是命令，暂时的！
4.主从问题演示
1）切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制？比如从k4进来，那之前的123是否也可以复制
2）从机是否可以写？set可否？
3）主机shutdown后情况如何？从机是上位还是原地待命？
4）主机又回来了后，主机新增记录，从机还能否顺利复制？
5. 其中一台从机down后情况如何？依照原有它能跟上大部队吗？
2.4.2 薪火相传
上一个slave可以是下一个slave的master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master，可以有效减轻master的写压力
中途变更转向：会清除之前的数据，重新建立拷贝最新的
slaveof 新主库ip 新主库端口
2.4.3 反客为主
salveof no one: 使当前数据库停止与其它数据库的同步，转成主数据库
slave启动成功连接到master后会发送一个sync命令
master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：master继续将新的所有收集到的修改命令依次传给slave，完成同步
但是只要是重新连接master，一次完全同步(全量复制)将自动执行。
4.1 是什么
自动选举老大的模式
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费时费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。redis从2.8开始正式提供了sentinel(哨兵)架构来解决这个问题。
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
哨兵模式是一种特殊的模式，首先redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待redis服务器响应，从而监控运行的多个redis实例。
这里的哨兵有两个作用：
通过发送命令，让redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
然而一个哨兵进程对redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。
4.2 怎么玩
1. 调整结构，6379带着80、81
自定义的/myredis目录下新建sentinel.conf文件，名字绝对不能错
2. 配置哨兵，填写内容
sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1上面最后一个数字1，表示主机挂掉后slave投票看让谁接替成为主机，得票数多的成为主机
3.启动哨兵
redis-sentinel /myredis/sentinel.conf
上述目录依据各自的实际情况配置，可能目录不同
4. 主从演示
如果master节点断开了，这个时候就会从从机中随机选择一个服务器！(这里面有一个投票算法！)
哨兵日志
如果主机此时回来了，只能归并到新的主机下，当作从机，这就是哨兵模式的规则。
5.原有的master挂了
6.投票选举
7.重新主从继续开工，info replication查看
8.问题：如果之前的master重启回来，会不会双master冲突？
一组sentinel能同时监控多个master
4.3 哨兵模式优缺点
4.3.1 优点
1.哨兵集群，基于主从复制模式，所有的主从配置优点，它全有
2.主从可以切换，故障可以转移，系统的可用性就会更好
3.哨兵模式就是主从模式的升级，手动到自动，更加健壮
4.3.2 缺点
1.redis不好在线扩容，集群容量一旦到达上限，在线扩容就十分麻烦！
2.实现哨兵模式的配置其实是很麻烦的，里面有很多选择！
3.复制的缺点：复制延时，由于所有的写操作都是先在master上操作，然后同步更新到slave上，所以从master同步到slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会使这个问题更加严重。
4.4 哨兵模式的全部配置
# example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379
port 26379
# 哨兵sentinel的工作目录
dir /tmp
# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母a-z、数字0-9 、这三个字符".-_"组成。
# quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
# sentinel monitor
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在redis实例中开启了requirepass foobared 授权密码 这样所有连接redis实例的客户端都要提供
密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass
sentinel auth-pass mymaster mysuper--secret-0123passw0rd
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds
sentinel down-after-milliseconds mymaster 30000
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那
里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，
slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout
sentinel failover-timeout mymaster 180000
# scripts execution
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知
相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个sigkill信号终止，之后重新执行。
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），
将会去调用这个脚本，这时这个脚本应该通过邮件，sms等方式去通知系统管理员关于系统不正常运行的信
息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配
置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无
法正常启动成功。
#通知脚本
# shell编程
# sentinel notification-script
sentinel notification-script mymaster /var/redis/notify.sh
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已
经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
#
# 目前总是“failover”,
# 是“leader”或者“observer”中的一个。
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通
信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由运维来配
置！