linux下的redis使用及redis集群（主从、哨兵）

redis单点、redis主从、redis哨兵 sentinel，redis集群cluster配置搭建与使用

linux下安装redis

1. 上传文件到opt文件夹
2. tar zxvf redis-3.2.9.tar.gz 解压
3. mv redis-3.2.9 /usr/local/ 移动redis文件夹至/usr/local
4. 进入redis-版本号下的src目录（应该是进入带有版本号的文件夹是我们解压后的文件，local下还有一个自带我的redis文件夹，不是这个）：cd /usr/local/redis-3.2.9/src
5. 编译源码：make
6. 测试编译结果：make test
7. 修改redis.conf

bind 绑定端口号注释，如果不注释将不能在本机以外客户端访问
requirepass 打开注释 修改密码

8. 端口号加入白名单

firewall-cmd --permanent --zone=public --add-port=6379/tcp
firewall-cmd --reload

9. 启动redis
   • 进入redis启动命令目录：cd /usr/local/redis-3.2.9/src
   • 执行redis启动命令：./redis-server …/redis.conf & (&符号表示在后台执行)
   • 连接Redis：./redis-cli -h 127.0.0.1 -p 6379；auth:密码
   • 输入指令exit退出
10. 停止redis服务

ps -ef|grep redis
Kill -9 进程号

如果客户端无法访问，请检查防护墙设置和redis.config是否绑定ip

redis集群

• redis主从复制简单介绍
  • 一个master可以有多个slave
  • 主从复制不会阻塞master。也就是说当一个或多个slave与master进行初次同步数据时，master可以继续处理client发来的请求。相反slave在初次同步数据时则会阻塞不能处理client的请求。
  • 主从复制可以用来提高系统的可伸缩性,我们可以用多个slave 专门用于client的读请求，比如sort操作可以使用slave来处理。也可以用来做简单的数据冗余
• Redis主从复制的常用的几种方式
  • 一主二仆 A(B、C) 一个Master两个Slave
  • 薪火相传（去中心化）A - B - C ，B既是主节点（C的主节点），又是从节点（A的从节点）
  • 反客为主（主节点down掉后，手动操作升级从节点为主节点）
  • 哨兵模式（主节点down掉后，自动升级从节点为主节点）

Redis主从复制的搭建（一主二仆）

角色设计

• 需要搭建3个Redis环境
• 6379端口的Redis作为主(Master)
• 6380和6381端口的Redis作为仆从(Slave)
  

redis主库搭建

• 在安装时配置的基础上，放开masterauth，设置密码，并将rdb和log生成的文件都带上6379以作区分。

logfile "/var/log/redis6379.log"
masterauth root
dbfilename dump6379.rdb

redis从库搭建

• 复制主库文件夹，修改名字：cp -r /usr/local/redis-3.2.9/redis6379.conf /usr/local/redis-3.2.9/redis.6380.conf
• 修改配置文件

端口号：port 6380
主库配置：slaveof 192.168.14.204 6379
主库密码：masterauth root
以及其他6379相关都改成6380

• 6381同理。
• 6380和6381加入防火墙白名单

firewall-cmd --permanent --zone=public --add-port=6380/tcp
firewall-cmd --permanent --zone=public --add-port=6381/tcp
firewall-cmd --reload

• 配置完成，启动。先启动主库，后启动从库。

测试

• redis客户端连接，插入两条数据，查看主库日志。
  

• 连接主库客户端，输入指令info replication
  

• 进入从库客户端。日志中可以看出，当前角色是slave，master的ip和port都已经显示出来。
  

• 由于conf文件中的配置，从库只能读取不能写。

主从复制的机制

• 全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。（第一次全量）
• 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步。（之后增量）
• 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行。

Redis主从复制（一主两从/一主多从）的分析

• IO剧增
  每次slave断开以后（无论是主动断开，还是网路故障）再连接master都要将master全部dump出来rdb，在aof，即同步的过程都要重新执行一遍；所以要记住多台slave不要一下都启动起来，否则master可能IO剧增（间隔1-2分）

• 复制延迟
  由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

• 可用性不高
  当有主节点发生异常情况，就会导致不能写入，导致业务出错！
  注意：
  Redis 集群不保证数据的强一致性（strong consistency）Redis 集群的一致性保证（guarantee）： 在特定条件下， Redis 集群可能会丢失已经被执行过的写命令。

Redis Sentinel（高可用集群-哨兵模式）

• Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：
  1. 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
  2. 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
  3. 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
     

配置Sentinel.conf文件

• 复制三份，端口号分别为：26379、26380、26381
• 需要修改：port、logfile、mymaster的IP、端口和连接密码。

# sentinel.6381.conf
protected-mode no

port 26381

dir /tmp

logfile "/var/log/redis/sentinel.6381.log"

sentinel monitor mymaster 192.168.14.204 6379 2

sentinel auth-pass mymaster root

sentinel down-after-milliseconds mymaster 3000

sentinel failover-timeout mymaster 180000

• 配置文件的注释

port 20086      #默认端口26379

dir "/tmp"

logfile "/var/log/redis/sentinel_20086.log"

daemonize yes

#格式：sentinel <option_name> <master_name> <option_value>；#该行的意思是：监控的master的名字叫做T1（自定义）,地址为127.0.0.1:10086，行尾最后的一个2代表在sentinel集群中，多少个sentinel认为masters死了，才能真正认为该master不可用了。
sentinel monitor T1 127.0.0.1 10086 2  

#sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了(subjectively down, 也简称为SDOWN)。而这个down-after-milliseconds就是用来指定这个“一定时间范围”的，单位是毫秒，默认30秒。
sentinel down-after-milliseconds T1 15000

#failover过期时间，当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel将会认为此次failoer失败。默认180秒，即3分钟。
sentinel failover-timeout T1 120000

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

#sentinel 连接设置了密码的主和从
#sentinel auth-pass <master_name> xxxxx

#发生切换之后执行的一个自定义脚本：如发邮件、vip切换等
##sentinel notification-script <master-name> <script-path>    
#sentinel client-reconfig-script <master-name> <script-path>  

启动reids集群

启动sentinel

• 在src目录下执行
  ./redis-server …/sentinel.6379.conf --sentinel &
  ./redis-server …/sentinel.6380.conf --sentinel &
  ./redis-server …/sentinel.6381.conf --sentinel &

测试

• ps -ef|grep redis 查看进程
  

• 杀掉主库的进程 端口号是6379的进程，观察日志
  

• 进入6380客户端，可以看见，此时的主库变成了6381
  

• 进入6381客户端，可以看见6381角色变成了主库，并且有一个从库6380

• 启动6379：./redis-server …/redis6379.conf &
  如果启动报错，是同步数据时出错，修改redis.conf配置文件，masterauth属性

• 查看6379客户端，6379已经变成了从库
  

springboot中的配置（application.yml）