1、主从复制

  • 利用异步复制
  • 3个服务器可以有多少个从服务器
  • 从服务器也可以有友好的从服务器
  • 复制功用不会阻塞主服务器
  • 可以通过劳务效益来上主服务器免于持久化操作,由从服务器去执行持久化操作即可。

澳门金沙国际 1

以下是关于Redis复制功用的多少个重点方面:

  • Redis使用异步复制。从Redis
    二.八始发,从服务器会以每秒一遍的功能向主服务器报告复制流(replication
    stream)的拍卖速度。
  • 二个主服务器能够有七个从服务器。
  • 不只主服务器能够有从服务器,从服务器也能够有友好的从服务器,三个从服务器之间可以构成一个图状结构。
  • 复制功效不会阻塞主服务器:
    固然有1个或七个从服务器正在开始展览第三同步,
    主服务器也能够继承处理命令请求。
  • 复制功效也不会卡住从服务器:
    只要在 redis.conf 文件中实行了相应的安装,
    即便从服务器正在拓展第2同步,
    服务器也足以利用旧版本的数目集来处理命令查询。
  • 不过, 在从服务器删除旧版本数据集并载入新本子数据集的那段岁月内,
    连接请求会被卡住。
  • 你仍是能够配备从服务器, 让它在与主服务器之间的连天断开时,
    向客户端发送二个错误。
  • 复制作用可以单独地用于数据冗余(data redundancy),
    也足以经过让八个从服务器处理只读命令请求来提高扩大性(scalability):
    比如说,
    繁重的 SORT 命令能够交给附属节点去运作。
  • 可以通过复制成效来让主服务器免于实践持久化操作:
    只要关闭主服务器的持久化功效, 然后由从服务器去实践持久化操作即可。

澳门金沙国际 2image.png

Redis命令参考之复制(Replication)

Redis 帮衬简单且易用的主从复制(master-slave replication)效率,
该意义能够让从服务器(slave server)成为主服务器(master
server)的可相信仿制品。

以下是有关 Redis 复制作用的多少个根本方面:

Redis 使用异步复制。 从 Redis 2.八 开首,
从服务器会以每秒二次的频率向主服务器报告复制流(replication
stream)的处理速度。

一个主服务器可以有八个从服务器。

不光主服务器能够有从服务器, 从服务器也足以有协调的从服务器,
四个从服务器之间能够整合3个图状结构。

复制功效不会阻塞主服务器: 就算有一个或多少个从服务器正在展开第一同步,
主服务器也足以持续处理命令请求。

复制成效也不会堵塞从服务器: 只要在 redis.conf 文件中开始展览了相应的设置,
即便从服务器正在进展第2同步,
服务器也能够使用旧版本的数量集来处理命令查询。

然则, 在从服务器删除旧版本数据集并载入新本子数据集的那段日子内,
连接请求会被打断。

你还是能配备从服务器, 让它在与主服务器之间的一而再断开时,
向客户端发送二个荒唐。

复制作用能够唯有地用于数据冗余(data redundancy),
也得以因而让多个从服务器处理只读命令请求来进步扩充性(scalability):
比如说, 繁重的 SO奥迪Q5T 命令能够交给附属节点去运行。

能够经过复制成效来让主服务器免于履行持久化操作:
只要关闭主服务器的持久化效用, 然后由从服务器去履行持久化操作即可。

复制作用的运作规律
不管初次连接照旧再次连接, 当建立贰个从服务器时,
从服务器都将向主服务器发送二个 SYNC 命令。

接收 SYNC 命令的主服务器将起来实践 BGSAVE , 并在保留操作实践时期,
将有着新实践的写入命令都封存到一个缓冲区里面。

当 BGSAVE 执行达成后, 主服务器将履行保存操作所得的 .rdb
文件发送给从服务器, 从服务器收到那几个 .rdb 文件,
并将文件中的数据载入到内部存款和储蓄器中。

随后主服务器会以 Redis 命令协议的格式,
将写命令缓冲区中积累的具有剧情都发送给从服务器。

您能够经过 telnet 命令来亲自证实那么些合伙进度:
首先连上二个正值处理命令请求的 Redis 服务器, 然后向它发送 SYNC 命令,
过一会儿, 你将看到 telnet
会话(session)接收到服务器发来的大段数据(.rdb 文件), 之后还会师到,
全部在服务器执行过的写命令, 都会再也发送到 telnet 会话来。

不怕有多少个从服务器同时向主服务器发送 SYNC , 主服务器也只需执行二遍BGSAVE 命令, 就能够拍卖全部那个从服务器的联合请求。

从服务器能够在着力服务器之间的一连断开时开始展览机动重连, 在 Redis 二.8版本此前, 断线之后重连的从服务器总要执行二回完整重同步(full
resynchronization)操作, 可是从 Redis 二.8 版本开头,
从服务器可以依据主服务器的状态来挑选执行总体重同步照旧有的重同步(partial
resynchronization)。

1部分重同步
从 Redis 二.捌 起始, 在互连网连接短暂性失效之后,
主从服务器能够品尝继续执行原有的复制进度(process),
而不自然要实施总体重同步操作。

以此性子须要主服务器为被发送的复制流成立三个内部存款和储蓄器缓冲区(in-memory
backlog),
并且主服务器和颇具从服务器之间都记录二个复制偏移量(replication
offset)和3个主服务器 ID (master run id), 当出现互联网连接断开时,
从服务器会再度连接, 并且向主服务器请求继续执行原来的复制进度:

万一从服务器记录的主服务器 ID 和当下要三番五次的主服务器的 ID 相同,
并且从服务器记录的偏移量所钦定的数量照旧保留在主服务器的复制流缓冲区里面,
那么主服务器会向从服务器发送断线时缺点和失误的那部分数量,
然后复制工作得以继续执行。
不然的话, 从服务器就要执行总体重同步操作。
Redis 贰.捌 的这一个局地重同步脾性会用到3个猛增的 PSYNC 内部命令, 而 Redis
二.捌 在此之前的旧版本只有 SYNC 命令, 可是, 只要从服务器是 Redis 二.捌或上述的本子, 它就会遵照主服务器的版本来决定到底是选取 PSYNC 依然 SYNC

即便主服务器是 Redis 2.八 或上述版本,那么从服务器使用 PSYNC
命令来进展共同。
假若主服务器是 Redis 2.八 以前的本子,那么从服务器使用 SYNC
命令来进行共同。
配置
布署二个从服务器卓殊不难, 只要在安顿文件中扩张以下的这1行就足以了:

slaveof 192.168.1.1 6379
当然, 你须求将代码中的 1九2.16八.一.壹 和 637九 替换到你的主服务器的 IP
和端口号。

此外1种办法是调用 SLAVEOF 命令, 输入主服务器的 IP 和端口,
然后一路就会起首:

127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK
只读从服务器
从 Redis 二.六 开端, 从服务器协理只读情势,
并且该方式为从服务器的暗中认可形式。

只读方式由 redis.conf 文件中的 slave-read-only 选项决定, 也足以通过
CONFIG SET 命令来打开或关闭这几个格局。

只读从劳动器会拒绝执行任何写命令,
所以不会冒出因为操作失误而将数据相当大心写入到了从服务器的气象。

哪怕从服务器是只读的, DEBUG 和 CONFIG 等管理式命令仍旧是能够使用的,
所以大家照旧不该将服务器暴露给网络或然其余离谱赖互连网。 可是, 使用
redis.conf 中的命令改名选项,
大家得以因而禁止实施有个别命令来进步只读从服务器的安全性。

您或然会倍感愕然, 既然从服务器上的写多少会被重同步数据覆盖,
也恐怕在从服务珍视启时丢失, 那么为何要让1个从服务器变得可写呢?

原因是, 壹些不首要的一时半刻数据, 依旧是足以保存在从服务器上面的。
比如说,
客户端能够在从服务器上保存主服务器的可达性(reachability)新闻,
从而完结故障转移(failover)策略。

从服务器相关铺排
如若主服务器通过 requirepass 选项设置了密码,
那么为了让从服务器的同步操作能够顺遂举办,
大家也不可能不为从服务器进行相应的身份验证设置。

对于二个正在周转的服务器, 能够选择客户端输入以下命令:

redis主从复制,Redis命令参考之复制。config set masterauth <password>
要永远地安装这些密码, 那么能够将它参预到计划文件中:

masterauth <password>
除此以外还有多少个挑选,
它们和主服务器执行部分重同步时所选拔的复制流缓冲区有关,
详细的音讯能够参考 Redis 源码中附带的 redis.conf 示例文件。

主服务器只在有至少 N 个从服务器的情况下,才实施写操作¶
从 Redis 贰.八 初阶, 为了保险数据的安全性, 能够由此布置,
让主服务器只在有至少 N 个当前已接连从服务器的图景下, 才执行写命令。

不过, 因为 Redis 使用异步复制,
所以主服务器发送的写多少并不一定会被从服务器收到到, 由此,
数据丢失的大概照旧是存在的。

以下是其壹特点的运作规律:

从服务器以每秒1回的频率 PING 主服务器二次, 并报告复制流的拍卖状态。
主服务器会记录各种从服务器最终2次向它发送 PING 的小运。
用户可以经过布置, 钦定网络延迟的最大值 min-slaves-max-lag ,
以及实施写操作所需的足足从服务器数量 min-slaves-to-write 。
假定至少有 min-slaves-to-write 个从服务器, 并且这几个服务器的延迟值都有限
min-slaves-max-lag 秒, 那么主服务器就会履行客户端请求的写操作。

您能够将以此天性看作 CAP 理论中的 C 的准绳放宽版本:
尽管无法担保写操作的持久性,
但起码丢失数据的窗口会被严峻限制在钦命的秒数中。

一只, 假诺条件达不到 min-slaves-to-write 和 min-slaves-max-lag
所钦点的标准化, 那么写操作就不会被执行,
主服务器会向请求执行写操作的客户端重临叁个不当。

以下是其壹特点的八个选项和它们所需的参数:

min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>
详尽的信息能够参考 Redis 源码中附带的 redis.conf 示例文件。

Ubuntu 1肆.04下Redis安装及简便测试

Redis集群明细文书档案

Ubuntu 12.10下安装Redis(图像和文字详解)+ Jedis连接Redis

Redis连串-安装配备维护篇

CentOS 6.3安装Redis

Redis安装配备学习笔记

Redis配置文件redis.conf 详解

Redis 的详尽介绍:请点这里
Redis 的下载地址:请点那里

正文永久更新链接地址:

Redis
补助简单且易用的主从复制(master-slave replication)功用,
该意义能够让从服务器(slave server)成为主服…

Reids主从复制

为了幸免单点故障,大家盼望将数据库复制五个副本以安排在不一致的服务器上,就算有一台服务器出现故障别的服务器依旧得以继续提供服务。
那就要求当壹台服务器上的数据库更新后,能够自动将更新的数目同步到其余服务器上,Redis提供了复制(replication)功效能够自行完结同步的经过。
Redis 帮忙不难且易用的主从复制(master-slave
replication)功用,该作用能够让从服务器(slave server)成为主服务器(master
server)的高精度仿制品。

Redis主从复制实践

环境:

/data/6380/redis-server
/data/6380/redis.conf
/data/6381/redis-server
/data/6381/redis.conf
/data/6382/redis-server
/data/6382/redis.conf

配置文件示例:

配置文件示例:
redis.conf
bind 127.0.0.1 192.168.29.128
port 6380
daemonize yes
pidfile /data/6380/redis.pid
loglevel notice
logfile "/data/6380/redis.log"
dbfilename dump.rdb
dir /data/6380
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
slowlog-log-slower-than 10000
slowlog-max-len 128
protected-mode no

启动

/data/6380/redis-server /data/6380/redis.conf
/data/6381/redis-server /data/6381/redis.conf
/data/6382/redis-server /data/6382/redis.conf

主节点:6380
从节点:6381、6382
开启主从:
6381/6382命令行:
redis-cli -p 6381
SLAVEOF 127.0.0.1 6380

Redis 与任何 key – value 缓存产品有以下几个特征:

Redis 复制功效的风味:

  • 1.Redis 使用异步复制。从 Redis 2.8开首,从服务器会以每秒一次的频率向主服务器报告复制流(replication stream)的处理速度。
  • 贰.2个主服务器能够有两个从服务器。
  • 3.不但主服务器能够有从服务器,从服务器也能够有和好的从服务器,多少个从服务器之间可以组合二个图状结构。
  • 四.复制功能不会阻塞主服务器:就算有一个或三个从服务器正在进展第3同步,主服务器也能够接二连三处理命令请求。
    复制功用也不会卡住从服务器:只要在 redis.conf
    文件中进行了对应的安装,即使从服务器正在展开第二同步,服务器也得以动用旧版本的数额集来处理命令查询。
  • 伍.可是,在从服务器删除旧版本数据集并载入新本子数据集的那段时间内,连接请求会被打断。你还足以布署从服务器,让它在与主服务器之间的连天断开时,向客户端发送八个不当。
  • 陆.复制功效能够单独地用于数据冗余(data
    redundancy),也得以经过让八个从服务器处理只读命令请求来升高扩充性(scalability):比如说,繁重的
    SOKugaT 命令可以交到附属节点去运作。
  • 柒.方可因此复制成效来让主服务器免于履行持久化操作:只要关闭主服务器的持久化功用,然后由从服务器去执行持久化操作即可。

澳门金沙国际,运作规律

从服务器以每秒一次的频率PING主服务器一次,并报告复制流的处理情况。主服务器记录各个从服务器最后一次向它发送PING的时间。用户可以通过配置,指定网络延迟的最大值min-slaves-max-lag,以及执行操作所需的至少从服务器数量min-slaves-to-write。
如果至少有min-slaves-to-write个从服务器,并且这些服务器的延迟值都少于min-slaves-max-lag秒,那么主服务器就会执行客户端请求的写操作。你可以将这个特性看作CAP理论的C的条件放宽版本:尽管不能保证写操作的持久性,但起码丢失数量的窗口会被严格限制在指定的描述中。
另一方面,如果条件达不到min-slaves-to-write和min-slaves-max-lag所指定的条件,那么写操作就不会执行,主服务器会向请求执行写操作的客户端返回一个错误。
  1. Redis帮衬数据的持久化,可以将内部存款和储蓄器中的数额保持在磁盘中,重启的时候能够再次加载进行应用。
  2. Redis不仅仅协助不难的key-value类型的数量,同时还提供list,set,zset,hash等数据结构的贮存。
  3. Redis协助数据的备份,即master-slave格局的数据备份。

Redis复制工作原理

  • 一.无论是初次连接照旧再度连接,当建立七个从服务器时,从服务器都将向主服务器发送3个SYNC命令。
  • 2.吸收SYNC命令的主服务器将开端实行BGSAVE,并在保留操作实施时期,将具有新实施的写入命令都保留到一个缓冲区里面。
  • 三.当BGSAVE执行完成后,主服务器将推行保存操作所得的.rdb文件发送给从服务器,从服务器收到那么些.rdb文件,并将文件中的数据载入到内存中。
  • 4.之后主服务器会以 Redis
    命令协议的格式,将写命令缓冲区中积累的装有内容都发送给从服务器。

  • 伍.你可以通过 telnet
    命令来亲自表明这一个合伙进程:首先连上一个正在处理命令请求的 Redis
    服务器,然后向它发送SYNC命令,过会儿,你将见到 telnet
    会话(session)接收到服务器发来的大段数据(.rdb文件),之后还会师到,全体在服务器执行过的写命令,都会再也发送到
    telnet 会话来。

  • 六.即使有多少个从服务器同时向主服务器发送SYNC,主服务器也只需进行2回BGSAVE命令,就足以处理全体那么些从服务器的同步请求。
  • 柒.从服务器能够在基本服务器之间的连天断开时展开活动重连,在 Redis 二.八版本在此以前,断线之后重连的从服务器总要执行1次完整重同步(full
    resynchronization)操作,然则从 Redis 2.8版本初叶,从服务器能够依照主服务器的情形来摘取执行总体重同步照旧某些重同步(partial
    resynchronization)。

Redis主从复制管理

主从复制状态监控:
info replication

主从切换:
slaveof no one
概念 说明
Redis 优势 1. 性能极高– Redis能读的速度是110000次/s,写的速度是81000次/s 。 2. 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。 3. 原子 – Redis的所有操作都是原子性的,同时Redis还支持对几个操作全并后的原子性执行。 4. 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。
Redis与其他key-value存储有什么不同? 1. Redis有着更为复杂的数据结构并且提供对他们的原子性操作,这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明,无需进行额外的抽象。 2. Redis运行在内存中但是可以持久化到磁盘,所以在对不同数据集进行高速读写时需要权衡内存,应为数据量不能大于硬件内存。在内存数据库方面的另一个优点是, 相比在磁盘上相同的复杂的数据结构,在内存中操作起来非常简单,这样Redis可以做很多内部复杂性很强的事情。 同时,在磁盘格式方面他们是紧凑的以追加的方式产生的,因为他们并不需要进行随机访问。

1些重同步

从 Redis 2.8起头,在互联网连接短暂性失效之后,主从服务器能够品味继续执行原有的复制进程(process),而不肯定要履行总体重同步操作。

本条天性须求主服务器为被发送的复制流创立一个内部存款和储蓄器缓冲区(in-memory
backlog),并且主服务器和持有从服务器之间都记录二个复制偏移量(replication
offset)和一个主服务器 ID (master run
id),当出现网络连接断开时,从服务器会另行连接,并且向主服务器请求继续执行原来的复制进程:
如若从服务器记录的主服务器 ID 和脚下要连接的主服务器的 ID
相同,并且从服务器记录的偏移量所钦命的数量如故保留在主服务器的复制流缓冲区里面,那么主服务器会向从服务器发送断线时缺失的那有些数额,然后复制工作可以继续执行。
不然的话,从服务器就要执行总体重同步操作。

Redis 2.八 的那些局地重同步天性会用到八个激增的 PSYNC 内部命令,而 Redis
2.八 此前的旧版本唯有 SYNC 命令,可是,只要从服务器是 Redis 2.八或以上的本子,它就会依照主服务器的本子来支配到底是应用 PSYNC 依旧 SYNC

假定主服务器是 Redis 贰.八 或以上版本,那么从服务器使用 PSYNC
命令来实行同步。
比方主服务器是 Redis 二.8 从前的版本,那么从服务器使用 SYNC
命令来拓展同步。

二、Redis Sentinel

Redis-Sentinel是Redis官方推荐的高可用性(HA)接近方案,当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,而Redis-sentinel本身也是一个独立运行的进程,他能监控多个master-slave集群,发现master宕机后能进行自动切换。

数据类型

概念 说明
String string是redis最基本的类型,你可以理解成与Memcached一模一样的类型,一个key对应一个value。 string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。 string类型是Redis最基本的数据类型,一个键最大能存储512MB。
Hash Redis hash 是一个键值对集合。 Redis hash是一个string类型的field和value的映射表,hash特别适合用于存储对象。 每个 hash 可以存储 2 *32 – 1键值对。
List Redis 列表是简单的字符串列表,按照插入顺序排序。你可以添加一个元素导列表的头部或者尾部。 列表最多可存储 2*32 – 1元素 (4294967295, 每个列表可存储40多亿)。
Set Redis的Set是string类型的无序集合。 集合是通过哈希表实现的,所以添加,删除,查找的复杂度都是O。 集合中最大的成员数为 2* 32 – 1(4294967295, 每个集合可存储40多亿个成员)。
zset(sorted set:有序集合) Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。 不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。 zset的成员是唯一的,但分数却可以重复。

着力配置

布局2个从服务器相当不难,只要在布局文件中加进以下的那1行就能够了:
slaveof 192.168.1.1 6379
自然,你要求将代码中的1九二.16捌.1.壹和637九替换到你的主服务器的 IP
和端口号。
此外1种艺术是调用SLAVEOF命令,输入主服务器的 IP
和端口,然后一并就会起首:
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK

Sentinel的构造

Sentinel是一个监视器,它可以根据被监视实例的身份和状态来判断应该执行何种动作。

澳门金沙国际 3

基本概念

概念 说明
HyperLogLog Redis 在 2.8.9 版本添加了 HyperLogLog 结构。 Redis HyperLogLog 是用来做基数统计的算法,HyperLogLog 的优点是,在输入元素的数量或者体积非常非常大时,计算基数所需的空间总是固定 的、并且是很小的。 在 Redis 里面,每个 HyperLogLog 键只需要花费 12 KB 内存,就可以计算接近 2^64 个不同元素的基 数。这和计算基数时,元素越多耗费内存就越多的集合形成鲜明对比。 但是,因为 HyperLogLog 只会根据输入元素来计算基数,而不会储存输入元素本身,所以 HyperLogLog 不能像集合那样,返回输入的各个元素。 什么是基数? 比如数据集 {1, 3, 5, 7, 5, 7, 8}, 那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数为5。 基数估计就是在误差可接受的范围内,快速计算基数。
发布订阅 Redis 发布订阅是一种消息通信模式:发送者发送消息,订阅者接收消息。 Redis 客户端可以订阅任意数量的频道。 下图展示了频道 channel1 , 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系:image.png 当有新消息通过 PUBLISH 命令发送给频道 channel1 时, 这个消息就会被发送给订阅它的三个客户端: image.png
Redis 事务 Redis 事务可以一次执行多个命令, 并且带有以下两个重要的保证: 1. 事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。 2. 事务是一个原子操作:事务中的命令要么全部被执行,要么全部都不执行。 一个事务从开始到执行会经历以下三个阶段: a. 开始事务。 b. 命令入队。 c. 执行事务。

从服务器只读

从 Redis 二.陆起初,从服务器帮助只读情势,并且该形式为从服务器的暗中认可格局。
只读形式由redis.conf文件中的slave-read-only选项决定,也得以透过CONFIG
SET命令来拉开或关闭那一个形式。
只读从劳动器会拒绝执行任何写命令,所以不会冒出因为操作失误而将数据十分大心写入到了从服务器的气象。固然从服务器是只读的,DEBUG和CONFIG等管理式命令还是是能够使用的,所以我们照旧不该将服务器暴光给互联网也许别的不可信赖互联网。然则,使用redis.conf中的命令改名选项,大家得以因此禁止实施某个命令来升高只读从服务器的安全性。
您大概会感觉惊叹,既然从服务器上的写多少会被重同步数据覆盖,也恐怕在从服务重视启时丢失,那么为何要让叁个从服务器变得可写呢?原因是,1些不根本的临时数据,如故是能够保存在从服务器上边包车型大巴。比如说,客户端能够在从服务器上保存主服务器的可达性(reachability)新闻,从而达成故障转移(failover)策略。

功能

  • 监控(Monitoring)

    Sentinel会不断地检讨你的主服务器和从服务器是还是不是运作如常。

  • 提醒(Notification)

    当被监察和控制的有些Redis服务器出现难题时,Sentinel能够由此API向管理员或许别的应用程序发送文告。

  • 机动故障迁移(Automatic failover)

    当三个主服务器不可能健康办事时,Sentinel会发轫叁回活动故障迁移操作,它会将失效主服务器的个中一个从服务器升级为新的主服务器,并让失效服务器的其余从服务器改为负值新的主服务器;当客户端试图连接失效的主服务器时,集群也会向客户端重回新主服务器的位置,使得集群能够使用新主服务器代替失效服务器。

复制(Replication)

Redis 支持简单且易用的主从复制(master-slave replication)成效,
该功效能够让从服务器(slave server)成为主服务器(master
server)的可信赖仿制品。

以下是关于 Redis 复制效率的多少个非常重要方面:

  1. Redis 使用异步复制。 从 Redis 2.八 开始,
    从服务器会以每秒三回的频率向主服务器报告复制流(replication
    stream)的拍卖速度。

  2. 2个主服务器能够有七个从服务器。

  3. 不光主服务器能够有从服务器, 从服务器也足以有温馨的从服务器,
    多个从服务器之间能够结合3个图状结构。

  4. 复制成效不会阻塞主服务器:
    尽管有2个或三个从服务器正在拓展第2同步,
    主服务器也足以继续处理命令请求。

  5. 复制作用也不会堵塞从服务器:
    只要在redis.conf文件中开始展览了对应的设置,
    尽管从服务器正在进展第二同步,
    服务器也能够运用旧版本的多寡集来处理命令查询。

    可是, 在从服务器删除旧版本数据集并载入新本子数据集的那段时光内,
    连接请求会被卡住。你还足以安排从服务器,
    让它在与主服务器之间的连年断开时, 向客户端发送二个谬误。

  6. 复制作用能够独自地用于数据冗余(data redundancy),
    也足以透过让三个从服务器处理只读命令请求来提高扩展性(scalability):
    比如说, 繁重的SOPRADOT 命令可以提交附属节点去运作。

  7. 能够通过复制作用来让主服务器免于实践持久化操作:
    只要关闭主服务器的持久化成效, 然后由从服务器去实践持久化操作即可。

概念 说明
复制功能的运作原理 无论是初次连接还是重新连接, 当建立一个从服务器时, 从服务器都将向主服务器发送一个 SYNC 命令。接到 SYNC 命令的主服务器将开始执行 BGSAVE , 并在保存操作执行期间, 将所有新执行的写入命令都保存到一个缓冲区里面。当 BGSAVE 执行完毕后, 主服务器将执行保存操作所得的 .rdb 文件发送给从服务器, 从服务器接收这个 .rdb 文件, 并将文件中的数据载入到内存中。之后主服务器会以 Redis 命令协议的格式, 将写命令缓冲区中积累的所有内容都发送给从服务器。你可以通过 telnet 命令来亲自验证这个同步过程: 首先连上一个正在处理命令请求的 Redis 服务器, 然后向它发送 SYNC 命令, 过一阵子, 你将看到 telnet 会话接收到服务器发来的大段数据, 之后还会看到, 所有在服务器执行过的写命令, 都会重新发送到 telnet 会话来。即使有多个从服务器同时向主服务器发送 SYNC , 主服务器也只需执行一次 BGSAVE 命令, 就可以处理所有这些从服务器的同步请求。从服务器可以在主从服务器之间的连接断开时进行自动重连, 在 Redis 2.8 版本之前, 断线之后重连的从服务器总要执行一次完整重同步(full resynchronization)操作, 但是从 Redis 2.8 版本开始, 从服务器可以根据主服务器的情况来选择执行完整重同步还是部分重同步(partial resynchronization)。
部分重同步 从 Redis 2.8 开始, 在网络连接短暂性失效之后, 主从服务器可以尝试继续执行原有的复制进程, 而不一定要执行完整重同步操作。 这个特性需要主服务器为被发送的复制流创建一个内存缓冲区(in-memory backlog), 并且主服务器和所有从服务器之间都记录一个复制偏移量(replication offset)和一个主服务器 ID (master run id), 当出现网络连接断开时, 从服务器会重新连接, 并且向主服务器请求继续执行原来的复制进程: 1. 如果从服务器记录的主服务器 ID 和当前要连接的主服务器的 ID 相同, 并且从服务器记录的偏移量所指定的数据仍然保存在主服务器的复制流缓冲区里面, 那么主服务器会向从服务器发送断线时缺失的那部分数据, 然后复制工作可以继续执行。 2. 否则的话, 从服务器就要执行完整重同步操作。 Redis 2.8 的这个部分重同步特性会用到一个新增的 PSYNC 内部命令, 而 Redis 2.8 以前的旧版本只有 SYNC 命令, 不过, 只要从服务器是 Redis 2.8 或以上的版本, 它就会根据主服务器的版本来决定到底是使用 PSYNC 还是 SYNC : 1. 如果主服务器是 Redis 2.8 或以上版本,那么从服务器使用 PSYNC 命令来进行同步。 2. 如果主服务器是 Redis 2.8 之前的版本,那么从服务器使用 SYNC 命令来进行同步。
只读从服务器 从 Redis 2.6 开始, 从服务器支持只读模式, 并且该模式为从服务器的默认模式。只读模式由 redis.conf 文件中的 slave-read-only 选项控制, 也可以通过 CONFIG SET 命令来开启或关闭这个模式。只读从服务器会拒绝执行任何写命令, 所以不会出现因为操作失误而将数据不小心写入到了从服务器的情况。即使从服务器是只读的, DEBUG 和 CONFIG 等管理式命令仍然是可以使用的, 所以我们还是不应该将服务器暴露给互联网或者任何不可信网络。 不过, 使用 redis.conf 中的命令改名选项, 我们可以通过禁止执行某些命令来提升只读从服务器的安全性。你可能会感到好奇, 既然从服务器上的写数据会被重同步数据覆盖, 也可能在从服务器重启时丢失, 那么为什么要让一个从服务器变得可写呢?原因是, 一些不重要的临时数据, 仍然是可以保存在从服务器上面的。 比如说, 客户端可以在从服务器上保存主服务器的可达性(reachability)信息, 从而实现故障转移策略。
主服务器只在有至少 N 个从服务器的情况下,才执行写操作 从 Redis 2.8 开始, 为了保证数据的安全性, 可以通过配置, 让主服务器只在有至少 N 个当前已连接从服务器的情况下, 才执行写命令。不过, 因为 Redis 使用异步复制, 所以主服务器发送的写数据并不一定会被从服务器接收到, 因此, 数据丢失的可能性仍然是存在的。以下是这个特性的运作原理:1 从服务器以每秒一次的频率 PING 主服务器一次, 并报告复制流的处理情况。 2 主服务器会记录各个从服务器最后一次向它发送 PING 的时间。3 用户可以通过配置, 指定网络延迟的最大值 , 以及执行写操作所需的至少从服务器数量如果至少有 min-slaves-to-write 个从服务器, 并且这些服务器的延迟值都少于 min-slaves-max-lag 秒, 那么主服务器就会执行客户端请求的写操作。你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本: 尽管不能保证写操作的持久性, 但起码丢失数据的窗口会被严格限制在指定的秒数中。另一方面, 如果条件达不到min-slaves-to-write 和 min-slaves-max-lag 所指定的条件, 那么写操作就不会被执行, 主服务器会向请求执行写操作的客户端返回一个错误。以下是这个特性的两个选项和它们所需的参数:1 min-slaves-to-write 2 min-slaves-max-lag 详细的信息可以参考 Redis 源码中附带的 redis.conf 示例文件。

密码验证

即使主服务器通过requirepass选项设置了密码,那么为了让从服务器的同步操作能够顺利举办,我们也务必为从服务器举行相应的身份验证设置。
对于贰个正值运营的服务器,能够行使客户端输入以下命令:

config set masterauth <password>

要永远地安装那个密码,那么能够将它出席到布署文件中:

masterauth <password>

除此以外还有多少个选项,它们和主服务器执行部分重同步时所选拔的复制流缓冲区有关,详细的消息方可参照
Redis 源码中附带的redis.conf示例文件。

sentinel配置

mkdir /data/26380
cp /usr/local/redis/src/redis-sentinel /data/26380
cd /data/26380
Vim sentinel.conf
port 26380
dir "/tmp"
sentinel monitor mymaster 127.0.0.1 6380 2
sentinel down-after-milliseconds mymaster 60000
sentinel config-epoch mymaster 0
启动
 ./redis-sentinel ./sentinel.conf

运维八个Sentinel所需的足足配置如下所示:

澳门金沙国际 4澳门金沙国际 5

运行一个 Sentinel 所需的最少配置如下所示:
sentinel monitor mymaster 127.0.0.1 6379 2 
sentinel down-after-milliseconds mymaster 60000 
sentinel failover-timeout mymaster 180000 
sentinel parallel-syncs mymaster 1 
sentinel monitor resque 192.168.1.3 6380 4 
sentinel down-after-milliseconds resque 10000 
sentinel failover-timeout resque 180000 
sentinel parallel-syncs resque 5
    第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器, 这个主服务器的 IP 地址为 127.0.0.1 , 端口号为 6379 , 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 (只要同意 Sentinel 的数量不达标,自动故障迁移就不会执行)。
    不过要注意, 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效, 一个 Sentinel 都需要获得系统中多数(majority) Sentinel 的支持, 才能发起一次自动故障迁移, 并预留一个给定的配置节点 (configuration Epoch ,一个配置节点就是一个新主服务器配置的版本号)。
    换句话说, 在只有少数(minority) Sentinel 进程正常运作的情况下, Sentinel 是不能执行自动故障迁移的。
其他选项的基本格式如下:
sentinel <选项的名字> <主服务器的名字> <选项的值>
各个选项的功能如下:
    down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
如果服务器在给定的毫秒数之内, 没有返回 Sentinel 发送的 Ping 命令的回复, 或者返回一个错误, 那么 Sentinel 将这个服务器标记为主观下线(subjectively down,简称 SDOWN )。
    不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移: 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后, 服务器才会被标记为客观下线(objectively down, 简称 ODOWN ), 这时自动故障迁移才会执行。
将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。
parallel-syncs 选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长。
    如果从服务器被设置为允许使用过期数据集(参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明), 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求, 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器, 但从服务器在载入主服务器发来的 RDB 文件时, 仍然会造成从服务器在一段时间内不能处理命令请求: 如果全部从服务器一起对新的主服务器进行同步, 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。
你可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。

View Code

事务(transaction)

MULTI 、 EXEC 、 DISCA宝马7系D 和 WATCH 是 Redis
事务的底蕴。事务可以二遍实施八个指令, 并且带有以下多个重点的担保:

  1. 业务是四个独门的割裂操作:事务中的全数命令都会种类化、按顺序地实施。事务在实施的进度中,不会被其它客户端发送来的命令请求所打断。
  2. 事务是一个原子操作:事务中的命令要么全部被实施,要么全体都不履行。EXEC
    命令担负触发并进行工作中的全体命令:
  • 假使客户端在利用 MULTI 开启了3个事情之后,却因为断线而尚未中标实践
    EXEC ,那么事务中的全体命令都不会被执行。
  • 五头,假诺客户端成功在开启事务之后执行 EXEC
    ,那么事务中的全体命令都会被执行。当使用 AOF 情势做持久化的时候,
    Redis 会使用单个 write 命令将业务写入到磁盘中。

可是,如果 Redis
服务器因为一些原因被管理员杀死,只怕遇上某种硬件故障,那么大概只有部分工作命令会被成功写入到磁盘中。如果Redis 在重复运转时发现 AOF
文件出了那般的难点,那么它会脱离,并举报3个荒唐。使用 redis-check-aof
程序能够修复这一题材:它会移除 AOF
文件中不完整事务的音讯,确认保障服务器可以万事大吉运营。从 二.二 版本发轫,Redis
还能够通过乐观锁(optimistic lock)完结 CAS
(check-and-set)操作,具体消息请参见文档的后半部分。

概念 说明
事务中的错误 使用事务时可能会遇上以下两种错误:1. 事务在执行 EXEC 之前,入队的命令可能会出错。比如说,命令可能会产生语法错误(参数数量错误,参数名错误,等等),或者其他更严重的错误,比如内存不足(如果服务器使用 maxmemory 设置了最大内存限制的话)。2. 命令可能在 EXEC 调用之后失败。举个例子,事务中的命令可能处理了错误类型的键,比如将列表命令用在了字符串键上面,诸如此类。对于发生在 EXEC 执行之前的错误,客户端以前的做法是检查命令入队所得的返回值:如果命令入队时返回 QUEUED ,那么入队成功;否则,就是入队失败。如果有命令在入队时失败,那么大部分客户端都会停止并取消这个事务。不过,从 Redis 2.6.5 开始,服务器会对命令入队失败的情况进行记录,并在客户端调用 EXEC 命令时,拒绝执行并自动放弃这个事务。在 Redis 2.6.5 以前, Redis 只执行事务中那些入队成功的命令,而忽略那些入队失败的命令。 而新的处理方式则使得在流水线中包含事务变得简单,因为发送事务和读取事务的回复都只需要和服务器进行一次通讯。至于那些在 EXEC 命令执行之后所产生的错误, 并没有对它们进行特别处理: 即使事务中有某个/某些命令在执行时产生了错误, 事务中的其他命令仍然会继续执行。最重要的是记住这样一条, 即使事务中有某条/某些命令执行失败了, 事务队列中的其他命令仍然会继续执行 —— Redis 不会停止执行事务中的命令。
Redis 不支持回滚 如果你有使用关系式数据库的经验, 那么 “Redis 在事务失败时不进行回滚,而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。 以下是这种做法的优点: 1. Redis 命令只会因为错误的语法而失败(并且这些问题不能在入队时发现),或是命令用在了错误类型的键上面:这也就是说,从实用性的角度来说,失败的命令是由编程错误造成的,而这些错误应该在开发的过程中被发现,而不应该出现在生产环境中。 2. 因为不需要对回滚进行支持,所以 Redis 的内部可以保持简单且快速。 有种观点认为 Redis 处理事务的做法会产生 bug , 然而需要注意的是, 在通常情况下, 回滚并不能解决编程错误带来的问题。 举个例子, 如果你本来想通过 INCR 命令将键的值加上 1 , 却不小心加上了 2 , 又或者对错误类型的键执行了 INCR , 回滚是没有办法处理这些情况的。 鉴于没有任何机制能避免程序员自己造成的错误, 并且这类错误通常不会在生产环境中出现, 所以 Redis 选择了更简单、更快速的无回滚方式来处理事务。
乐观锁 WATCH 命令可以为 Redis 事务提供 check-and-set 行为。 被 WATCH 的键会被监视,并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了, 那么整个事务都会被取消, EXEC 返回空多条批量回复(null multi-bulk reply)来表示事务已经失败。 举个例子, 假设我们需要原子性地为某个值进行增 1 操作(假设 INCR 不存在)。 首先我们可能会这样做: val = GETmykey val = val + 1 SET mykey $val 上面的这个实现在只有一个客户端的时候可以执行得很好。 但是, 当多个客户端同时对同一个键进行这样的操作时, 就会产生竞争条件。 举个例子, 如果客户端 A 和 B 都读取了键原来的值, 比如 10 , 那么两个客户端都会将键的值设为 11 , 但正确的结果应该是 12 才对。 有了 WATCH , 我们就可以轻松地解决这类问题了: WATCH mykey val = GET mykey val = val + 1 MULTI SET mykey $val EXEC 使用上面的代码, 如果在 WATCH 执行之后, EXEC 执行之前, 有其他客户端修改了 mykey 的值, 那么当前客户端的事务就会失败。 程序需要做的, 就是不断重试这个操作, 直到没有发生碰撞为止。 这种形式的锁被称作乐观锁, 它是一种非常强大的锁机制。 并且因为大多数情况下, 不同的客户端会访问不同的键, 碰撞的情况一般都很少, 所以通常并不需要进行重试。
WATCH WATCH 使得 EXEC 命令需要有条件地执行: 事务只能在所有被监视键都没有被修改的前提下执行, 如果这个前提不能满足的话,事务就不会被执行。 如果你使用 WATCH 监视了一个带过期时间的键, 那么即使这个键过期了, 事务仍然可以正常执行, 关于这方面的详细情况,请看这个帖子: http://code.google.com/p/redis/issues/detail?id=270 WATCH 命令可以被调用多次。 对键的监视从 WATCH 执行之后开始生效, 直到调用 EXEC 为止。 用户还可以在单个 WATCH 命令中监视任意多个键, 就像这样: redis> WATCH key1 key2 key3 OK 当 EXEC 被调用时, 不管事务是否成功执行, 对所有键的监视都会被取消。 另外, 当客户端断开连接时, 该客户端对键的监视也会被取消。 使用无参数的 UNWATCH 命令可以手动取消对所有键的监视。 对于一些需要改动多个键的事务, 有时候程序需要同时对多个键进行加锁, 然后检查这些键的当前值是否符合程序的要求。 当值达不到要求时, 就可以使用 UNWATCH 命令来取消目前对键的监视, 中途放弃这个事务, 并等待事务的下次尝试。 WATCH 可以用于创建 Redis 没有内置的原子操作。
Redis 脚本和事务 从定义上来说, Redis 中的脚本本身就是一种事务, 所以任何在事务里可以完成的事, 在脚本里面也能完成。 并且一般来说, 使用脚本要来得更简单,并且速度更快。 因为脚本功能是 Redis 2.6 才引入的, 而事务功能则更早之前就存在了, 所以 Redis 才会同时存在两种处理事务的方法。 不过我们并不打算在短时间内就移除事务功能, 因为事务提供了一种即使不使用脚本, 也可以避免竞争条件的方法, 而且事务本身的实现并不复杂。 不过在不远的将来, 可能所有用户都会只使用脚本来实现事务也说不定。 如果真的发生这种情况的话, 那么我们将废弃并最终移除事务功能。

从服务器写策略

从 Redis 二.八初步,为了保险数据的安全性,能够透过配备,让主服务器只在有最少 N
个当前已一而再从服务器的图景下,才实施写命令。
不过,因为Redis
使用异步复制,所以主服务器发送的写多少并不一定会被从服务器收到到,由此,数据丢失的恐怕依旧是存在的。

安插文件

指定监控master
sentinel monitor mymaster 127.0.0.1 6370 2 
{2表示多少个sentinel同意}
安全信息
sentinel auth-pass mymaster root
超过15000毫秒后认为主机宕机
sentinel down-after-milliseconds mymaster 15000  
当主从切换多久后认为主从切换失败
sentinel failover-timeout mymaster 900000
这两个配置后面的数量主从机需要一样,epoch为master的版本
sentinel leader-epoch mymaster 1
sentinel config-epoch mymaster 1

sentinel

Redis 的 Sentinel 系统用于管理八个 Redis 服务器,
该种类进行以下八个职务:

  1. 监控(Monitoring): Sentinel
    会不断地检讨你的主服务器和从服务器是或不是运作不荒谬。
  2. 提醒(Notification): 当被监督的某部 Redis 服务器出现难题时,
    Sentinel 能够通过 API 向管理员只怕别的应用程序发送文告。
  3. 活动故障迁移(Automatic failover)
    当二个主服务器不可能日常办事时, Sentinel 会开头3回活动故障迁移操作,
    它会将失效主服务器的中间四个从服务器升级为新的主服务器,
    并让失效主服务器的其余从服务器改为复制新的主服务器;
    当客户端试图连接失效的主服务器时,
    集群也会向客户端重临新主服务器的地方,
    使得集群能够应用新主服务器代替失效服务器。

Redis Sentinel 是一个分布式系统, 你能够在一个架构中运维四个 Sentinel
进度, 那几个进度使用传言协议(gossip
protocols)来接受关于主服务器是或不是下线的音信, 并使用投票协议(agreement
protocols)来控制是还是不是履行活动故障迁移,
以及选拔哪个从服务器作为新的主服务器。固然 Redis Sentinel
释出为3个独门的可执行文件 redis-sentinel ,
但实际上它只是二个运作在奇特情势下的 Redis 服务器, 你能够在开发银行1个一般性
Redis 服务器时通过给定 –sentinel 选项来运行 Redis Sentinel 。Redis
Sentinel 近日仍在付出中, 那几个文书档案的始末只怕随着 Sentinel
达成的改动而改变。Redis Sentinel 包容 Redis 二.4.1陆 或以上版本, 推荐应用
Redis 贰.8.0 或上述的本子。

概念 说明
主观下线和客观下线 Redis 的 Sentinel 中关于下线有两个不同的概念:1. 主观下线(Subjectively Down, 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。2. 客观下线(Objectively Down, 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断, 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断。 (一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。)如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内, 对向它发送 PING 命令的 Sentinel 返回一个有效回复(valid reply), 那么 Sentinel 就会将这个服务器标记为主观下线。服务器对 PING 命令的有效回复可以是以下三种回复的其中一种:1. 返回 +PONG 。2. 返回 -LOADING 错误。3. 返回 -MASTERDOWN 错误。如果服务器返回除以上三种回复之外的其他回复, 又或者在指定时间内没有回复 PING 命令, 那么 Sentinel 认为服务器返回的回复无效(non-valid)。注意, 一个服务器必须在 master-down-after-milliseconds 毫秒内, 一直返回无效回复才会被 Sentinel 标记为主观下线。举个例子, 如果 master-down-after-milliseconds 选项的值为 30000 毫秒, 那么只要服务器能在每 29 秒之内返回至少一次有效回复, 这个服务器就仍然会被认为是处于正常状态的。从主观下线状态切换到客观下线状态并没有使用严格的法定人数算法(strong quorum algorithm), 而是使用了流言协议: 如果 Sentinel 在给定的时间范围内, 从其他 Sentinel 那里接收到了足够数量的主服务器下线报告, 那么 Sentinel 就会将主服务器的状态从主观下线改变为客观下线。 如果之后其他 Sentinel 不再报告主服务器已下线, 那么客观下线状态就会被移除。客观下线条件只适用于主服务器: 对于任何其他类型的 Redis 实例, Sentinel 在将它们判断为下线前不需要进行协商, 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。只要一个 Sentinel 发现某个主服务器进入了客观下线状态, 这个 Sentinel 就可能会被其他 Sentinel 推选出, 并对失效的主服务器执行自动故障迁移操作。
每个 Sentinel 都需要定期执行的任务 1. 每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。2. 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 那么这个实例会被 Sentinel 标记为主观下线。 一个有效回复可以是: +PONG 、 -LOADING 或者 -MASTERDOWN 。3. 如果一个主服务器被标记为主观下线, 那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。4. 如果一个主服务器被标记为主观下线, 并且有足够数量的 Sentinel (至少要达到配置文件指定的数量)在指定的时间范围内同意这一判断, 那么这个主服务器被标记为客观下线。5. 在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时, Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。6. 当没有足够数量的 Sentinel 同意主服务器已经下线, 主服务器的客观下线状态就会被移除。 当主服务器重新向 Sentinel 的 PING命令返回有效回复时, 主服务器的主管下线状态就会被移除。
自动发现 Sentinel 和从服务器 一个 Sentinel 可以与其他多个 Sentinel 进行连接, 各个 Sentinel 之间可以互相检查对方的可用性, 并进行信息交换。你无须为运行的每个 Sentinel 分别设置其他 Sentinel 的地址, 因为 Sentinel 可以通过发布与订阅功能来自动发现正在监视相同主服务器的其他 Sentinel , 这一功能是通过向频道 sentinel:hello 发送信息来实现的。与此类似, 你也不必手动列出主服务器属下的所有从服务器, 因为 Sentinel 可以通过询问主服务器来获得所有从服务器的信息。1. 每个 Sentinel 会以每两秒一次的频率, 通过发布与订阅功能, 向被它监视的所有主服务器和从服务器的 sentinel:hello 频道发送一条信息, 信息中包含了 Sentinel 的 IP 地址、端口号和运行 ID 。2. 每个 Sentinel 都订阅了被它监视的所有主服务器和从服务器的 sentinel:hello 频道, 查找之前未出现过的 sentinel (looking for unknown sentinels)。 当一个 Sentinel 发现一个新的 Sentinel 时, 它会将新的 Sentinel 添加到一个列表中, 这个列表保存了 Sentinel 已知的, 监视同一个主服务器的所有其他 Sentinel 。3. Sentinel 发送的信息中还包括完整的主服务器当前配置(configuration)。 如果一个 Sentinel 包含的主服务器配置比另一个 Sentinel 发送的配置要旧, 那么这个 Sentinel 会立即升级到新配置上。4. 在将一个新 Sentinel 添加到监视主服务器的列表上面之前, Sentinel 会先检查列表中是否已经包含了和要添加的 Sentinel 拥有相同运行 ID 或者相同地址(包括 IP 地址和端口号)的 Sentinel , 如果是的话, Sentinel 会先移除列表中已有的那些拥有相同运行 ID 或者相同地址的 Sentinel , 然后再添加新 Sentinel 。
故障转移 一次故障转移操作由以下步骤组成: 1. 发现主服务器已经进入客观下线状态。 2. 对我们的当前纪元进行自增(详情请参考 Raft leader election ), 并尝试在这个纪元中当选。 3. 如果当选失败, 那么在设定的故障迁移超时时间的两倍之后, 重新尝试当选。 如果当选成功, 那么执行以下步骤。 4. 选出一个从服务器,并将它升级为主服务器。 5. 向被选中的从服务器发送 SLAVEOF NO ONE 命令,让它转变为主服务器。 6. 通过发布与订阅功能, 将更新后的配置传播给所有其他 Sentinel , 其他 Sentinel 对它们自己的配置进行更新。 7. 向已下线主服务器的从服务器发送 SLAVEOF 命令, 让它们去复制新的主服务器。 8. 当所有从服务器都已经开始复制新的主服务器时, 领头 Sentinel 终止这次故障迁移操作。 每当一个 Redis 实例被重新配置(reconfigured) —— 无论是被设置成主服务器、从服务器、又或者被设置成其他主服务器的从服务器 —— Sentinel 都会向被重新配置的实例发送一个 CONFIG REWRITE 命令, 从而确保这些配置会持久化在硬盘里。 Sentinel 使用以下规则来选择新的主服务器: 1. 在失效主服务器属下的从服务器当中, 那些被标记为主观下线、已断线、或者最后一次回复 PING 命令的时间大于五秒钟的从服务器都会被淘汰。 2. 在失效主服务器属下的从服务器当中, 那些与失效主服务器连接断开的时长超过 down-after 选项指定的时长十倍的从服务器都会被淘汰。 3. 在经历了以上两轮淘汰之后剩下来的从服务器中, 我们选出复制偏移量(replication offset)最大的那个从服务器作为新的主服务器; 如果复制偏移量不可用, 或者从服务器的复制偏移量相同, 那么带有最小运行 ID 的那个从服务器成为新的主服务器。 Sentinel 自动故障迁移的一致性特质 Sentinel 自动故障迁移使用 Raft 算法来选举领头 Sentinel , 从而确保在一个给定的纪元里, 只有一个领头产生。 这表示在同一个纪元中, 不会有两个 Sentinel 同时被选中为领头, 并且各个 Sentinel 在同一个纪元中只会对一个领头进行投票。 更高的配置纪元总是优于较低的纪元, 因此每个 Sentinel 都会主动使用更新的纪元来代替自己的配置。 简单来说, 我们可以将 Sentinel 配置看作是一个带有版本号的状态。 一个状态会以最后写入者胜出(last-write-wins)的方式(也即是,最新的配置总是胜出)传播至所有其他 Sentinel 。 举个例子, 当出现网络分割(network partitions)时, 一个 Sentinel 可能会包含了较旧的配置, 而当这个 Sentinel 接到其他 Sentinel 发来的版本更新的配置时, Sentinel 就会对自己的配置进行更新。 如果要在网络分割出现的情况下仍然保持一致性, 那么应该使用 min-slaves-to-write 选项, 让主服务器在连接的从实例少于给定数量时停止执行写操作, 与此同时, 应该在每个运行 Redis 主服务器或从服务器的机器上运行 Redis Sentinel 进程。Sentinel 状态的持久化 Sentinel 的状态会被持久化在 Sentinel 配置文件里面。 每当 Sentinel 接收到一个新的配置, 或者当领头 Sentinel 为主服务器创建一个新的配置时, 这个配置会与配置纪元一起被保存到磁盘里面。 这意味着停止和重启 Sentinel 进程都是安全的。 Sentinel 在非故障迁移的情况下对实例进行重新配置 即使没有自动故障迁移操作在进行, Sentinel 总会尝试将当前的配置设置到被监视的实例上面。 特别是: 1. 根据当前的配置, 如果一个从服务器被宣告为主服务器, 那么它会代替原有的主服务器, 成为新的主服务器, 并且成为原有主服务器的所有从服务器的复制对象。 2. 那些连接了错误主服务器的从服务器会被重新配置, 使得这些从服务器会去复制正确的主服务器。 不过, 在以上这些条件满足之后, Sentinel 在对实例进行重新配置之前仍然会等待一段足够长的时间, 确保可以接收到其他 Sentinel 发来的配置更新, 从而避免自身因为保存了过期的配置而对实例进行了不必要的重新配置。
TILT 模式 Redis Sentinel 严重依赖计算机的时间功能: 比如说, 为了判断一个实例是否可用, Sentinel 会记录这个实例最后一次相应 PING 命令的时间, 并将这个时间和当前时间进行对比, 从而知道这个实例有多长时间没有和 Sentinel 进行任何成功通讯。不过, 一旦计算机的时间功能出现故障, 或者计算机非常忙碌, 又或者进程因为某些原因而被阻塞时, Sentinel 可能也会跟着出现故障。TILT 模式是一种特殊的保护模式: 当 Sentinel 发现系统有些不对劲时, Sentinel 就会进入 TILT 模式。因为 Sentinel 的时间中断器默认每秒执行 10 次, 所以我们预期时间中断器的两次执行之间的间隔为 100 毫秒左右。 Sentinel 的做法是, 记录上一次时间中断器执行时的时间, 并将它和这一次时间中断器执行的时间进行对比:1. 如果两次调用时间之间的差距为负值, 或者非常大, 那么 Sentinel 进入 TILT 模式。2. 如果 Sentinel 已经进入 TILT 模式, 那么 Sentinel 延迟退出 TILT 模式的时间。当 Sentinel 进入 TILT 模式时, 它仍然会继续监视所有目标, 但是:1. 它不再执行任何操作,比如故障转移。2. 当有实例向这个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令时, Sentinel 返回负值: 因为这个 Sentinel 所进行的下线判断已经不再准确。如果 TILT 可以正常维持 30 秒钟, 那么 Sentinel 退出 TILT 模式。

以下是这么些特点的运营规律:

  • 1.从服务器以每秒三遍的频率 PING
    主服务器三次,并报告复制流的拍卖状态。
  • 二.主服务器会记录各样从服务器最终3遍向它发送 PING 的时辰。
  • 三.用户能够因而布置,内定互连网延迟的最大值 min-slaves-max-lag
    ,以及履行写操作所需的起码从服务器数量 min-slaves-to-write 。
  • 四.比方至少有 min-slaves-to-write
    个从服务器,并且那一个服务器的延迟值都有数 min-slaves-max-lag
    秒,那么主服务器就会执行客户端请求的写操作。
  • 伍.你能够将以此本性看作 CAP 理论中的 C
    的规格放宽版本:尽管不可能保障写操作的持久性,但最少丢失数据的窗口会被严格界定在钦赐的秒数中。
    单向,假如基准达不到 min-slaves-to-write 和 min-slaves-max-lag
    所内定的条件,那么写操作就不会被实践,主服务器会向请求执行写操作的客户端重回三个谬误。
    以下是那一个特点的七个挑选和它们所需的参数:

    min-slaves-to-write <number of slaves>
    min-slaves-max-lag <number of seconds>
    #详细的信息可以参考 Redis 源码中附带的 redis.conf 示例文件。
    

Sentinel命令

PING :返回 PONG 。
SENTINEL masters :列出所有被监视的主服务器
SENTINEL slaves <master name> 
SENTINEL get-master-addr-by-name <master name> : 返回给定名字的主服务器的 IP 地址和端口号。 
SENTINEL reset <pattern> : 重置所有名字和给定模式 pattern 相匹配的主服务器。 
SENTINEL failover <master name> : 当主服务器失效时, 在不询问其他 Sentinel 意见的情况下, 强制开始一次自动故障迁移。

其他

集群教程Redis 集群规范

个人介绍:

高广超:多年分寸网络研究开发与架构设计经验,擅长设计与出生高可用、高质量、可增添的互连网架构。

正文首发在 高广超的简书博客 转载请注脚!

澳门金沙国际 6简书博客澳门金沙国际 7头条号

从Redis 持久化

另三个相对耗费时间的操作是持久化,为了增长质量,能够因而复制作用建立2个(或若干个)从数据库,并在从数据库中启用持久化,同时在主数据库禁止使用持久化。当从数据库崩溃时重启后主数据库会活动将数据同步过来所以无需操心数据丢失。而当主数据库崩溃时,必要在从数据库中使用SLAVEOF NO ONE指令将从数据库升高成主数据库继续服务,并在原来的主数据库运转后使用SLAVEOF命令将其设置成新的主数据库的从数据库,即可将数据同步回来。

Redis的小编Salvatore
Sanfilippo曾经见报过Redis宣言一,在那之中提到Redis以简练为美。同样在安全范围Redis也尚无做太多的做事。

三、Redis集群

Redis集群是一个可以在多个Redis节点之间进行数据共享的设施(installation)。
Redis集群不支持那些需要同时处理多个键的Redis命令,因为执行这些命令需要在多个Redis节点之间移动数据,并且在高负载的情况下,这些命令降低Redis集群的性能,并导致不可预测的行为。
Redis集群通过分区(partition)来提供一定程度的可用性(availability):即使集群中有一部分节点失效或者无法进行通讯,集群也可以继续处理命令请求。
将数据自动切分(split)到多个节点的能力。
当集群中的一部分节点失效或者无法进行通讯时,仍然可以继续处理命令请求的能力。

Redis集群数据共享

Redis集群使用数据分片(sharding)而非一致性哈希(consistency hashing)来实现:一个Redis集群包含16384个哈希槽(hash slot),数据库中的每个键都属于这16384个哈希槽的其中一个,集群使用公式CRC16(key)%16384来计算键key属于哪个槽,其中CRC16(key)语句用于计算键key的CRC16校验和。
节点A负责处理0号至5500号哈希槽。
节点B负责处理5501号至11000号哈希槽。
节点C负责处理11001号至16384号哈希槽。

Redis Cluster

澳门金沙国际 8

集群组件安装

EPEL源安装ruby支持
yum install ruby rubygems -y
使用国内源
gem sources --add https://gems.ruby-china.org/ --remove https://rubygems.org/
gem install redis -v 3.3.3
gem sources -l
如果无法使用,可以使用aliyun
gem sources -a http://mirrors.aliyun.com/rubygems/ 
gem sources  --remove http://rubygems.org/

布局文件中蕴藏

Redis 集群由多个运行在集群模式(cluster mode)下的 Redis 实例组成, 实例的集群模式需要通过配置来开启, 开启集群模式的实例将可以使用集群特有的功能和命令。

以下是多个富含了最少选项的集群配置文件示例:

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

文件中的 cluster-enabled 选项用于开实例的集群模式, 而 cluster-conf-file 选项则设定了保存节点配置文件的路径, 默认值为 nodes.conf 。
节点配置文件无须人为修改, 它由 Redis 集群在启动时创建, 并在有需要时自动进行更新。
要让集群正常运作至少需要三个主节点, 不过在刚开始试用集群功能时, 强烈建议使用六个节点: 其中三个为主节点, 而其余三个则是各个主节点的从节点。

cd /data
mkdir cluster-test
cd cluster-test
mkdir 7000 7001 7002 7003 7004 7005

创设应用

mkdir cluster-test
cd cluster-test
mkdir 7000 7001 7002 7003 7004 7005

拷贝应用
cp redis.conf redis-server ./7000
启动应用
cd 7000
./redis-server ./redis.conf

创设集群

{redis_src_home}/src/redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 \
127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

给定 redis-trib.rb 程序的命令是 create , 这表示我们希望创建一个新的集群。
选项 --replicas 1 
表示我们希望为集群中的每个主节点创建一个从节点。

集群客户端

redis-cli -c -p 7000
set foo bar
get foo

重新分片
./redis-trib.rb reshard 127.0.0.1:7000

集群众管理理

集群状态
redis-cli -p 7000 cluster nodes | grep master
故障转移
redis-cli -p 7002 debug segfault
查看状态
redis-cli -p 7000 cluster nodes | grep master


增加新的节点
./redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000
删除一个节点
redis-trib del-node ip:port '<node-id>' 
删除master节点之前首先要使用reshard移除master的全部slot,然后再删除当前节点
添加一个从节点
./redis-trib.rb add-node --slave --master-id $[nodeid] 127.0.0.1:7008 127.0.0.1:7000 

情景表明

集群最近一次向节点发送 PING 命令之后, 过去了多长时间还没接到回复。
节点最近一次返回 PONG 回复的时间。
节点的配置节点(configuration epoch):详细信息请参考 Redis 集群规范 。
本节点的网络连接情况:例如 connected 。
节点目前包含的槽:例如 127.0.0.1:7001 目前包含号码为 5960 至 10921 的哈希槽。

 

相关文章