标签：优先 tor 网络传输 操作 怎么 节点 start err aof
玩法原则:
1.配从不配主
2.使用命令 SLAVEOF 动态指定主从关系 ，如果设置了密码，关联后使用 config set masterauth 密码
3.配置文件和命令混合使用时，如果混合使用，动态指定了主从，请注意一定要修改对应的配置文件
玩法基本步骤：
1.新建redis8000,redis8001,redis8002文件夹
2.将redis.conf文件复制在redis8000下
3.分别修改个目录下的redis.conf文件
redis8000/redis.conf：
1.bind 192.168.0.104 指定本机ip 2.port 8000 3.daemonize yes 4.pidfile /var/run/redis_8000.pid 5.dir /myredis/redis8000 6.requirepass 123456 4.把redis8000/redis.conf文件复制到redis8001,redis8002下
redis8001/redis.conf
1. :%s/8000/8001/g 批量替换 2. replicaof 192.168.0.104 8000 3. masterauth 123456
redis8002/redis.conf
1. :%s/8000/8002/g 批量替换 2. replicaof 192.168.0.104 8000 3. masterauth 123456
4.分别启动8000.8001,8002实例
[root@localhost myredis]# /usr/local/bin/redis-server /myredis/redis8000/redis.conf [root@localhost myredis]# /usr/local/bin/redis-server /myredis/redis8001/redis.conf [root@localhost myredis]# /usr/local/bin/redis-server /myredis/redis8002/redis.conf
5.客户端连接
/usr/local/bin/redis-cli -h 192.168.0.104 -p 8000 -a 123456 /usr/local/bin/redis-cli -h 192.168.0.104 -p 8001 -a 123456 /usr/local/bin/redis-cli -h 192.168.0.104 -p 8002 -a 123456
建立连接
1.设置master的地址和端口，发送slaveof ip port指令，master会返回响应客户端，根据响应信息保存master ip port信息 (连接测试)
2.根据保存的信息创建连接master的socket
3.周期性发送ping，master会响应pong
4.发送指令 auth password（身份验证），master验证身份
5.发送slave端口信息，master保存slave的端口号
数据同步
1.slave发送指令 psyn2
2.master 执行bgsave
3.在第一个salve连接时，创建命令缓存区
4.生成RDB文件，通过socket发送给slave
5.slave接收RDB，清空数据，执行RDB文件恢复过程
6.发送命令告知RDB恢复已经完成（告知全量复制完成）
7.master发送复制缓冲区信息
8.slave接收信息，执行重写后恢复数据
注意： master会保存slave从我这里拿走了多少数据，保存salve的偏移量
命令传播
slave心跳：replconf ack {offset} 汇报slave自己的offset，获取最新数据指令
命令传播阶段出现断网：
全量复制核心三个要素
1.bgsave时间
2.rdb文件网络传输
3.从节点请求请求数据时间
4.从节点加载rdb的时间
5.可能的aof重写时间
1.由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
2.当主机宕机之后，将不能进行写操作，需要手动将从机升级为主机，从机需要重新制定master
简单总结：
一个master可以有多个Slave
一个slave只能有一个master
数据流向是单向的，只能从主到从
在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。
通俗来讲哨兵模式的出现是就是为了解决我们主从复制模式中需要我们人为操作的东西变为自动版，并且它比人为要更及时
监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。
自动故障转移（Automatic Failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
配置提供者（Configuration Provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
通知（Notification）：哨兵可以将故障转移的结果发送给客户端。
其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。
哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的Redis节点，不存储数据。
数据节点：主节点和从节点都是数据节点。
哨兵系统中的主从节点，与普通的主从节点配置是一样的，并不需要做任何额外配置。下面分别是主节点（port=8000）和2个从节点（port=8001/8002）的配置文件；
上面搭建的主从复制就是主从节点
哨兵节点本质上是特殊的Redis节点。
3个哨兵节点的配置几乎是完全一样的，主要区别在于端口号的不同（26379 / 26380 / 26381）下面以26379节点为例介绍节点的配置和启动方式；配置部分尽量简化：
sentinel-26379.conf
port 26379 daemonize yes logfile "26379.log" sentinel monitor mymaster 192.168.0.104 6379 2
其中，sentinel monitor mymaster 192.168. 92.128 6379 2配置的含义是：该哨兵节点监92.168.0.104 6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。
哨兵节点的启动有两种方式，二者作用是完全相同的：
redis-sentinel sentinel-26379.conf
redis-server sentinel-26379.conf --sentinel
使用kill命令杀掉主节点即可看到效果
public static void main(String[] args) {
Logger logger= LoggerFactory.getLogger(TestJedisSentinel.class);
Set<String> set=new HashSet<>();
set.add("192.168.0.104:28000");
set.add("192.168.0.104:28001");
set.add("192.168.0.104:28002");
JedisSentinelPool jedisSentinelPool=new JedisSentinelPool("mymaster",set,"123456");
while (true) {
Jedis jedis=null;
try {
jedis = jedisSentinelPool.getResource();
String s = UUID.randomUUID().toString();
jedis.set("k" + s, "v" + s);
System.out.println(jedis.get("k" + s));
Thread.sleep(1000);
}catch (Exception e){
logger.error(e.getMessage());
}finally {
if(jedis!=null){
jedis.close();
}
}
}
}
关于哨兵的原理，关键是了解以下几个概念：
主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。
客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。
需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。
定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：
1.每10秒通过向主从节点发送info命令获取最新的主从结构；
发现slave节点
确定主从关系
2.每2秒通过发布订阅功能获取其他哨兵节点的信息；SUBSCRIBE c2 PUBLISH c2 hello-redis
交互对节点的“看法”和自身情况
3.每1秒通过向其他节点发送ping命令进行心跳检测，判断是否下线（monitor）。
心跳检测，失败判断依据
选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。
监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。
故障转移：选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：
在从节点中选择新的主节点：选择的原则是，
1.首先过滤掉不健康的从节点；
2.过滤响应慢的节点
3.过滤与master断开时间最久的
4.优先原则
先选择优先级最高的从节点（由replica-priority指定）；如果优先级无法区分，
则选择复制偏移量最大的从节点；如果仍无法区分，
则选择runid最小的从节点。
更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
将已经下线的主节点（即6379）保持关注，当6379从新上线后设置为新的主节点的从节点
哨兵节点的数量应不止一个。一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈；另一方面减少对下线的误判。此外，这些不同的哨兵节点应部署在不同的物理机上。
哨兵节点的数量应该是奇数，便于哨兵通过投票做出“决策”：领导者选举的决策、客观下线的决策等。
各个哨兵节点的配置应一致，包括硬件、参数等；此外应保证时间准确、一致。
在主从复制的基础上，哨兵引入了主节点的自动故障转移，进一步提高了Redis的高可用性；
但是哨兵的缺陷同样很明显：哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要我们对从节点做额外的监控、切换操作。
此外，哨兵模式仍然没有解决写操作无法负载均衡、及存储能力受到单机限制的问题
标签：优先 tor 网络传输 操作 怎么 节点 start err aof
原文地址：https://www.cnblogs.com/tongxuping/p/12356650.html
