您的位置:时时app平台注册网站 > 时时app平台注册网站 > Redis高可用及分片集群

Redis高可用及分片集群

2019-11-03 12:54

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所需的起码配置如下所示:

图片 1图片 2

运行一个 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

sentinel

Redis 的 Sentinel 系统用于管理多个 Redis 服务器, 该系统实践以下多个义务:

  1. 监控(Monitoring): Sentinel 会不断地检讨你的主服务器和从服务器是或不是运作如常。
  2. 提醒(Notification): 当被监督的某部 Redis 服务器现身难题时, Sentinel 能够通过 API 向管理员或然其余应用程序发送文告。
  3. 机关故障迁移(Automatic failover卡塔尔国: 当贰个主服务器不能够健康职业时, Sentinel 会开端贰遍机关故障迁移操作, 它会将失效主服务器的内部二个从服务器晋级为新的主服务器, 并让失效主服务器的其余从服务器改为复制新的主服务器; 当顾客端试图连接失效的主服务器时, 集群也会向客户端重回新主服务器的地点, 使得集群能够接收新主服务器替代失效服务器。

Redis Sentinel 是二个分布式系统, 你能够在一个架构中运转四个 Sentinel 进度, 这几个经过使用流言合同(gossip protocols)来选取关于主服务器是或不是下线的消息, 并使用投票公约(agreement protocols卡塔 尔(阿拉伯语:قطر‎来调节是不是实施机关故障迁移, 以致选拔哪位从服务器作为新的主服务器。固然 Redis Sentinel 释出为一个单身的可试行文件 redis-sentinel , 但实际上它只是三个运维在特种格局下的 Redis 服务器, 你可以在起步二个普通 Redis 服务器时通过给定 --sentinel 选项来运行 Redis Sentinel 。Redis Sentinel 近年来仍在开荒中, 那些文书档案的内容大概随着 Sentinel 达成的改造而改动。Redis Sentinel 包容 Redis 2.4.16 或以上版本, 推荐使用 Redis 2.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 模式。

Redis命令参谋之复制(Replication卡塔 尔(英语:State of Qatar)

Redis 扶植轻便且易用的主从复制(master-slave replication卡塔尔成效, 该功效能够让从服务器(slave server)成为主服务器(master server)的纯粹仿制品。

以下是关于 Redis 复制作用的多少个首要方面:

Redis 使用异步复制。 从 Redis 2.8 开头, 从服务器会以每秒三次的频率向主服务器报告复制流(replication stream卡塔尔的管理速度。

四个主服务器能够有八个从服务器。

不光主服务器能够有从服务器, 从服务器也足以有和煦的从服务器, 八个从服务器之间能够结合四个图状结构。

复制功效不会窒碍主服务器: 尽管有三个或八个从服务器正在进展第一齐步, 主服务器也得以三番陆回管理命令恳求。

复制功用也不会梗塞从服务器: 只要在 redis.conf 文件中开展了相应的装置, 尽管从服务器正在拓宽第一齐步, 服务器也能够运用旧版本的数目集来管理命令查询。

唯独, 在从服务器删除旧版本数据集并载入新本子数据集的这段时光内, 连接央浼会被封堵。

你还能配备从服务器, 让它在与主服务器之间的连年断开时, 向客户端发送一个错误。

复制作用能够独自地用来数据冗余(data redundancy卡塔尔, 也能够透过让多个从服务器管理只读命令须要来提高扩充性(scalability卡塔尔: 比方说, 劳碌的 SORT 命令能够提交从属节点去运营。

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

复制功用的周转规律
无论初次连接仍旧再度连接, 当建设构造二个从服务器时, 从服务器都将向主服务器发送三个 SYNC 命令。

接到 SYNC 命令的主服务器将启幕施行 BGSAVE , 并在保存操作试行时期, 将有所新执行的写入命令都保留到二个缓冲区里面。

当 BGSAVE 实行实现后, 主服务器将实施保存操作所得的 .rdb 文件发送给从服务器, 从服务器收到这么些 .rdb 文件, 并将文件中的数据载入到内部存款和储蓄器中。

从此主服务器会以 Redis 命令公约的格式, 将写命令缓冲区中积攒的具备内容都发送给从服务器。

你能够通过 telnet 命令来亲自表达那么些合伙进度: 首先连上两个正在管理命令须求的 Redis 服务器, 然后向它发送 SYNC 命令, 过会儿, 你将见到 telnet 会话(session卡塔尔国接纳到服务器发来的大段数据(.rdb 文件卡塔 尔(阿拉伯语:قطر‎, 之后还拜谒到, 全数在服务器实施过的写命令, 都会再次发送到 telnet 会话来。

就算有多少个从服务器同卓殊候向主服务器发送 SYNC , 主服务器也只需试行一遍BGSAVE 命令, 即可拍卖全数那几个从服务器的同步需要。

从服务器能够在主导服务器之间的连年断开时开展机动重连, 在 Redis 2.8 版本以前, 断线之后重连的从服务器总要实施二遍完整重同步(full resynchronization卡塔 尔(英语:State of Qatar)操作, 可是从 Redis 2.8 版本开端, 从服务器可以依赖主服务器的场合来接纳实践总体重同步照旧有个别重同步(partial resynchronization卡塔 尔(阿拉伯语:قطر‎。

某个重同步
从 Redis 2.8 起始, 在网络连接短暂性失效之后, 主从服务器可以品尝继续推行原有的复制进度(process卡塔 尔(阿拉伯语:قطر‎, 而不自然要试行总体重同步操作。

本条天性须要主服务器为被发送的复制流创立八个内部存款和储蓄器缓冲区(in-memory backlog卡塔尔, 况兼主服务器和富有从服务器之间都记录三个复制偏移量(replication offset卡塔 尔(英语:State of Qatar)和贰个主服务器 ID (master run id卡塔 尔(阿拉伯语:قطر‎, 当现身互连网连接断开时, 从服务器会另行连接, 并且向主服务器央求继续试行原本的复制进度:

譬如从服务器记录的主服务器 ID 和脚下要三回九转的主服务器的 ID 相像, 何况从服务器记录的偏移量所钦赐的多寡照旧保留在主服务器的复制流缓冲区里面, 那么主服务器会向从服务器发送断线时缺点和失误的这部分多少, 然后复制专门的学业得以继续推行。
不然的话, 从服务器就要实践总体重同步操作。
Redis 2.8 的这么些部分重同步天性会用到二个新扩充的 PSYNC 内部命令, 而 Redis 2.8 早前的旧版本独有 SYNC 命令, 但是, 只要从服务器是 Redis 2.8 或上述的本子, 它就能够依据主服务器的版本来支配到底是应用 PSYNC 照旧 SYNC :

假使主服务器是 Redis 2.8 或上述版本,那么从服务器使用 PSYNC 命令来张开同步。
假若主服务器是 Redis 2.8 在此之前的版本,那么从服务器使用 SYNC 命令来张开同步。
配置
陈设三个从服务器特别轻易, 只要在配置文件中增添以下的那风姿洒脱行就能够了:

slaveof 192.168.1.1 6379
理所必然, 你须要将代码中的 192.168.1.1 和 6379 替换到你的主服务器的 IP 和端口号。

此外风华正茂种办法是调用 SLAVEOF 命令, 输入主服务器的 IP 和端口, 然后一同就能够发轫:

127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK
只读从服务器
从 Redis 2.6 初始, 从服务器扶持只读格局, 並且该格局为从服务器的暗许形式。

只读格局由 redis.conf 文件中的 slave-read-only 选项决定, 也能够经过 CONFIG SET 命令来拉开或关闭这几个形式。

只读从服务器会拒却试行任何写命令, 所以不会现身因为操作失误而将数据非常大心写入到了从服务器的情形。

尽管从服务器是只读的, DEBUG 和 CONFIG 等管理式命令仍是能够利用的, 所以大家还是不应当将服务器暴光给网络或许别的不可信赖赖互连网。 不过, 使用 redis.conf 中的命令改名选项, 大家得以经过防止施行某个命令来升高只读从服务器的安全性。

你或者会认为愕然, 既然从服务器上的写多少会被重同步数据覆盖, 也说不佳在从服务珍视启时遗失, 那么为啥要让贰个从服务器变得可写呢?

原因是, 一些不主要的暂且数据, 仍为能够保存在从服务器下面的。 比方说, 客户端能够在从服务器上保存主服务器的可达性(reachability卡塔 尔(英语:State of Qatar)新闻, 进而落成故障转移(failover卡塔尔国计策。

从服务器相关配置
假设主服务器通过 requirepass 选项设置了密码, 那么为了让从服务器的同步操作可以顺遂举办, 大家也必须要为从服务器举办相应的身份验证设置。

对此三个正值运营的服务器, 能够动用客商端输入以下命令:

config set masterauth <password>
要永世地安装这一个密码, 那么能够将它出席到布置文件中:

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

主服务器只在有最少 N 个从服务器的事态下,才实践写操作¶
从 Redis 2.8 初叶, 为了有限支撑数据的安全性, 可以因此布署, 让主服务器只在有最少 N 个当前已接连从服务器的气象下, 才实践写命令。

只是, 因为 Redis 使用异步复制, 所以主服务器发送的写多少并不一定会被从服务器收到到, 因而, 数据遗失的可能性依然是存在的。

以下是以此特性的周转规律:

从服务器以每秒二次的作用 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 所钦赐的规格, 那么写操作就不会被推行, 主服务器会向乞求实践写操作的客户端再次来到二个漏洞非常多。

以下是那些特点的多个选用和它们所需的参数:

min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>
详尽的新闻方可参谋 Redis 源码中附带的 redis.conf 示例文件。

Ubuntu 14.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)成为主服...

二、Redis Sentinel

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

其他

集群教程Redis 集群标准

村办介绍:

高广超:多年微薄互连网研究开发与架构划杜撰计涉世,专长设计与出生高可用、高质量、可扩充的互连网架构。

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

图片 3简书博客图片 4头条号

三、Redis集群

Redis集群是一个可以在多个Redis节点之间进行数据共享的设施(installation)。
Redis集群不支持那些需要同时处理多个键的Redis命令,因为执行这些命令需要在多个Redis节点之间移动数据,并且在高负载的情况下,这些命令降低Redis集群的性能,并导致不可预测的行为。
Redis集群通过分区(partition)来提供一定程度的可用性(availability):即使集群中有一部分节点失效或者无法进行通讯,集群也可以继续处理命令请求。
将数据自动切分(split)到多个节点的能力。
当集群中的一部分节点失效或者无法进行通讯时,仍然可以继续处理命令请求的能力。
  1. Redis扶植数据的长久化,能够将内部存款和储蓄器中的多寡保持在磁盘中,重启的时候能够重新加载举行利用。
  2. Redis不止扶持简单的key-value类型的数额,同一时候还提供list,set,zset,hash等数据结构的仓库储存。
  3. Redis扶植数据的备份,即master-slave格局的数据备份。

创造应用

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 优势 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可以做很多内部复杂性很强的事情。 同时,在磁盘格式方面他们是紧凑的以追加的方式产生的,因为他们并不需要进行随机访问。

Sentinel的构造

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

图片 5

复制(Replication)

Redis 辅助简单且易用的主从复制(master-slave replication卡塔 尔(英语:State of Qatar)功效, 该意义可以让从服务器(slave server)成为主服务器(master server)的正确仿制品。

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

  1. Redis 使用异步复制。 从 Redis 2.8 领头, 从服务器会以每秒三遍的频率向主服务器报告复制流(replication stream卡塔 尔(英语:State of Qatar)的拍卖速度。

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

  3. 岂但主服务器能够有从服务器, 从服务器也足以有本人的从服务器, 八个从服务器之间能够结合多个图状结构。

  4. 复制功用不会窒碍主服务器: 纵然有四个或多个从服务器正在进行第一齐步, 主服务器也能够三翻五次管理命令央浼。

  5. 复制效能也不会卡住从服务器: 只要在redis.conf文件中实行了对应的安装, 尽管从服务器正在张开第一起步, 服务器也得以应用旧版本的多寡集来管理命令查询。

    但是, 在从服务器删除旧版本数据集并载入新本子数据集的这段岁月内, 连接乞请会被堵塞。你还是能安顿从服务器, 让它在与主服务器之间的接连断开时, 向顾客端发送一个乖谬。

  6. 复制功用可以单独地用于数据冗余(data redundancy卡塔 尔(阿拉伯语:قطر‎, 也能够经过让多少个从服务器管理只读命令诉求来提升扩充性(scalability卡塔尔: 比方说, 艰苦的SORT 命令能够交到从属节点去运作。

  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 示例文件。

地方表达

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

 

事务(transaction)

MULTI 、 EXEC 、 DISCAHighlanderD 和 WATCH 是 Redis 事务的根基。事务能够贰遍试行多个指令, 何况带有以下八个重大的有限支撑:

  1. 业务是四个单身的隔开分离操作:事务中的全数命令都会种类化、按梯次地施行。事务在实行的进度中,不会被别的客户端发送来的吩咐请求所打断。
  2. 事情是二个原子操作:事务中的命令要么全体被施行,要么全体都不推行。EXEC 责成触发并进行职业中的全数命令:
  • 如若客商端在接受 MULTI 开启了三个工作之后,却因为断线而并未有得逞实行EXEC ,那么事务中的全部命令都不会被实施。
  • 一头,若是顾客端成功在拉开事务之后试行 EXEC ,那么事务中的全体命令都会被实行。当使用 AOF 形式做长久化的时候, Redis 会使用单个 write 命令将业务写入到磁盘中。

只是,要是 Redis 服务器因为某个原因被管理员杀死,大概遇上某种硬件故障,那么恐怕唯有部分业务命令会被成功写入到磁盘中。假诺Redis 在重新运转时开掘 AOF 文件出了那般的难题,那么它会退出,并报告七个错误。使用 redis-check-aof 程序能够修复那风度翩翩题目:它会移除 AOF 文件中缺损事务的音讯,确认保证服务器能够高枕而卧运营。从 2.2 版本开始,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集群数据分享

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

数据类型

概念 说明
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的成员是唯一的,但分数却可以重复。

布署文件

指定监控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

基本概念

概念 说明
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_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 
表示我们希望为集群中的每个主节点创建一个从节点。

图片 6image.png

布局文件中蕴藏

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

Redis 与此外 key - value 缓存成品有以下六本性状:

集群管理

集群状态
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 

集群组件安装

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主从复制实施

环境:

/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主从复制管理

主从复制状态监控:
info replication

主从切换:
slaveof no one

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 Cluster

图片 7

集群客商端

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

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

功能

  • 监控(Monitoring)

    Sentinel会不断地检讨你的主服务器和从服务器是或不是运作符合规律。

  • 提醒(Notification)

    当被监察和控制的某部Redis服务器现身难点时,Sentinel能够通过API向管理员或然此外应用程序发送文告。

  • 自行故障迁移(Automatic failover)

    当一个主服务器不能够健康干活时,Sentinel会最早一遍机关故障迁移操作,它会将失效主服务器的内部四个从服务器进级为新的主服务器,并让失效服务器的其他从服务器改为负值新的主服务器;当顾客端试图连接失效的主服务器时,集群也会向客商端重临新主服务器的地址,使得集群能够选拔新主服务器代替失效服务器。

运维原理

从服务器以每秒一次的频率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所指定的条件,那么写操作就不会执行,主服务器会向请求执行写操作的客户端返回一个错误。

风流倜傥、主从复制

  • 利用异步复制
  • 多少个服务器可以有多个从服务器
  • 从服务器也足以有友好的从服务器
  • 复制效能不会拥塞主服务器
  • 能够通过劳务功效来上主服务器免于持久化操作,由从服务器去实施长久化操作就可以。

图片 8

以下是有关Redis复制成效的多少个首要方面:

  • Redis使用异步复制。从Redis 2.8以前,从服务器会以每秒三回的作用向主服务器报告复制流(replication stream卡塔尔的拍卖速度。
  • 一个主服务器能够有多少个从服务器。
  • 岂但主服务器能够有从服务器,从服务器也足以有自身的从服务器,三个从服务器之间能够整合三个图状结构。
  • 复制功用不会堵塞主服务器: 即便有三个或七个从服务器正在拓宽第一齐步, 主服务器也能够继续管理命令诉求。
  • 复制作用也不会卡住从服务器: 只要在 redis.conf 文件中进行了相应的安装, 尽管从服务器正在开展第一起步, 服务器也足以动用旧版本的多寡集来管理命令查询。
  • 然则, 在从服务器删除旧版本数据集并载入新本子数据集的这段岁月内, 连接恳求会被拥塞。
  • 您还是能够配备从服务器, 让它在与主服务器之间的三回九转断开时, 向顾客端发送三个荒谬。
  • 复制作而成效能够唯有地用于数据冗余(data redundancy卡塔 尔(阿拉伯语:قطر‎, 也得以因此让八个从服务器管理只读命令央浼来提高扩充性(scalability卡塔尔: 比方说, 辛苦的 SORT 命令能够提交从属节点去运行。
  • 能够通过复制功用来让主服务器免于执行持久化操作: 只要关闭主服务器的长久化作用, 然后由从服务器去实践长久化操作就能够。

本文由时时app平台注册网站发布于时时app平台注册网站,转载请注明出处:Redis高可用及分片集群

关键词: