文章目录

概念
环境配置
一主二从
哨兵模式

以下是Redis相关笔记总结，方便自己以后复习，同时也希望对大家有所帮助。

内容	地址链接
Redis在Linux环境下的详细安装教程	https://blog.csdn.net/BBQ__ZXB/article/details/123905061
Redis中五大基本数据类型和三种特殊数据类型	https://blog.csdn.net/BBQ__ZXB/article/details/124169168
Redis中基本事务操作及乐观锁的实现	https://blog.csdn.net/BBQ__ZXB/article/details/124192251
Java中使用JedisAPI操作Redis中五大基本数据类型	https://blog.csdn.net/BBQ__ZXB/article/details/124194220
Spring boot整合Redis（入门教程）	https://blog.csdn.net/BBQ__ZXB/article/details/124301234
Redis主从复制详解（入门教程）	https://blog.csdn.net/BBQ__ZXB/article/details/124802602
Spring boot整合Redis实现发布订阅（超详细）	https://blog.csdn.net/BBQ__ZXB/article/details/124980860
Redis执行save命令时报错ERR	https://blog.csdn.net/BBQ__ZXB/article/details/123995289

概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower) ; 数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。

默认情况下，每台redis服务器都是主节点，且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

主从复制的作用：

读写分离：主节点写，从节点读，提高服务器的读写负载能力
数据冗余︰主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复︰当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复 ; 实际上是一种服务的冗余。
负载均衡︰在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载 ; 尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
高可用（集群）基石︰除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

一般来说，要将redis运用于工程项目中，只使用一台redis是万万不能的（可能宕机，一主二从），原因如下：

从结构上，单个redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；
从容量上，单个redis服务器内存容量有限，就算一台redis服务器内存容量为256G，也不能将所有内存用做redis存储内存，
一般单台redis最大使用内存不应该超过20G。

比如电商网站上的商品，一般都是一次上传，无数次浏览，也就是“多读少写”

环境配置

本文以一主二从的模式，需在一台装有redis服务的服务器上准备三个端口不同的配置文件，如：redis79.conf，redis80.conf，redis81.conf。

分别启动这3个redis服务器，可以通过进程查看

一主二从

配置

本文中以6379端口服务为主库，6380和6381端口两个服务为从库进行配置

默认情况下，每台redis服务器都是主节点，且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

通俗来讲就是只配置从机！（认老大）
命令说明：
slaveof host 端口（当前服务器转变为指定服务器的从属服务器(slave server)）
slaveof no one (使得这个从属服务器关闭复制功能，并从从属服务器转变回主服务器)
注意：slaveof no one 命令使用后，原来同步所得的数据集不会被丢弃

在6380端口服务上操作（只展示部分返回信息）：

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379	#在从机中进行配置，slaveof host 端口
OK
127.0.0.1:6380> info replication
# Replication
role:slave	#当前角色 从节点
master_host:127.0.0.1	#主机信息
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:28
slave_priority:100
slave_read_only:1
connected_slaves:0
...

在6381端口服务上操作（只展示部分返回信息）：

127.0.0.1:6381> info replication
# Replication
role:slave	#当前角色 从节点
master_host:127.0.0.1 #主机信息
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_repl_offset:1428
slave_priority:100
slave_read_only:1
connected_slaves:0
...

在6379端口服务中查看：

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=1428,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=1428,lag=0
...

测试

主机可以写，从机不可以写（只能读）！主机村所有信息和数据，都会自动被从机保存！

在6379端口服务（主机）写：

在6380端口服务（从机）读：

问题：如果主机宕机会发生什么？主机宕机恢复后会发生什么？

在6380中：
显示主机状态断掉，但自身扔为从机

主机恢复
在6379端口服务中（主机）：进行写操作

在6380端口服务中（从机）：进行读操作

结论：

主机断开后，从机依旧连接到主机，但是没有写操作了
如主机重新连接，从机依旧可以获取到主机写入的信息

其中一个从机断了，主机新set的值，待该从机后连接后，如果使用命令行来配置的主从关系，如果重启后，从机就变成主机。（修改配置文件可永久生效)！只要再变回从机，立马就会从主机中获取值！
在Redis.conf中的REPLICATION配置两个地方即可

复制原理

Slave启动成功连接到master后会发生一个sync同步命令

master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕后，master将传送整个文件到slave，并完成一次完全同步。

全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中
增量复制：master继续将新的所有收集的修改命令依次传给slave，完成同步

但是只要是重新连接master，一次完全同步（全量复制）将被自动执行

哨兵模式

概述

主从切换技术的方法是：当主机服务器宕机后，需要手动把一台服务器切换为主服务器，这就是需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，优先考虑哨兵模式。redis从2.8开始正式提供了Sentinel（哨兵）架构来解决这个问题。

该方式可以后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立允许，其原理就是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个redis实例。

这里哨兵有两个作用：

通过发送命令，让redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然后一个哨兵进程对redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控，各哨兵之间还会进行监控，这样形成了多哨兵模式。

假设主服务器宕机，哨兵1先监测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面哨兵也检测出主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover（故障转移）操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

测试

配置哨兵配置文件（sentinel.conf）

#sentinel monitor 被监控的名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1

后面的数字1，代表主机挂了，slave投票看谁接替成为主机，票数最多成为主机！
2. 启动哨兵

sudo redis-sentinel my-config/sentinel.conf

3. 测试主机（6379）宕机
如果Master节点宕机断开，会在从机中随机选择一个服务器作为主节点（投票算法）

如果主机再次重新连接，则只能当它的从机，而非恢复之前的主机。

优缺点

优点：

哨兵集群，基于主从复制模式，所有的主从复制优点，它都有
主从可以切换，故障可以转移，系统的可用性就会更好
哨兵模式就是主从模式的升级，手动到自动，更加健壮

缺点：

Redis很难在线扩容，集群容量一旦达到上线，在线扩容就十分麻烦
实现哨兵模式的配置其实很麻烦，里面有很多选择配置项！

哨兵模式全部配置

重点配置

# Example   sentinel.conf
# 哨兵sentinel实例运行的端口   默认是26379，如果有哨兵集群，我们还需要配置每个哨兵端口
port 26379

#哨兵sentinel的工作目录
dir /tmp

#哨兵 sentine1 监控的redis主节点的 ip port   
# master-name  ，可以自己命名的主节点名字 只能由字母A-Z、数字0-9、这三个字符"  .   -  _ "组成。
# quorum配置多少个sentine1哨兵统- -认为master主节点失联那么这时客观上认为主节点失联了
# sentine1 monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster   127.0.0.1   6379   1

其他配置

#当在Redis实例中开启了requirepass foobared 授权密码这样所有连接kedis实例的客户端都要提供密码
#设置哨兵sentinel连接主从的密码注意必须为主从设置- - 样的验证密码
# sentine1 auth-pass <master-name> <password>
sentine1 auth-pass mymaster MySUPER--secret-0123passwOrd

#指定多少毫秒之后主节点没有应答哨兵sentine1 此时哨兵主观上认为主节点下线默认30秒
# sentinel down-after-mi 11i seconds <master-name> <mi 11iseconds>
sentine1 down-after-mi 11iseconds mymaster 30000

#这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成fai lover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而 不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
# sentine1 paralle1-syncs <master-name> <numslaves>
sentine1 paralle1-syncs mymaster 1

#故障转移的超时时间failover-timeout 可以用在以下这些方面:
#1.同一个sentine1对同一 个master两次fai lover之间的间隔时间。
#2.当一个slave从一 个错误的master那里同步数据开始计算时间。直到s1ave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有s1aves指向新的master所需的最大时间。不过，即使过了这个超时，slaves 依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了
#默认三分钟
# sentine1 failover-timeout <master-name> <milliseconds>
sentine1 fai lover-ti meout mymaster 180000

# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
#对于脚本的运行结果有以下规则:
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被-一个SIGKILL信号终止，之后重新执行。

#通知型脚本:当sentine1有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等)，将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等 方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一 个是事件的类型，一个是事件的描述。如果sentine1. conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentine1无法正常启动成功。
#通知脚本
# she11编程
# sentine1 notification-script <master-name> <script-path>
sentine1 notificati on-script mymaster /var/redis/notify. sh

#客户端重新配置主节点参数脚本
#当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。
#以下参数将会在调用脚本时传给脚本: 
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
#目前<state>总是“failover",
# <role>是“Teader"或者"observer"中的-一个。
#参数from-ip， from-port， to-ip，to-port是用来和旧的master和新的master(即旧的s lave)通信的
#这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentine1 client-reconfig-script <master-name> <script-path>
sentine1 client-reconfig-script mymaster /var/redis/reconfig.sh #一般都是由运维来配置!