您的位置:新葡亰496net > 电脑系统 > Redis焦点概念,Redis高可用及分片集群

Redis焦点概念,Redis高可用及分片集群

发布时间:2019-08-31 17:40编辑:电脑系统浏览(146)

    一、主从复制

    • 选拔异步复制
    • 一个服务器能够有七个从服务器
    • 从服务器也得以有自身的从服务器
    • 复制效率不会阻塞主服务器
    • 能够经过服务职能来上主服务器免于长久化操作,由从服务器去试行漫长化操作就可以。

    新葡亰496net 1

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

    • Redis使用异步复制。从Redis 2.8从头,从服务器会以每秒一回的频率向主服务器报告复制流(replication stream)的管理速度。
    • 三个主服务器能够有两个从服务器。
    • 岂但主服务器能够有从服务器,从服务器也足以有温馨的从服务器,四个从服务器之间能够组成贰个图状结构。
    • 复制作用不会阻塞主服务器: 固然有叁个或多少个从服务器正在展开第一齐步, 主服务器也能够持续管理命令乞求。
    • 复制功效也不会堵塞从服务器: 只要在 redis.conf 文件中展开了对应的设置, 即便从服务器正在实行第一起步, 服务器也得以选取旧版本的多少集来管理命令查询。
    • 只是, 在从服务器删除旧版本数据集并载入新本子数据集的近日内, 连接诉求会被打断。
    • 您仍可以配备从服务器, 让它在与主服务器之间的接连断开时, 向客商端发送三个错误。
    • 复制功能能够独自地用来数据冗余(data redundancy), 也得以透过让多个从服务器管理只读命令央浼来提高增添性(scalability): 譬喻说, 繁重的 SORT 命令能够交到附属节点去运作。
    • 可以透过复制功效来让主服务器免于推行持久化操作: 只要关闭主服务器的漫长化成效, 然后由从服务器去执行悠久化操作就可以。

    新葡亰496net 2image.png

    Redis命令参谋之复制(Replication)

    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)操作, 可是从 Redis 2.8 版本起先, 从服务器能够依靠主服务器的景况来抉择试行总身体重量同步如故有的重同步(partial resynchronization)。

    一部分重同步
    从 Redis 2.8 开头, 在网络连接短暂性失效之后, 主从服务器能够尝试继续实行原有的复制进度(process), 而不必然要实行总体重同步操作。

    这几个特点要求主服务器为被发送的复制流创制贰个内部存款和储蓄器缓冲区(in-memory backlog), 况兼主服务器和全数从服务器之间都记录三个复制偏移量(replication offset)和贰个主服务器 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)新闻, 进而完成故障转移(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)成为主服...

    Reids主从复制

    为了幸免单点故障,我们盼望将数据库复制五个别本以安顿在分歧的服务器上,尽管有一台服务器现身故障别的服务器还是可以够继续提供服务。
    那将要求当一台服务器上的数据库更新后,能够自动将创新的数目同步到其他服务器上,Redis提供了复制(replication)功效能够自行实现同台的历程。
    Redis 协理轻松且易用的主从复制(master-slave replication)功用,该作用能够让从服务器(slave server)成为主服务器(master server)的高精度仿制品。

    Redis焦点概念,Redis高可用及分片集群。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.不但主服务器能够有从服务器,从服务器也能够有投机的从服务器,四个从服务器之间能够组成多少个图状结构。
    • 4.复制功用不会阻塞主服务器:固然有三个或多少个从服务器正在开展第一齐步,主服务器也得以承继处理命令乞求。
      复制功能也不会卡住从服务器:只要在 redis.conf 文件中实行了对应的装置,尽管从服务器正在扩充第一齐步,服务器也足以选择旧版本的数目集来管理命令查询。
    • 5.然而,在从服务器删除旧版本数据集并载入新本子数据集的方今内,连接央浼会被封堵。你还是能够配备从服务器,让它在与主服务器之间的延续断开时,向客商端发送贰个荒唐。
    • 6.复制功用能够单独地用于数据冗余(data redundancy),也得以经过让多少个从服务器管理只读命令需要来升高扩张性(scalability):比方说,繁重的 SORT 命令能够交给附属节点去运作。
    • 7.足以透过复制作用来让主服务器免于施行长久化操作:只要关闭主服务器的持久化成效,然后由从服务器去实施长久化操作就能够。

    以下是关于 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所指定的条件,那么写操作就不会执行,主服务器会向请求执行写操作的客户端返回一个错误。
    
    1. Redis支持数据的持久化,能够将内部存款和储蓄器中的数目保持在磁盘中,重启的时候能够重复加载进行利用。
    2. Redis不止扶助简单的key-value类型的多寡,同一时间还提供list,set,zset,hash等数据结构的蕴藏。
    3. Redis援助数据的备份,即master-slave格局的数据备份。

    Redis复制职业规律

    • 1.无论是初次连接照旧重新连接,当建构三个从服务器时,从服务器都将向主服务器发送二个SYNC命令。
    • 2.摄取SYNC命令的主服务器将启幕实施BGSAVE,并在保留操作施行时期,将具有新实践的写入命令都保存到三个缓冲区里面。
    • 3.当BGSAVE实行实现后,主服务器将实行保存操作所得的.rdb文件发送给从服务器,从服务器收到那个.rdb文件,并将文件中的数据载入到内部存款和储蓄器中。
    • 4.之后主服务器会以 Redis 命令公约的格式,将写命令缓冲区中储存的具有内容都发送给从服务器。

    • 5.你能够通过 telnet 命令来亲自表明那几个合伙进程:首先连上三个正值管理命令须要的 Redis 服务器,然后向它发送SYNC命令,过会儿,你将看到 telnet 会话(session)接收到服务器发来的大段数据(.rdb文件),之后还有大概会看到,全部在服务器试行过的写命令,都会再次发送到 telnet 会话来。

    • 6.固然有三个从服务器同有的时候间向主服务器发送SYNC,主服务器也只需进行二遍BGSAVE命令,就能够管理全部这个从服务器的同台央求。
    • 7.从服务器能够在宗旨服务器之间的接二连三断开时开展机动重连,在 Redis 2.8 版本从前,断线之后重连的从服务器总要实践二次完整重同步(full resynchronization)操作,可是从 Redis 2.8 版本起头,从服务器可以依附主服务器的图景来摘取试行总体重同步依然某些重同步(partial resynchronization)。

    Redis 使用异步复制。 从 Redis 2.8 开端, 从服务器会以每秒壹遍的频率向主服务器报告复制流(replication stream)的管理速度。

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

    局部重同步

    从 Redis 2.8 最早,在网络连接短暂性失效之后,主从服务器能够尝尝继续施行原有的复制进程(process),而不自然要施行总体重同步操作。

    其一性情需求主服务器为被发送的复制流创制三个内部存款和储蓄器缓冲区(in-memory backlog),何况主服务器和全体从服务器之间都记录二个复制偏移量(replication offset)和贰个主服务器 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 命令来进展共同。

    一个主服务器能够有三个从服务器。

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

    中央配置

    计划一个从服务器极度轻易,只要在布局文件中追加以下的这一行就能够了:
    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

    不止主服务器能够有从服务器, 从服务器也能够有和好的从服务器, 八个从服务器之间能够结合一个图状结构。

    Sentinel的构造

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

    新葡亰496net 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 2.6 开始,从服务器帮助只读形式,并且该形式为从服务器的暗中同意方式。
    只读方式由redis.conf文件中的slave-read-only选项决定,也可以因此CONFIG SET命令来张开或关闭那个方式。
    只读从服务器会拒绝推行任何写命令,所以不会现出因为操作失误而将数据极大心写入到了从服务器的动静。即使从服务器是只读的,DEBUG和CONFIG等管理式命令仍旧是足以行使的,所以大家依旧不应有将服务器暴光给互连网恐怕另外不可靠赖网络。但是,使用redis.conf中的命令改名选项,大家可以通过禁止实施某个命令来进步只读从服务器的安全性。
    你可能会认为感叹,既然从服务器上的写多少会被重同步数据覆盖,也说不定在从服务注重启时错失,那么为何要让叁个从服务器变得可写呢?原因是,一些不重要的临时数据,依旧是足以保存在从服务器下面的。举例说,客户端能够在从服务器上保存主服务器的可达性(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.8 最初, 从服务器会以每秒二遍的功用向主服务器报告复制流(replication stream)的拍卖速度。

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

    密码验证

    假设主服务器通过requirepass选项设置了密码,那么为了让从服务器的同步操作能够顺遂实行,大家也不能够不为从服务器实行相应的身份验证设置。
    对此叁个正值运维的服务器,能够动用客户端输入以下命令:

    config set masterauth <password>
    

    要长久地设置那一个密码,那么能够将它加入到布署文件中:

    masterauth <password>
    

    别的还应该有几个选择,它们和主服务器执行部分重同步时所利用的复制流缓冲区有关,详细的新闻能够参见 Redis 源码中附带的redis.conf示例文件。

    复制效用也不会阻塞从服务器: 只要在 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所需的至少配置如下所示:

    新葡亰496net 4新葡亰496net 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大切诺基D 和 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 2.8 开端,为了保险数据的安全性,能够因而陈设,让主服务器只在有至少 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 会最先三遍机关故障迁移操作, 它会将失效主服务器的内部一个从服务器晋级为新的主服务器, 并让失效主服务器的别的从服务器改为复制新的主服务器; 当客商端试图连接失效的主服务器时, 集群也会向客商端再次回到新主服务器的地方, 使得集群能够采纳新主服务器代替失效服务器。

    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 模式。

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

    • 1.从服务器以每秒二遍的频率 PING 主服务器叁次,并报告复制流的管理状态。
    • 2.主服务器会记录种种从服务器最终一次向它发送 PING 的小时。
    • 3.客户能够经过安顿,内定互连网延迟的最大值 min-slaves-max-lag ,以及实行写操作所需的足足从服务器数量 min-slaves-to-write 。
    • 4.假如至少有 min-slaves-to-write 个从服务器,並且那个服务器的延迟值都有限 min-slaves-max-lag 秒,那么主服务器就能奉行客商端乞求的写操作。
    • 5.您能够将那么些特点看作 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 集群标准

    私家介绍:

    高广超:多年细小互联网研究开发与架构划虚构计经验,专长设计与出生高可用、高质量、可扩充的网络架构。

    正文首发在 高广超的简书博客 转发请阐明!

    新葡亰496net 6简书博客新葡亰496net 7头条号

    从Redis 持久化

    另二个周旋耗费时间的操作是长久化,为了抓实质量,能够透过复制效用建设构造三个(或若干个)从数据库,并在从数据库中启用长久化,同有时候在主数据库禁止使用长久化。当从数据库崩溃时重启后主数据库会自行将数据同步过来所以不要思量数据错过。而当主数据库崩溃时,必要在从数据库中接纳SLAVEOF NO ONE一声令下将从数据库提高成主数据库继续服务,并在本来的主数据库运转后选取SLAVEOF命令将其设置成新的主数据库的从数据库,就可以将数据同步回来。

    Redis的小编Salvatore Sanfilippo曾经见报过Redis宣言①,在那之中涉嫌Redis以轻易为美。一样在平安范围Redis也从未做太多的行事。

    复制功用能够独自地用来数据冗余(data redundancy), 也足以透过让七个从服务器处理只读命令诉求来提高扩充性(scalability): 举个例子说, 繁重的 SORT 命令能够提交附属节点去运营。

    三、Redis集群

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

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

    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号哈希槽。
    

    复制功用的周转规律
    任由初次连接仍然再一次连接, 当建设构造贰个从服务器时, 从服务器都将向主服务器发送三个 SYNC 命令。

    Redis Cluster

    新葡亰496net 8

    吸收接纳 SYNC 命令的主服务器将初步推行 BGSAVE , 并在保存操作实行时期, 将兼具新施行的写入命令都封存到一个缓冲区里面。

    集群组件安装

    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/
    

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

    布局文件中隐含

    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 命令左券的格式, 将写命令缓冲区中积攒的有所内容都发送给从服务器。

    开创应用

    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
    

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

    创造集群

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

    不怕有多少个从服务器同有时间向主服务器发送 SYNC , 主服务器也只需实行一回BGSAVE 命令, 就能够拍卖全部那一个从服务器的联合签名哀告。

    集群顾客端

    redis-cli -c -p 7000
    set foo bar
    get foo
    
    重新分片
    ./redis-trib.rb reshard 127.0.0.1:7000
    

    从服务器能够在主导服务器之间的连接断开时展开活动重连, 在 Redis 2.8 版本在此以前, 断线之后重连的从服务器总要施行叁次完整重同步(full resynchronization)操作, 可是从 Redis 2.8 版本早先, 从服务器可以依据主服务器的景观来抉择试行总体重同步照旧有的重同步(partial resynchronization)。

    集群管理

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

    一部分重同步
    从 Redis 2.8 开端, 在互联网连接短暂性失效之后, 主从服务器能够品尝继续施行原有的复制进度(process), 而不料定要实行总体重同步操作。

    气象表达

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

     

    那特个性要求主服务器为被发送的复制流创制一个内部存款和储蓄器缓冲区(in-memory backlog), 而且主服务器和持有从服务器之间都记录三个复制偏移量(replication offset)和三个主服务器 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 命令来打开或关闭这一个形式。

    只读从服务器会拒绝实施任何写命令, 所以不会出现因为操作失误而将数据一点都不小心写入到了从服务器的意况。

    新葡亰496net,就算从服务器是只读的, DEBUG 和 CONFIG 等管理式命令依旧是能够运用的, 所以大家依然不该将服务器揭示给互连网可能其余离谱网络。 不过, 使用 redis.conf 中的命令改名选项, 大家得以由此禁止施行某个命令来升高只读从服务器的安全性。

    您或然会感到惊愕, 既然从服务器上的写多少会被重同步数据覆盖, 也大概在从服务注重启时丢失, 那么为什么要让贰个从服务器变得可写呢?

    缘由是, 一些不重要的临时数据, 照旧是可以保存在从服务器上面包车型客车。 比方说, 客商端能够在从服务器上保存主服务器的可达性(reachability)音信, 进而完结故障转移(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安装及简单测验 http://www.linuxidc.com/Linux/2014-05/101544.htm

    Redis集群明细文书档案 http://www.linuxidc.com/Linux/2013-09/90118.htm

    Ubuntu 12.10下安装Redis(图文详解) Jedis连接Redis http://www.linuxidc.com/Linux/2013-06/85816.htm

    Redis体系-安装配置维护篇 http://www.linuxidc.com/Linux/2012-12/75627.htm

    CentOS 6.3安装Redis http://www.linuxidc.com/Linux/2012-12/75314.htm

    Redis安装配置学习笔记 http://www.linuxidc.com/Linux/2014-07/104306.htm

    Redis配置文件redis.conf 详解 http://www.linuxidc.com/Linux/2013-11/92524.htm

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

    正文长久更新链接地址:http://www.linuxidc.com/Linux/2014-10/108198.htm

    新葡亰496net 9

    本文由新葡亰496net发布于电脑系统,转载请注明出处:Redis焦点概念,Redis高可用及分片集群

    关键词: