前言
本期原本计划是写些redis高可用架构选型,分析,及实战,发现篇幅过长,所以拆开来写了。这期先讲一些官方提供的高可用功能,主从,sentinel,以及redis cluster。
Redis-Replication
Redis 支持简单且易用的主从复制(master-slave replication)功能, 该功能可以让从服务器(slave server)成为主服务器(master server)的精确复制品。
以下是关于 Redis 复制功能的几个重要方面:
Redis 使用异步复制。 从 Redis 2.8 开始, 从服务器会以每秒一次的频率向主服务器报告复制流(replication stream)的处理进度。
工作原理
① 无论是初次连接还是重新连接, 当建立一个从服务器时, 从服务器都将向主服务器发送一个SYNC
命令。
② 接到SYNC
命令的主服务器将开始执行BGSAVE
, 并在保存操作执行期间, 将所有新执行的写入命令都保存到一个缓冲区里面。
③ 当BGSAVE
执行完毕后, 主服务器将执行保存操作所得的 .rdb 文件发送给从服务器, 从服务器接收这个 .rdb 文件, 并将文件中的数据载入到内存中。
④ 之后主服务器会以 Redis 命令协议的格式, 将写命令缓冲区中积累的所有内容都发送给从服务器。
你可以通过telnet
命令来亲自验证这个同步过程: 首先连上一个正在处理命令请求的 Redis 服务器, 然后向它发送SYNC
命令, 过一阵子, 你将看到 telnet 会话(session)接收到服务器发来的大段数据(.rdb 文件), 之后还会看到, 所有在服务器执行过的写命令, 都会重新发送到telnet
会话来。
即使有多个从服务器同时向主服务器发送SYNC
, 主服务器也只需执行一次BGSAVE
命令, 就可以处理所有这些从服务器的同步请求。
注意:从服务器可以在主从服务器之间的连接断开时进行自动重连, 在 Redis 2.8 版本之前, 断线之后重连的从服务器总要执行一次完整重同步(full resynchronization)操作, 但是从 Redis 2.8 版本开始, 从服务器可以根据主服务器的情况来选择执行完整重同步还是部分重同步(partial resynchronization)。
配置
replication的配置非常简单,在之前的文章中也有讲过,这里就不细说了。
slaveof 192.168.1.1 6379
另外一种方法是调用 SLAVEOF 命令, 输入主服务器的 IP 和端口, 然后同步就会开始:
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK
slave
从 Redis 2.6 开始, 从服务器默认为只读模式。
只读模式由 redis.conf
文件中的 slave-read-only
选项控制, 也可以通过 CONFIG SET
命令来开启或关闭这个模式。
只读从服务器会拒绝执行任何写命令, 所以不会出现因为操作失误而将数据不小心写入到了从服务器的情况。
即使从服务器是只读的, DEBUG 和 CONFIG 等管理式命令仍然是可以使用的, 所以我们还是不应该将服务器暴露给互联网或者任何不可信网络。 不过, 使用 redis.conf
中的命令改名选项, 我们可以通过禁止执行某些命令来提升只读从服务器的安全性。
你可能会感到好奇, 既然从服务器上的写数据会被重同步数据覆盖, 也可能在从服务器重启时丢失, 那么为什么要让一个从服务器变得可写呢?
原因是, 一些不重要的临时数据, 仍然是可以保存在从服务器上面的。 比如说, 客户端可以在从服务器上保存主服务器的可达性(reachability)信息, 从而实现故障转移(failover)策略。
注意:一般来说,常规业务,普通企业,redis这种内存型nosql是不存在IO瓶颈的,即便存在一般也是通过proxy构建集群,对数据进行分片来分担压力,所以向常规数据库样做读写分离是没有必要的。(这里说的是一般情况,具体场景具体分析)
sentinel
Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务:
sentinel原理
在讲解 Redis 高可用方案之前,我们先来看看 Redis Sentinel 原理是怎么样的。
down-after-milliseconds
)没有回复或则返回错误的回复,那么该实例被判为下线。failover
主备切换被触发后,failover
并不会马上进行,还需要 Sentinel 中的大多数 Sentinel 授权后才可以进行failover
,即进行failover
的 Sentinel 会去获得指定 quorum 个的 Sentinel 的授权,成功后进入 ODOWN 状态。如在 5 个 Sentinel 中配置了 2 个 quorum,等到 2 个 Sentinel 认为 master 死了就执行 failover。SLAVEOF NO ONE
命令,选择 slave 的条件是 Sentinel 首先会根据 slaves 的优先级来进行排序,优先级越小排名越靠前。如果优先级相同,则查看复制的下标,哪个从 master 接收的复制数据多,哪个就靠前。如果优先级和下标都相同,就选择进程 ID 较小的。config-epoch
),当 failover 执行结束以后,这个版本号将会被用于最新的配置,通过广播形式通知其它 Sentinel,其它的 Sentinel 则更新对应 master 的配置。1 到 3 是自动发现机制:
4 是检测机制,5 和 6 是failover 机制,7 是更新配置机制。
sentinel配置
Redis 源码中包含了一个名为 sentinel.conf 的默认配置文件。 运行一个 Sentinel 所需的配置如下所示:
# Global
port 26379
##监听端口
daemonize yes
##使用daemon方式运行程序,默认为非daemon方式运行
dir "/data/nosql/sentinel"
pidfile "/data/nosql/sentinel/sentinel.pid"
loglevel noticelogfile "/data/nosql/sentinel/sentinel.log"
#### sentinel monitor <master-group-name> <ip> <port> <quorum>
####行尾的<quorum>是数字
####这个数字表明需要最少多少个sentinel互相沟通来确认某个master是否真的死了
### sentinel <option_name> <master-group-name> <option_value>#### down-after-milliseconds : sentinel会向master发送心跳PING来确认master是否存活,如果master在“一定时间范围”内不回应PONG或者是回复了一个错误消息,那么这个sentinel会主观地(单方面地)认为这个master已经不可用了(subjectively down, 也简称为SDOWN)。而这个down-after-milliseconds就是用来指定这个“一定时间范围”的,单位是毫秒。
#### failover-timeout : 这个选项确定自动转移故障超时时间,单位毫秒
#### parallel-syncs : 在发生failover主备切换时,这个选项指定了最多可以有多少个slave同时对新的master进行同步
sentinel monitor redis161 192.168.1.161 6379 1
sentinel down-after-milliseconds redis161 5000
sentinel failover-timeout redis161 10000
sentinel client-reconfig-script redis161 /data/redis/sentinel/sentinel_hook.sh //故障触发脚本
sentinel config-epoch redis161 4
sentinel leader-epoch redis161 4
# Generated by CONFIG REWRITE
sentinel known-slave redis161 192.168.1.164 6380
sentinel current-epoch 4
注意:
sentinel client-reconfig-script
为sentinel指定故障触发脚本,多用于配合proxy使用,去同步修改proxy配置,屏蔽切换故障节点。
启动Sentinel
对于 redis-sentinel 程序, 你可以用以下命令来启动 Sentinel 系统:
redis-sentinel /path/to/sentinel.conf
对于 redis-server 程序, 你可以用以下命令来启动一个运行在 Sentinel 模式下的 Redis 服务器:
redis-server /path/to/sentinel.conf --sentinel
两种方法都可以启动一个 Sentinel 实例。 启动 Sentinel 实例必须指定相应的配置文件, 系统会使用配置文件来保存 Sentinel 的当前状态, 并在 Sentinel 重启时通过载入配置文件来进行状态还原。
有朋友反映前几篇文章篇幅过长,影响可读性,不应向PC端技术文章那样详细,因此我对后续文章开始逐步精简。 下一篇横向分析下redis cluster,twemproxy,codis等集群架构。