写在前面

redis作为一款高速缓存数据库，在解决系统速度问题上有颇大的成就， 那么今天就带大家了解下redis底层都做了哪些事情，本文章需要你有一定的redis基础，适合想要更深入了解redis底层机制的同学，如果你在过程中有不懂得地方，欢迎在评论区提问！在下一定知无不言；

注意事项

默认情况下，从节点不允许写操作，只能从主节点同步数据过来；可在配置文件中配置为可写的操作

主从复制配置和启动

先启动三个redis，分别为6379、6380、6381端口，其中6379为主节点,其他2个redis跟随6379；

启动主节点

./redis-server /etc/redis/6379.conf

启动6380从节点，启动后需要追随主节点， 追随有3种方式

1、 启动redis时追随，—后面的跟随命令也可以在登录reids后在命令行执行

# 5.0版本以前 , slaveof 表示跟随的节点，后面2个参数是ip和端口
./redis-server /etc/redis/6380.conf --slaveof 127.0.0.1 6379
# 5.0版本以后，replicaof 表示跟随的节点，后面2个参数是ip和端口
./redis-server /etc/redis/6380.conf --replicaof 127.0.0.1 6379

2、 在命令行追随，启动redisserver端后，使用redis-cli客户端连接服务端，输入以下命令即可

replicaof 127.0.0.1 6379

3、 在配置文件种追随，找到对应节点的 conf配置文件，找到以下配置，replicaof默认是被注释的，放开注释并加上ip和端口即可；

replicaof 127.0.0.1 6379

启动6381从节点，—后面的跟随命令也可以在登录reids后在命令行执行

# 5.0版本以后，replicaof 表示跟随的节点，后面2个参数是ip和端口
./redis-server /etc/redis/6381.conf --replicaof 127.0.0.1 6379

首次跟随主节点时，会先将从节点的数据全部删除，在将主节点的数据同步到从节点；并且，默认情况下从节点就只能读取，不能在写入，如果需要写入，可在配置文件中修改以下选项改为no即可;默认为yes（只读）

# 只读模式，默认开启
replica-read-only yes;

不想跟随别人了，自己当老大

当reids的从节点不像追随某个主节点了，想要自己当主节点，输入以下命令即可；

replicaof no one

主从同步方式

有2种方式同步数据

1. 默认第一种是先将数据以RDB方式持久化到主节点磁盘，然后通过网络将rdb文件传到从节点
2. 第二种是直接用网络的方式将数据传输到从节点；

同步方式可通过以下方式进行配置

# 默认 no 为磁盘同步，改为yes则直连同步
repl-diskless-sync no

增量同步

从节点第一次跟随主节点时会同步主节点的全量数据， 当主节点修改了数据，这些修改后的数据需要同步到从节点种，不可能每次修改都全量同步，数据量太大的话花费的时候就很长，这时候就需用到增量同步了，主节点内部维护了一个队列，队列里面存储都是修改的命令，队列里面有一个offset（偏移量），告诉你数据修改到哪了，这个队列默认大小为1MB，如果队列里面的数据大于1MB了，就会触发全量同步；

哨兵机制 sentinel

redis的哨兵机制是用来实现高可用的，也就是当直节点挂掉之后，哨兵进程会在从节点中选出一个节点晋升为主节点；从而保证redis高可用；

启动哨兵进程

因为哨兵是一个进程，是需要占用端口的，所以在启动哨兵前，需要先对哨兵进行配置，哨兵配置时只要配置对主节点的监控即可，新建一个文件 26379.conf，内容如下

port 26379
# monitor表示定期监控哨兵节点，
# mymaster是哨兵的名称，名字随便起，因为哨兵也是集群的，所以集群下每个哨兵进程的名称也是一样的；这样就可以做到一套哨兵控制多套主从复制集群； 
# 127.0.0.1 6379 是主节点的ip和端口
# 最后的2 是<quorum>，表示的是哨兵判断主节点是否发生故障的票数。也就是说如果我们将<quorum>设置为2就代表至少要有两个哨兵认为主节点故障了，才算这个主节点是客观下线的了，一般是设置为sentinel节点数的一半加一。
sentinel monitor mymaster 127.0.0.1 6379 2

启动哨兵，启动前必须先启动redis主节点

 # --sentinel表示以哨兵机制启动
 redis-server ./26379.conf --sentinel

启动后，哨兵进程会修改 26379.conf 配置文件，热别是当主节点宕机后，会将26379.conf配置文件里面的主节点ip和端口都更换成新的主节点ip端口；并会附带一些其他信息；

哨兵机制的底层原理

A、监控任务

在哨兵内部有三个定时监控任务，用来实时监控哨兵进程和redis进程

1、每10秒发一次info到主从节点

每个哨兵节点每10秒会向主节点和从节点发送info命令获取最新拓扑结构图，哨兵配置时只要配置对主节点的监控即可(sentinel monitor mymaster 127.0.0.1 26379 2)，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到；

2、每2秒发送一次各节点的信息给主节点

每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的；

3、每隔1秒发送一次心跳
每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据；

B、哨兵选举领导过程（Paxos算法）

redis选主过程使用了非常强大的Paxos算法，因为强大，所以它的内部实现非常复杂，以下介绍Paxos算法的大致流程；

哨兵和redis一样，也有主从节点，哨兵的主节点叫做领导者，当领导者挂了、或者产生故障了，可能是网络原因，也可能是程序自身原因；导致主节点不可用了；首先会在在线中的哨兵节点中选出一个领导者，每个在线的哨兵节点都可以成为领导者；

1. 当普通的哨兵节点(哨兵1)发现领导者节点不可用时，会向其他的哨兵节点发送is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
2. 当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
3. 如果哨兵1发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举；

选举出领导者后，后续redis的主节点出现故障时，就由领导者负责故障转移；

C、主管宕机和客观宕机

• sdown，即主观宕机，如果一个哨兵它自己觉得master宕机了，就是主观宕机
• odown，即客观宕机，如果quorum数量的哨兵都认为一个master宕机了，则为客观宕机

主观下线 sdown

sentinel会以每秒一次的频率向所有与其建立了命令连接的实例（master，从服务，其他sentinel）发ping命令，通过判断ping回复是：有效回复、还是无效回复来判断实例是否在线（对该sentinel来说是“主观在线”）

sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，如果实例在down-after-milliseconds毫秒内，返回的都是无效回复，那么sentinel回认为该实例已（主观）下线，修改其flags状态为SRI_S_DOWN

客观下线 odown

如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机，就完成了sdown到odown的转换。

D、redis选主过程—-从节点升级为主节点的选举算法

当redis主节点被认为不可用时，哨兵的领导者会按照如下规则在从节点中选出新的主节点；

1. 只选择健康的从节点，过滤掉主观下线的节点
2. 选择slave-priority最高的节点；有则返回，没有则继续下一步；
3. 选择出复制偏移量最大的系节点，因为复制便宜量越大则数据复制的越完整，如果有就返回，没有就继续下一步；
4. 选择run_id最小的节点；

完