搭建 Redis 主从+哨兵集群

纯粹是为了记录搭建的过程。忘了就翻来看看。

下载编译

下载:

$ wget http://download.redis.io/releases/redis-5.0.3.tar.gz

解压:

$ tar -zxvf redis-5.0.3.tar.gz

编译:

$ make install PREFIX /opt/redis/redis-5.0.3

拷贝配置文件:

$ cp redis.conf /opt/redis/redis-5.0.3/bin

$ cp redis-sentinel.conf /opt/redis/redis-5.0.3/bin

配置

配置 redis.conf

# 这里需要配置内网地址,不要配置localhost, 不然只能单机自己玩

bind 内网地址

# 进程后台运行, 这个必须的

daemonize yes

# 如果是从服务器, 那么这里需要配置主服务器的地址和端口

slaveof 主地址 主端口

配置 sentinel.conf

# 哨兵监听的端口

port 26379

# 进程后台运行, 这个必须的

daemonize yes

# 监视一个名为mymaster的主服务器,这个主服务器的 IP 地址为 172.17.4.57,端口号为 6379

# 后面那个2指的是将这个主服务器判断为失效至少需要1个Sentinel同意(只要同意Sentinel的数量不达标,自动故障迁移就不会执行)

sentinel monitor mymaster 172.17.4.57 6379 2

启动

启动 redis

$ ./redis-server redis.conf

启动哨兵监控

$ ./redis-sentinel sentinel.conf

查看主从状态

$ ./redis-cli -h xxx.xxx.xx.x -p 6379

 info replication;

# 主服务器:

# Replication

role:master

connected_slaves:2

slave0:ip 172.17.4.58,port 6379,state online,offset 20654866,lag 0

slave1:ip 172.17.4.59,port 6379,state online,offset 20654852,lag 1

master_replid:cd484ba407267626276822a76c387aafc77c78c0

master_replid2:0000000000000000000000000000000000000000

master_repl_offset:20655090

second_repl_offset:-1

repl_backlog_active:1

repl_backlog_size:1048576

repl_backlog_first_byte_offset:19606515

repl_backlog_histlen:1048576

# 从服务器

# Replication

role:slave

master_host:172.17.4.57

master_port:6379

master_link_status:up

master_last_io_seconds_ago:1

master_sync_in_progress:0

slave_repl_offset:20675712

slave_priority:100

slave_read_only:1

connected_slaves:0

master_replid:cd484ba407267626276822a76c387aafc77c78c0

master_replid2:0000000000000000000000000000000000000000

master_repl_offset:20675712

second_repl_offset:-1

repl_backlog_active:1

repl_backlog_size:1048576

repl_backlog_first_byte_offset:19627137

repl_backlog_histlen:1048576

查看哨兵状态

$ ./redis-cli -h xxx.xxx.xx.x -p 26379 info sentinel

# Sentinel

sentinel_masters:1

sentinel_tilt:0

sentinel_running_scripts:0

sentinel_scripts_queue_length:0

sentinel_simulate_failure_flags:0

master0:name mymaster,status ok,address 172.17.4.57:6379,slaves 2,sentinels 3

24-微服务技术栈（高级）：分布式缓存Redis分片集群 在上面两节，笔者带领大家完成主动集群搭建（解决单节点读压力过大问题），又完成哨兵集群的搭建（解决节点故障的自动恢复，从而提高系统整体稳定性）。但是上述不论那种架构模式，都没有解决当前系统的写压力过大问题。本节的分片集群将会有多个master节点，实现写压力的分摊，同时多个master节点互相通信，具备哨兵的功能，一旦节点故障，同样可以自动检测、投票、恢复。
23-微服务技术栈（高级）：分布式缓存Redis哨兵集群 在上一节我们完成主从集群的搭建，虽然解决了读的压力，但是当集群主节点宕机时，系统架构有没有备用方案呢？如果没有是不是缓存层就直接失效、甚至异常了呢？在此基础之上我们可以借助于哨兵完成新主节点的选举，实现集群的自动恢复。
22-微服务技术栈（高级）：分布式缓存Redis主从集群 单机Redis可以解决应用缓存的问题，但是随着系统流量的增加，读操作开始指数级倍增时，及时单节点Redis基于内存的读写操作再快也会有性能瓶颈，此时我们可以借助主从架构（主负责写、从负责读）来优化上述场景，实现高并发读优化。
不同 Redis 集群之间做数据同步 本实践是在两台虚拟机中部署了伪集群进行试验，最后才在生产环境中进行同步，同步完成之后记得做数据一致性验证。
Redis学习（九）：Redis集群 之前通过代理主机的方式解决。即客户端的请求发到代理服务器中，再由代理服务器转发给各个服务。但其实这样会导致服务器数量很多。Redis3.0之后提出了无中心化集群配置，即每一个服务都可以作为请求的入口，各个服务之间可以相互转发请求。这样可以减少服务器的数量。
后端进阶 微信公众号「后端进阶」作者，技术博客（https://objcoding.com/）博主，Seata Committer，GitHub ID：objcoding。