标签：链接 leader auto 独立 write 管理 模拟 目的 下线。
1）使用异步复制。
2）一个主服务器可以有多个从服务器。从服务器也可以有自己的从服务器。
3）复制功能不会阻塞主服务器
4）可以通过复制功能来让主服务器免于执行持久化操作，由从服务器去执行持久化操作即可。
当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。否则的话，由于延迟等问题，部署的服务应该要避免自动拉起。为了帮助理解主服务器关闭持久化时自动拉起的危险性，参考一下以下会导致主从服务器数据全部丢失的例子：
1. 假设节点A为主服务器，并且关闭了持久化。 并且节点B和节点C从节点A复制数据
2. 节点A崩溃，然后由自动拉起服务重启了节点A. 由于节点A的持久化被关闭了，所以重启之后没有任何数据
3. 节点B和节点C将从节点A复制数据，但是A的数据是空的， 于是就把自身保存的数据副本删除。
4）在关闭主服务器上的持久化，并同时开启自动拉起进程的情况下，即便使用Sentinel来实现Redis的高可用性，也是非常危险的。 因为主服务器可能拉起得非常快，以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启，然后还是会执行上面的数据丢失的流程。
无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动拉起。
原理说明：
1. 副本库通过slaveof 10.0.0.51 6379命令,连接主库,并发送SYNC给主库
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.
7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.
8. 如果发生主从临时断开。从库数据没有被破坏的情况下，在下次重连之后，，从库发送PSYNC给主库 (2.8版本之后)
9. 主库只会将从库缺失部分的数据同步给从库应用，达到快速恢复主从的目的
其他说明：
1）SYNC 命令执行示例
2）命令传播
在主从服务器完成同步之后，主服务器每执行一个写命令，它都会将被执行的写命令发送给从服务器执行，这个操作被称为“命令传播”（command propagate）。命令传播是一个持续的过程：只要复制仍在继续，命令传播就会一直进行，使得主从服务器的状态可以一直保持一致
3）复制中的SYNC与PSYNC
①在 Redis 2.8 版本之前， 断线之后重连的从服务器总要执行一次完整重同步（full resynchronization）操作。
②从 Redis 2.8 开始，Redis 使用 PSYNC命令代替 SYNC 命令。PSYNC 比起 SYNC 的最大改进在于 PSYNC 实现了部分重同步（partial resync）特性：在主从服务器断线并且重新连接的时候，只要条件允许，PSYNC 可以让主服务器只向从服务器同步断线期间缺失的数据，而不用重新向从服务器同步整个数据库。
SYNC 处理断线重连示例：
PSYNC 处理断线重连示例：
1）在读写分离环境下，客户端向主服务器发送写命令 SET n 10086，主服务器在执行这个写命令之后，向客户端返回回复，并将这个写命令传播给从服务器。
2）接到回复的客户端继续向从服务器发送读命令 GET n ，并且因为网络状态的原因，客户端的 GET命令比主服务器传播的 SET 命令更快到达了从服务器。
3）因为从服务器键 n 的值还未被更新，所以客户端在从服务器读取到的将是一个错误（过期）的 n值。
从 Redis 2.8 开始， 为了保证数据的安全性， 可以通过配置， 让主服务器只在有至少 N 个当前已连接从服务器的情况下， 才执行写命令。不过， 因为 Redis 使用异步复制， 所以主服务器发送的写数据并不一定会被从服务器接收到，因此， 数据丢失的可能性仍然是存在的。
通过以下两个参数保证数据的安全：
min-slaves-to-write <number of slaves> min-slaves-max-lag <number of seconds> 这个特性的运作原理： 从服务器以每秒一次的频率 PING 主服务器一次， 并报告复制流的处理情况。 主服务器会记录各个从服务器最后一次向它发送 PING 的时间。 1）用户可以通过配置， 指定网络延迟的最大值 min-slaves-max-lag ，以及执行写操作所需的至少从服务器数量 min-slaves-to-write 。如果至少有 min-slaves-to-write 个从服务器， 并且这些服务器的延迟值都少于 min-slaves-max-lag秒，那么主服务器就会执行客户端请求的写操作。 2）另一方面， 如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件， 那么写操作就不会被执行，主服务器会向请求执行写操作的客户端返回一个错误。
准备两个或两个以上redis实例：主节点：6380 从节点：6381、6382
mkdir /data/638{0..2}2）配置文件
cat >>/data/6380/redis.conf<<EOF port 6380 daemonize yes pidfile /data/6380/redis.pid loglevel notice logfile "/data/6380/redis.log" dbfilename dump.rdb dir /data/6380 requirepass 123 masterauth 123 EOF cat >>/data/6381/redis.conf<<EOF port 6381 daemonize yes pidfile /data/6381/redis.pid loglevel notice logfile "/data/6381/redis.log" dbfilename dump.rdb dir /data/6381 requirepass 123 masterauth 123 EOF cat >>/data/6382/redis.conf<<EOF port 6382 daemonize yes pidfile /data/6382/redis.pid loglevel notice logfile "/data/6382/redis.log" dbfilename dump.rdb dir /data/6382 requirepass 123 masterauth 123 EOF
3）启动
redis-server /data/6380/redis.conf redis-server /data/6381/redis.conf redis-server /data/6382/redis.conf ps -ef|grep redis
4）开启主从
6381/6382命令行上操作
redis-cli -p 6381 -a 123 SLAVEOF 127.0.0.1 6380 redis-cli -p 6382 -a 123 SLAVEOF 127.0.0.1 6380
5）查询主从状态
redis-cli -p 6380 -a 123 info replication redis-cli -p 6381 -a 123 info replication redis-cli -p 6382 -a 123 info replication
示例：
[root@redis-master ~]# redis-cli -p 6380 -a 123 info replication # Replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=6381,state=online,offset=1,lag=1 slave1:ip=127.0.0.1,port=6382,state=online,offset=1,lag=1 master_repl_offset:1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:0 [root@redis-master ~]# redis-cli -p 6381 -a 123 info replication # Replication role:slave master_host:127.0.0.1 master_port:6380 master_link_status:up master_last_io_seconds_ago:8 master_sync_in_progress:0 slave_repl_offset:1 slave_priority:100 slave_read_only:1 connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 [root@redis-master ~]# redis-cli -p 6382 -a 123 info replication # Replication role:slave master_host:127.0.0.1 master_port:6380 master_link_status:up master_last_io_seconds_ago:2 master_sync_in_progress:0 slave_repl_offset:15 slave_priority:100 slave_read_only:1 connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0
1）模拟主库故障
redis-cli -p 6380 -a 123 shutdown
2）解除主从关系
redis-cli -p 6381 -a 123 info replication slaveof no one
3）重新设置主从
#6382连接到6381： redis-cli -p 6382 -a 123 SLAVEOF no one SLAVEOF 127.0.0.1 6381 #6382作为6381的从库
Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。
Sentinel 是一个监视器，它可以根据被监视实例的身份和状态来判断应该执行何种动作。
1）监控（Monitoring）：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
2）提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3）自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。
4）应用透明 ==>相当于mysql MHA vip功能
---------------------------------------------------------------------------------------------------------------------------------------------------
1）发现并连接主服务器
Sentinel 通过用户给定的配置文件来发现主服务器。Sentinel 会与被监视的主服务器创建两个网络连接：
2）发现并连接从服务器
Sentinel 通过向主服务器发送 INFO 命令来自动获得所有从服务器的地址。跟主服务器一样，Sentinel 会与每个被发现的从服务器创建命令连接和订阅连接
3）发现其他 Sentinel
Sentinel 会通过命令连接向被监视的主从服务器发送 “HELLO” 信息，该消息包含 Sentinel 的 IP、端口号、ID 等内容，以此来向其他 Sentinel 宣告自己的存在。与此同时Sentinel 会通过订阅连接接收其他 Sentinel 的“HELLO” 信息，以此来发现监视同一个主服务器的其他 Sentinel 。sentinel1 通过发送HELLO 信息来让sentinel2 和 sentinel3发现自己，其他两个sentinel 也会进行类似的操作。
4）多个Sentienl之间的链接
Sentinel 之间只会互相创建命令连接，用于进行通信。因为已经有主从服务器作为发送和接收 HELLO 信息的中介，所以 Sentinel之间不会创建订阅连接。
5）检测实例的状态
Sentinel 使用 PING 命令来检测实例的状态：如果实例在指定的时间内没有返回回复，或者返回错误的回复，那么该实例会被 Sentinel 判断为下线
Redis 的 Sentinel 中关于下线（down）有两个不同的概念：
①主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
②客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。 （一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内， 对向它发送 PING 命令的 Sentinel 返回一个有效回复（valid reply）， 那么 Sentinel 就会将这个服务器标记为主观下线。
6）故障转移FAILOVER
一次故障转移操作由以下步骤组成：
①发现主服务器已经进入客观下线状态。
②基于Raft leader election 协议 ， 进行投票选举
③如果当选失败，那么在设定的故障迁移超时时间的两倍之后，重新尝试当选。 如果当选成功， 那么执行以下步骤。
④选出一个从服务器，并将它升级为主服务器。
⑤向被选中的从服务器发送 SLAVEOF NO ONE 命令，让它转变为主服务器。
⑥通过发布与订阅功能， 将更新后的配置传播给所有其他 Sentinel ，其他 Sentinel 对它们自己的配置进行更新。
⑦向已下线主服务器的从服务器发送 SLAVEOF 命令，让它们去复制新的主服务器。
⑧当所有从服务器都已经开始复制新的主服务器时， leader Sentinel 终止这次故障迁移操作。
标签：链接 leader auto 独立 write 管理 模拟 目的 下线。
原文地址：https://www.cnblogs.com/hujinzhong/p/11620643.html
