Redis高可用

https://www.cnblogs.com/bingshu/p/9776610.html

Redis高可用概述

在 Web 服务器中，高可用 是指服务器可以 正常访问 的时间，衡量的标准是在 多长时间 内可以提供正常服务（99.9%、99.99%、99.999% 等等）。

在 Redis 层面，高可用 的含义要宽泛一些，除了保证提供 正常服务（如 主从分离、快速容灾技术 等），还需要考虑 数据容量扩展、数据安全 等等。

在 Redis 中，实现 高可用 的技术主要包括 持久化、复制、哨兵 和 集群，下面简单说明它们的作用，以及解决了什么样的问题：

• 持久化：持久化是 最简单的 高可用方法。它的主要作用是 数据备份，即将数据存储在 硬盘，保证数据不会因进程退出而丢失。
• 复制：复制是高可用 Redis 的基础，哨兵 和 集群 都是在 复制基础 上实现高可用的。复制主要实现了数据的多机备份以及对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化、写操作无法负载均衡、存储能力受到单机的限制。
• 哨兵：在复制的基础上，哨兵实现了 自动化 的 故障恢复。缺陷是 写操作 无法 负载均衡，存储能力 受到 单机 的限制。
• 集群：通过集群，Redis 解决了 写操作 无法 负载均衡 以及 存储能力 受到 单机限制 的问题，实现了较为 完善 的 高可用方案。

Redis主从复制搭建

准备三台服务器

192.168.31.128
192.168.31.129
192.168.31.130

安装Redis,详细参考

将128服务期设为主服务器

主节点需加入一下配置

# 主节点认证密码，如果设置了密码，就要设置
masterauth 123456

将129 130 服务器设置为从服务器

从节点需要加入以下配置

 # 从节点要跟随的主节点
 slaveof 192.168.31.128 6397

# 主节点认证密码，如果设置了密码，就要设置
masterauth 123456

配置完成后重启三台服务器Redis服务

查看master信息

192.168.31.128:0>INFO Replication
"# Replication
role:master
connected_slaves:2
slave0:ip=192.168.31.129,port=6379,state=online,offset=950,lag=1
slave1:ip=192.168.31.130,port=6379,state=online,offset=950,lag=1
master_replid:1464d0fb6b8c7b19e104fb09f2de573191c2513c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:950
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:950

查看slave信息

192.168.31.129:0>INFO Replication
"# Replication
role:slave
master_host:192.168.31.128
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:1020
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:1464d0fb6b8c7b19e104fb09f2de573191c2513c
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1020
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1020

Redis主从复制的问题

Redis 主从复制 可将 主节点 数据同步给 从节点，从节点此时有两个作用：

1. 一旦 主节点宕机，从节点 作为 主节点 的 备份 可以随时顶上来。
2. 扩展 主节点 的 读能力，分担主节点读压力。

主从复制 同时存在以下几个问题：

1. 一旦 主节点宕机，从节点 晋升成 主节点，同时需要修改 应用方 的 主节点地址，还需要命令所有 从节点 去 复制 新的主节点，整个过程需要 人工干预。
2. 主节点 的 写能力 受到 单机的限制。
3. 主节点 的 存储能力 受到 单机的限制。
4. 原生复制 的弊端在早期的版本中也会比较突出，比如：Redis 复制中断 后，从节点 会发起 psync。此时如果 同步不成功，则会进行 全量同步，主库 执行 全量备份 的同时，可能会造成毫秒或秒级的 卡顿。

原文地址：https://www.cnblogs.com/miye/p/12164996.html