下载并且编译安装
配置主从的conf
创建一个redis的主从文件夹
mkdir redis_master_slave
在redis_master_slave文件夹内创建三个文件7001、7002、7003
mkdir -p 7001/conf 7002/conf 7003/conf
将redis中的配置文件redis.conf复制到上面各个conf中去
在700相关文件夹中的redis.conf中的配置进行修改
# 端口7001,7002,7003
port 7001
# bind 0.0.0.0，这样是允许任何机器都可以访问该服务器
# 默认ip为127.0.0.1 需要改为其他节点机器可访问的ip 否则创建集群时无法访问对应的端口，否则无法主从
bind 主机ip
# redis后台运行
daemonize yes
# pidfile文件对应6379,6380,6381
pidfile /var/run/redis_7000.pid
# aof日志开启 有需要就开启，它会每次写操作都记
appendonly yes
# 和dir 有关系
logfile "文件名"
# 数据存储路径
dir "/usr/local/software/redis_master_slave/7001/data"
# 在7002,7003里面配置，作为从
slaveof 绑定ip 7001
# 其他配置一句需求做响应的设置
# 本机redis密码 如果哨兵中配置，那么主从都配置
requirepass 123456
# 主机redis密码 如果哨兵中配置，那么主从都配置
masterauth "123456"
启动redis
#!/bin/sh
for ((i=1;i<4;i++))
do
redis-server ./700$i/conf/redis.conf
done
哨兵机制简介
配置哨兵
哨兵的 conf文件一般都在redis的当前解压目录下
在redis_master_slave 目录下创建 mkdir -p sentinel/conf mkdir -p sentinel/log
在redis的根目录下mv sentinel.conf ../sentinel/conf
# 端口
port 26379
# 工作路径，注意路径不要和主重复
dir "/usr/local/software/redis_master_slave/sentinel/log"
# 指明日志文件名
logfile "./sentinel.log"
sentinel myid bea48b4599058ed53d7b43b1b13c886bcbda232c
# 绑定主机
bind 172.16.93.101
# 守护进程模式
daemonize yes
sentinel deny-scripts-reconfig yes
# 哨兵监控的master，主从配置一样，这里只用输入redis主节点的ip/port和法定人数
# 这个1代表，当集群中有2个sentinel认为master挂了时，才能真正认为该master已经不可用了
sentinel monitor mymaster 127.0.0.1 7001 1
sentinel config-epoch mymaster 1
sentinel leader-epoch mymaster 1
# 密码 没有可不设置
# sentinel auth-pass mymaster 123456
# Generated by CONFIG REWRITE 下面三个配置是自动生成的
sentinel known-slave mymaster 127.0.0.1 7001
sentinel known-slave mymaster 127.0.0.1 7002
sentinel current-epoch 1
启动哨兵
redis-sentinel /usr/local/software/redis_master_slave/sentinel/conf
哨兵机制起到的作用
sentinel架构的主要作用是解决主从模式下主节点的故障转移工作的。这里如果主节点因为故障下线，那么某个sentinel节点发送检测消息给主节点时，如果在指定时间内收不到回复，那么该sentinel就会主观的判断该主节点已经下线，那么其会发送消息给其余的sentinel节点，询问其是否“认为”该主节点已下线，其余的sentinel收到消息后也会发送检测消息给主节点，如果其认为该主节点已经下线，那么其会回复向其询问的sentinel节点，告知其也认为主节点已经下线，当该sentinel节点最先收到超过指定数目（配置文件中配置的数目和当前sentinel节点集合数的一半，这里两个数目的较大值）的sentinel节点回复说当前主节点已下线，那么其就会对主节点进行故障转移工作，故障转移的基本思路是在从节点中选取某个从节点向其发送slaveof no one（假设选取的从节点为127.0.0.1:6380），使其称为独立的节点（也就是新的主节点），然后sentinel向其余的从节点发送slaveof 127.0.0.1 6380命令使它们重新成为新的主节点的从节点。重新分配之后sentinel节点集合还会继续监控已经下线的主节点（假设为127.0.0.1:6379），如果其重新上线，那么sentinel会向其发送slaveof命令，使其成为新的主机点的从节点，如此故障转移工作完成
优点及解决问题
- 同一个Master可以同步
多个Slaves - Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的
分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构 - Master Server是以
非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求 - Slave Server同样是
以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据 - 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，
写服务仍然必须由Master来完成。即便如此，系统的伸缩性还是得到了很大的提高 - Master可以将数据
保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作 - 支持
主从复制，主机会自动将数据同步到从机，可以进行读写分离
❗️❗️❗️注意点
在实现redis客户端API工具类时，出现的问题
使用StringRedisSerializer序列化方式，**不能在string类型中存储对象等非string信息
使用JdkSerializationRedisSerializer序列化方式，不能对整数、浮点进行incr自增操作
使用GenericJackson2JsonRedisSerializer序列化方式，存储的json串信息较比byte方式性能较慢
网友评论