精华内容
下载资源
问答
  • 目录1、什么是哨兵机制2、哨兵模式修改配置3、什么是Redis持久化4、RDB持久化5、AOF持久化6、AOF与ROB区别1、什么是哨兵机制Redis的哨兵(sentinel)系统用于管理多个Redis服务器,该系统执行以下三个任务:1.1、监控...

    目录

    1、什么是哨兵机制

    2、哨兵模式修改配置

    3、什么是Redis持久化

    4、RDB持久化

    5、AOF持久化

    6、AOF与ROB区别

    1、什么是哨兵机制

    Redis的哨兵(sentinel)系统用于管理多个Redis服务器,该系统执行以下三个任务:

    1.1、监控(Monitoring):哨兵(sentinel)会不断地检查你的Master和Slave是否运作正常

    1.2、提醒(Notification):当被监控的某个Redis出现问题时,哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

    1.3、转载自动故障迁移(Automatic failover):当一个Master不能正常工作时,哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

    1.4、哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用留言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master.

    每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).

    若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置.

    虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器,你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel).

    2、哨兵模式修改配置

    实现步骤:》

    1.拷贝到etc目录

    cp sentinel.conf  /usr/local/redis/etc

    2.修改sentinel.conf配置文件

    sentinel monitor mymast  192.168.110.133 6379 1  #主节点 名称 IP 端口号 选举次数

    sentinel auth-pass mymaster 123456

    3. 修改心跳检测 5000毫秒

    sentinel down-after-milliseconds mymaster 5000

    4.sentinel parallel-syncs mymaster 2 --- 做多多少合格节点

    5. 启动哨兵模式

    ./redis-server /usr/local/redis/etc/sentinel.conf --sentinel &

    6. 停止哨兵模式

    3、什么是Redis持久化

    什么是Redis持久化,就是将内存数据保存到硬盘。

    Redis 持久化存储 (AOF 与 RDB 两种模式)

    4、RDB持久化

    RDB 是以二进制文件,是在某个时间 点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据恢复。

    优点:使用单独子进程来进行持久化,主进程不会进行任何 IO 操作,保证了 redis 的高性能

    缺点:RDB 是间隔一段时间进行持久化,如果持久化之间 redis 发生故障,会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

    这里说的这个执行数据写入到临时文件的时间点是可以通过配置来自己确定的,通过配置redis 在 n 秒内如果超过 m 个 key 被修改这执行一次 RDB 操作。这个操作就类似于在这个时间点来保存一次 Redis 的所有数据,一次快照数据。所有这个持久化方法也通常叫做 snapshots。

    RDB 默认开启,redis.conf 中的具体配置参数如下;

    #dbfilename:持久化数据存储在本地的文件

    dbfilename dump.rdb

    #dir:持久化数据存储在本地的路径,如果是在/redis/redis-3.0.6/src下启动的redis-cli,则数据会存储在当前src目录下

    dir ./

    ##snapshot触发的时机,save

    ##如下为900秒后,至少有一个变更操作,才会snapshot

    ##对于此值的设置,需要谨慎,评估系统的变更操作密集程度

    ##可以通过“save “””来关闭snapshot功能

    #save时间,以下分别表示更改了1个key时间隔900s进行持久化存储;更改了10个key300s进行存储;更改10000个key60s进行存储。

    save 900 1

    save 300 10

    save 60 10000

    ##当snapshot时出现错误无法继续时,是否阻塞客户端“变更操作”,“错误”可能因为磁盘已满/磁盘故障/OS级别异常等

    stop-writes-on-bgsave-error yes

    ##是否启用rdb文件压缩,默认为“yes”,压缩往往意味着“额外的cpu消耗”,同时也意味这较小的文件尺寸以及较短的网络传输时间

    rdbcompression yes

    5、AOF持久化

    Append-only file,将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部,在 append 操作返回后(已经写入到文件或者即将写入),才进行实际的数据变更,“日志文件”保存了历史所有的操作过程;当 server 需要数据恢复时,可以直接 replay 此日志文件,即可还原所有的操作过程。AOF 相对可靠,它和 mysql 中 bin.log、apache.log、zookeeper 中 txn-log 简直异曲同工。AOF 文件内容是字符串,非常容易阅读和解析。

    优点:可以保持更高的数据完整性,如果设置追加 file 的时间是 1s,如果 redis 发生故障,最多会丢失 1s 的数据;且如果日志写入不完整支持 redis-check-aof 来进行日志修复;AOF 文件没被 rewrite 之前(文件过大时会对命令进行合并重写),可以删除其中的某些命令(比如误操作的 flushall)。

    缺点:AOF 文件比 RDB 文件大,且恢复速度慢。

    我们可以简单的认为 AOF 就是日志文件,此文件只会记录“变更操作”(例如:set/del 等),如果 server 中持续的大量变更操作,将会导致 AOF 文件非常的庞大,意味着 server 失效后,数据恢复的过程将会很长;事实上,一条数据经过多次变更,将会产生多条 AOF 记录,其实只要保存当前的状态,历史的操作记录是可以抛弃的;因为 AOF 持久化模式还伴生了“AOF rewrite”。

    AOF 的特性决定了它相对比较安全,如果你期望数据更少的丢失,那么可以采用 AOF 模式。如果 AOF 文件正在被写入时突然 server 失效,有可能导致文件的最后一次记录是不完整,你可以通过手工或者程序的方式去检测并修正不完整的记录,以便通过 aof 文件恢复能够正常;同时需要提醒,如果你的 redis 持久化手段中有 aof,那么在 server 故障失效后再次启动前,需要检测 aof 文件的完整性。

    AOF 默认关闭,开启方法,修改配置文件 reds.conf:appendonly yes

    ##此选项为aof功能的开关,默认为“no”,可以通过“yes”来开启aof功能

    ##只有在“yes”下,aof重写/文件同步等特性才会生效

    appendonly yes

    ##指定aof文件名称

    appendfilename appendonly.aof

    ##指定aof操作中文件同步策略,有三个合法值:always everysec no,默认为everysec

    appendfsync everysec

    ##在aof-rewrite期间,appendfsync是否暂缓文件同步,"no"表示“不暂缓”,“yes”表示“暂缓”,默认为“no”

    no-appendfsync-on-rewrite no

    ##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite,默认“64mb”,建议“512mb”

    auto-aof-rewrite-min-size 64mb

    ##相对于“上一次”rewrite,本次rewrite触发时aof文件应该增长的百分比。

    ##每一次rewrite之后,redis都会记录下此时“新aof”文件的大小(例如A),那么当aof文件增长到A*(1 + p)之后

    ##触发下一次rewrite,每一次aof记录的添加,都会检测当前aof文件的尺寸。

    auto-aof-rewrite-percentage 100

    要注意的问题!

    AOF 是文件操作,对于变更操作比较密集的 server,那么必将造成磁盘 IO 的负荷加重;此外 linux 对文件操作采取了“延迟写入”手段,即并非每次 write 操作都会触发实际磁盘操作,而是进入了 buffer 中,当 buffer 数据达到阀值时触发实际写入(也有其他时机),这是 linux 对文件系统的优化,但是这却有可能带来隐患,如果 buffer 没有刷新到磁盘,此时物理机器失效(比如断电),那么有可能导致最后一条或者多条 aof 记录的丢失。通过上述配置文件,可以得知 redis 提供了 3 中 aof 记录同步选项:

    always:每一条 aof 记录都立即同步到文件,这是最安全的方式,也以为更多的磁盘操作和阻塞延迟,是 IO 开支较大。

    everysec:每秒同步一次,性能和安全都比较中庸的方式,也是 redis 推荐的方式。如果遇到物理服务器故障,有可能导致最近一秒内 aof 记录丢失(可能为部分丢失)。

    no:redis 并不直接调用文件同步,而是交给操作系统来处理,操作系统可以根据 buffer 填充情况 / 通道空闲时间等择机触发同步;这是一种普通的文件操作方式。性能较好,在物理服务器故障时,数据丢失量会因 OS 配置有关。

    其实,我们可以选择的太少,everysec 是最佳的选择。如果你非常在意每个数据都极其可靠,建议你选择一款“关系性数据库”吧。

    AOF 文件会不断增大,它的大小直接影响“故障恢复”的时间, 而且 AOF 文件中历史操作是可以丢弃的。AOF rewrite 操作就是“压缩”AOF 文件的过程,当然 redis 并没有采用“基于原 aof 文件”来重写的方式,而是采取了类似 snapshot 的方式:基于 copy-on-write,全量遍历内存中数据,然后逐个序列到 aof 文件中。因此 AOF rewrite 能够正确反应当前内存数据的状态,这正是我们所需要的;*rewrite 过程中,对于新的变更操作将仍然被写入到原 AOF 文件中,同时这些新的变更操作也会被 redis 收集起来(buffer,copy-on-write 方式下,最极端的可能是所有的 key 都在此期间被修改,将会耗费 2 倍内存),当内存数据被全部写入到新的 aof 文件之后,收集的新的变更操作也将会一并追加到新的 aof 文件中,此后将会重命名新的 aof 文件为 appendonly.aof, 此后所有的操作都将被写入新的 aof 文件。如果在 rewrite 过程中,出现故障,将不会影响原 AOF 文件的正常工作,只有当 rewrite 完成之后才会切换文件,因为 rewrite 过程是比较可靠的。*

    触发 rewrite 的时机可以通过配置文件来声明,同时 redis 中可以通过 bgrewriteaof 指令人工干预。

    redis-cli -h ip -p port bgrewriteaof

    因为 rewrite 操作 /aof 记录同步 /snapshot 都消耗磁盘 IO,redis 采取了“schedule”策略:无论是“人工干预”还是系统触发,snapshot 和 rewrite 需要逐个被执行。

    AOF rewrite 过程并不阻塞客户端请求。系统会开启一个子进程来完成。

    6、AOF与ROB区别

    AOF 和 RDB 各有优缺点,这是有它们各自的特点所决定:

    RDB

    RDB是在某个时间点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据恢复。

    优点:使用单独子进程来进行持久化,主进程不会进行任何IO操作,保证了redis的高性能

    缺点:RDB是间隔一段时间进行持久化,如果持久化之间redis发生故障,会发生数据丢失。所以这种方式更适合数据要求不严谨的时候

    AOF

    Append-only file,将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部,在append操作返回后(已经写入到文件或者即将写入),才进行实际的数据变更,“日志文件”保存了历史所有的操作过程;当server需要数据恢复时,可以直接replay此日志文件,即可还原所有的操作过程。AOF相对可靠,它和mysql中bin.log、apache.log、zookeeper中txn-log简直异曲同工。AOF文件内容是字符串,非常容易阅读和解析。

    优点:可以保持更高的数据完整性,如果设置追加file的时间是1s,如果redis发生故障,最多会丢失1s的数据;且如果日志写入不完整支持redis-check-aof来进行日志修复;AOF文件没被rewrite之前(文件过大时会对命令进行合并重写),可以删除其中的某些命令(比如误操作的flushall)。

    缺点:AOF文件比RDB文件大,且恢复速度慢。

    68f724bad5a33d9a9f6bd2ca7369ecb7.png

    展开全文
  • 3.哨兵机制​ 在《4.1 集群设计绕不开的话题》中我们提到了单点故障的问题,在《4.2 主从复制》中我们又提到了使用从库来做主库的备份,保证数据尽量不丢失。不过问题来了,如果主库挂掉了,我们如何知道呢?而且...

    3.哨兵机制

    ​ 在《4.1 集群设计绕不开的话题》中我们提到了单点故障的问题,在《4.2 主从复制》中我们又提到了使用从库来做主库的备份,保证数据尽量不丢失。不过问题来了,如果主库挂掉了,我们如何知道呢?而且每次主库挂掉我们都让运维人员来将从库手动改成主库吗?如果代码里已经将主库连接写死了,是不是还得把所有影响到的项目都重新发布呢?这样显然不合理,所以,就有了哨兵机制。

    ​ 哨兵机制(Redis Sentinel)有两个主要任务:

    监控:定时给被监控的Redis实例做心跳检测,看看是否在正常工作

    自动故障转移:当主Redis挂掉了,Sentinel会将从服务器升级为主服务器,并且给客户端提供新的主服务器地址。

    3.1 Sentinel 启动初始化

    ​ 当一个Sentinel启动时,它会执行以下步骤:

    初始化服务器

    这里的初始化服务器并不会像《3.1.2.1 Redis服务启动流程》中描述的那样完整的初始化Redis服务器,比如它不会载入RDB或AOF文件。

    将普通Redis服务器的代码替换成Sentinel代码

    Redis服务器启动的时候会载入命令表,而Sentinel启动载入的命令表和正常的不太一样,所以它只支持PING、SENTINEL、INFO、SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE和PUNSUBSCRIBE这七个命令。除了这个以外还有一些其他的代码替换。

    初始化Sentinel状态

    这里会初始化一个sentinelState结构体,如下:

    /* Main state. */

    struct sentinelState {

    char myid[CONFIG_RUN_ID_SIZE+1]; /* This sentinel ID. */

    uint64_t current_epoch; /* Current epoch. */

    dict *masters; /* Dictionary of master sentinelRedisInstances.

    Key is the instance name, value is the

    sentinelRedisInstance structure pointer. */

    int tilt; /* Are we in TILT mode? */

    int running_scripts; /* Number of scripts in execution right now. */

    mstime_t tilt_start_time; /* When TITL started. */

    mstime_t previous_time; /* Last time we ran the time handler. */

    list *scripts_queue; /* Queue of user scripts to execute. */

    char *announce_ip; /* IP addr that is gossiped to other sentinels if

    not NULL. */

    int announce_port; /* Port that is gossiped to other sentinels if

    non zero. */

    unsigned long simfailure_flags; /* Failures simulation. */

    int deny_scripts_reconfig; /* Allow SENTINEL SET ... to change script

    paths at runtime? */

    } sentinel;

    根据给定的配置文件,初始化Sentinel的监视主服务器列表

    上述sentinelState结构体中的masters字典记录了所有被Sentinel监视的主服务器相关信息。其中key是被监视主服务器的名字,value是Redis服务器实例,用sentinelRedisInstance来保存信息,如下:

    typedef struct sentinelRedisInstance {

    int flags; /* See SRI_... defines */

    char *name; /* Master name from the point of view of this sentinel. */

    char *runid; /* Run ID of this instance, or unique ID if is a Sentinel.*/

    uint64_t config_epoch; /* Configuration epoch. */

    sentinelAddr *addr; /* Master host. */

    instanceLink *link; /* Link to the instance, may be shared for Sentinels. */

    mstime_t last_pub_time; /* Last time we sent hello via Pub/Sub. */

    mstime_t last_hello_time; /* Only used if SRI_SENTINEL is set. Last time

    we received a hello from this Sentinel

    via Pub/Sub. */

    mstime_t last_master_down_reply_time; /* Time of last reply to

    SENTINEL is-master-down command. */

    mstime_t s_down_since_time; /* Subjectively down since time. */

    mstime_t o_down_since_time; /* Objectively down since time. */

    mstime_t down_after_period; /* Consider it down after that period. */

    mstime_t info_refresh; /* Time at which we received INFO output from it. */

    dict *renamed_commands; /* Commands renamed in this instance:

    Sentinel will use the alternative commands

    mapped on this table to send things like

    SLAVEOF, CONFING, INFO, ... */

    /* Role and the first time we observed it.

    * This is useful in order to delay replacing what the instance reports

    * with our own configuration. We need to always wait some time in order

    * to give a chance to the leader to report the new configuration before

    * we do silly things. */

    int role_reported;

    mstime_t role_reported_time;

    mstime_t slave_conf_change_time; /* Last time slave master addr changed. */

    /* Master specific. */

    dict *sentinels; /* Other sentinels monitoring the same master. */

    dict *slaves; /* Slaves for this master instance. */

    unsigned int quorum;/* Number of sentinels that need to agree on failure. */

    int parallel_syncs; /* How many slaves to reconfigure at same time. */

    char *auth_pass; /* Password to use for AUTH against master & replica. */

    char *auth_user; /* Username for ACLs AUTH against master & replica. */

    /* Slave specific. */

    mstime_t master_link_down_time; /* Slave replication link down time. */

    int slave_priority; /* Slave priority according to its INFO output. */

    mstime_t slave_reconf_sent_time; /* Time at which we sent SLAVE OF */

    struct sentinelRedisInstance *master; /* Master instance if it's slave. */

    char *slave_master_host; /* Master host as reported by INFO */

    int slave_master_port; /* Master port as reported by INFO */

    int slave_master_link_status; /* Master link status as reported by INFO */

    unsigned long long slave_repl_offset; /* Slave replication offset. */

    /* Failover */

    char *leader; /* If this is a master instance, this is the runid of

    the Sentinel that should perform the failover. If

    this is a Sentinel, this is the runid of the Sentinel

    that this Sentinel voted as leader. */

    uint64_t leader_epoch; /* Epoch of the 'leader' field. */

    uint64_t failover_epoch; /* Epoch of the currently started failover. */

    int failover_state; /* See SENTINEL_FAILOVER_STATE_* defines. */

    mstime_t failover_state_change_time;

    mstime_t failover_start_time; /* Last failover attempt start time. */

    mstime_t failover_timeout; /* Max time to refresh failover state. */

    mstime_t failover_delay_logged; /* For what failover_start_time value we

    logged the failover delay. */

    struct sentinelRedisInstance *promoted_slave; /* Promoted slave instance. */

    /* Scripts executed to notify admin or reconfigure clients: when they

    * are set to NULL no script is executed. */

    char *notification_script;

    char *client_reconfig_script;

    sds info; /* cached INFO output */

    } sentinelRedisInstance;

    创建连向主服务器的网络连接

    Sentinel会和被监视的主服务器创建两个异步网络连接,一个是用来向Redis服务器发送命令和接收命令用的,另一个是用来订阅_sentinel_:hello频道用的。

    3.2 监视流程

    ​ Sentinel默认以十秒一次的频率给主服务器发送INFO命令,并通过分析INFO命令来获取主服务器的当前信息。这里除了获得主服务器信息以外,还会取到从服务器的一些信息,并且Sentinel会给每个从服务器构建一个sentinelRedisInstance结构体来保存从服务器信息。

    ​ 当每次有新的从服务器被加入进来,Sentinel还会构建和从服务器的命令连接和订阅连接,并且也是十秒一次向从服务器发送INFO命令。

    ​ 除了发送INFO命令以外,Sentinel还会以两秒一次的频率向所有被监视的服务器发送PUBLISH命令,这样就能保证所有订阅了这个服务器的Sentinel都接收到相关的信息,除此之外,Sentinel还可以互相知晓彼此的存在。sentinelRedisInstance结构体中的sentinels字典就是用来保存其他Sentinel的地方。每个Sentinel还会互相建立命令连接来相互交换信息,不过Sentinel不会互相建立订阅连接。

    ​ Sentinel会以每秒一次,向所有建立了命令连接的机器发送PING命令,如果有机器在down-after-milliseconds时间范围内未响应的话,这个机器会被Sentinel标记成主观下线(Sentinel自己认为这个服务器不可用了)。当有机器被Sentinel认为主观下线之后,Sentinel会询问其他监视这个机器的Sentinel,如果返回的信息表示这个机器确实不能提供服务了,这时,所有Sentinel会将其标记为客观下线。被标记成下线并不意味着不被Sentinel监视了,Sentinel会定时监听这个机器,如果他又可以PING通了,Sentinel还是会重新将其标记为在线状态。如果是master节点不可用,那么当新的master被选出来之后,老的master就会被当做新master的从服务器。

    ​ master节点不可用的情况下,Sentinel会做一次故障转移。但是毕竟一台服务器可能有多个master,不可能所有Sentinel都做故障转移,所以在做故障转移之前,Sentinel会选举出一个领头的Sentinel来做这件事情,选举的规则就是每个Sentinel都向其他Sentinel发送一个SENTINEL is-master-down-by-addr命令,如果其他Sentinel有半数都通过了某个Sentinel,那么就由这个有个Sentinel作为领头有个Sentinel来执行故障转移(这里使用了raft算法)。

    ​ 故障转移的时候需要做两步,一是选举一个新的master,新master会在所有正常的从节点中选取一个偏移量最大的节点作为新master,这里可能会涉及到一部分的数据丢失,不过这不可避免(可参阅《4.1 集群设计绕不开的话题》)。二是其他从服务器SLAVEOF这个新的master。

    思考:

    ​ 常规我们都是配置三台Sentinel来处理,如果Sentinel有一台挂了,刚好master服务器也挂了。Sentinel机制需要选举一台领头Sentinel处理故障转移,但是两台Sentinel会出现脑裂情况,所以这个时候Redis服务就不可用了。

    展开全文
  • 今天我们就来看看redis sentinel即哨兵机制的相关底层原理以及我们在生产中需要避的坑。什么是redis sentinel哨兵在redis集群架构中是一个非常重要的组件,其主要功能有下面这些:集群监控,...

    前面我们基于实际案例搭建了缓存高可用方案(分布式缓存高可用方案,我们都是这么干的)同时提到了redis主从架构下是如何保证高可用的,讲到了它是通过redis sentinel的机制来实现的。

    c4073111843b406091454297df4a900f.png

    今天我们就来看看redis sentinel即哨兵机制的相关底层原理以及我们在生产中需要避的坑。

    什么是redis sentinel

    哨兵在redis集群架构中是一个非常重要的组件,其主要功能有下面这些:

    集群监控,即时刻监控着redis的master和slave进程是否是在正常工作。

    消息通知,就是说当它发现有redis实例有故障的话,就会发送消息给管理员

    故障自动转移,如果redis master 节点宕机了的话,它就会将请求转到slave 节点上,slave升为master。

    充当配置中心,如果发生了故障转移,它会通知将master的新地址写在配置中心告诉客户端。

    sentinel 本身也是分布式部署的,是一个集群去运行的并且节点间相互协调工作,那它是怎么来监控redis的呢?

    (1),当发生故障转移的时候,只有大部分哨兵节点同意才会判断你这个master是真的宕机了,这里会涉及到前面讲到的分布式选主,如果忘记了自行看下(面试是不是经常被问到分布式系统核心问题,这一次没人难倒你)(2),如果哨兵部分节点挂了的话,整个哨兵集群依然能工作,这也是确保自身能高可用。

    需要知道的哨兵核心点

    哨兵集群至少要 3 个节点,来确保自己的健壮性。

    redis主从 + sentinel的架构,是不会保证数据的零丢失的,它是为了保证redis集群的高可用。

    在部署redis主从 + sentinel 架构之前,我们要在测试环境多测试,尽量模拟线上环境。

    你可能会问,哨兵集群 2 个节点难道就不行吗?好,如果咱们的哨兵集群只部署了两个节点,那么 quorum=1,

    a9e70b20ba4638e1d76ffc72baaabdbb.png

    如上图,如果master宕机,sentinel 1 和 sentinel 2 只要有一个认为master宕机就会进行切换,同时sentinel 1 和sentinel 2 就会选出一个sentinel来进行故障转移,这个时候就需要用到majority,即大多数哨兵都是运行的,2个哨兵的majority是2(3个的majority=2,4个的majority=2,5个的majority=3),也就是说现在这两个哨兵节点都是正常运行的就可以进行故障转移。

    但是,现在master和sentinel1运行的整个机器如果宕机了的话,那么哨兵就只有一个了,此时就无法来通过majority来进行故障转移了,所以,我们至少需要三台哨兵实例。

    3 节点sentinel架构

    52bc1ec572d3c61fad19dcd45fc6580e.png

    如上图所示,

    假设master所在的机器不可用的话,那么哨兵还剩2个,sentinel 2 和sentinel3 就会认为master宕机,然后选举一个来处理故障转移

    三个哨兵节点的majority为2,现在还有2个哨兵在工作着,就可以允许执行故障转移。

    上面我们已经知道了哨兵的核心机制以及它和redis主从架构是如何配合使用来达到redis的高可用的,下面我们就来看看redis哨兵主备切换的数据丢失问题。

    1,主从异步复制导致的数据丢失

    redis master 和slave 数据复制是异步的,像前面说的MySQL差不多(数据库读写分离方案,实现高性能数据库集群),这样就有可能会出现部分数据还没有复制到slave中,master就挂掉了,那么这部分的数据就会丢失了。

    7a70f1bc2062741c26c658253f207ec4.png

    2,脑裂导致的数据丢失

    脑裂其实就是网络分区导致的现象,比如,我们的master机器网络突然不正常了发生了网络分区,和其他的slave机器不能正常通信了,其实master并没有挂还活着好好的呢,但是哨兵可不是吃闲饭的啊,它会认为master挂掉了啊,那么问题来了,client可能还在继续写master的呀,还没来得及更新到新的master呢,那这部分数据就会丢失。

    5d7a7e6fac5188132c6f344192108d92.png

    上面的两个数据丢失的问题,那我们该怎么去解决呢?其实也很简单,只需要在配置中加两个配置就行了,如下:

    min-slaves-to-write 1 # 要求至少一个slave

    min-slaves-max-lag 10 # 数据复制和同步的延迟不能超过10s

    我们不能只是去解决问题,我们要知道为什么这么做就可以解决问题,下面我们就来分析下,加上了这两个配置是怎么解决我们数据丢失问题的。

    核心思想就是,一旦所有的slave节点,在数据复制和同步时延迟了超过10秒的话,那么master它就不会再接客户端的请求了,这样就会有效减少大量数据丢失的发生。

    如何减少异步复制数据的丢失

    现在当我们的slave在数据复制的时候,发现返回的ACK时延太长达到了 min-slaves-max-lag 配置,这个时候就会认为如果master宕机就会导致大量数据丢失,所以就提前进行了预测,就不再去接收客户端的任何请求了,来将丢失的数据降低在可控范围内。

    d39a63f4ec56900278cfc3af4e55f832.png

    减少脑裂数据的丢失

    如果master出现了脑裂,和其他的slave失去了通信,不能继续给指定数量的slave发送数据。

    slave超过10秒没有给自己返回ack消息。

    master就会拒绝客户端的写请求

    redis 哨兵底层核心原理深度解析

    上面我们了解到了redis 哨兵的基本知识也解决了数据丢失的问题,那接下来我们来看看哨兵的几个核心底层原理,帮助大家在探讨这类问题的时候,也有话可说,也更不怕面试官问到哨兵机制。

    1,sdown和odown转换机制

    sdown,即主观宕机,如果一个哨兵它自己觉得master宕机了,就是主观宕机

    odown,即客观宕机,如果quorum数量的哨兵都认为一个master宕机了,则为客观宕机

    哨兵在ping一个master的时候,如果超过了is-master-down-after-milliseconds指定的毫秒数之后,就是达到了sdown,就主观认为master宕机了。

    如果一个哨兵在指定时间内,收到了quorum指定数量的其他哨兵也认为那个master是sdown了,那么就认为是odown了,客观认为master宕机,就完成了sdown到odown的转换。

    2,哨兵集群如何实现自动发现

    通过redis的pub/sub系统实现的,每个哨兵都会往__sentinel__:hello这个channel里发送一个消息。

    其他哨兵可以消费到这个消息,且可以感知到其他哨兵的存在。

    每隔两秒钟,每个哨兵都会向自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息(包括自己的host、ip和runid还有对这个master的监控配置)。

    每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel,然后去感知到同样在监听这个master+slaves的其他哨兵的存在。

    每个哨兵还会跟其他哨兵交换对master的监控配置,互相进行监控配置的同步。

    3,slave配置如何自动纠正

    slave配置的自动纠正,是由哨兵来负责的。例如,slave如果要成为潜在的master候选人,哨兵会确保slave复制现有的master数据;如果slave连接的是一个有问题的master,在故障转移之后,哨兵会确保slave能连上新的没问题的master上。

    4,slave 到master 选举算法

    如果一个master被认为odown了,而且majority哨兵都允许了主备切换,那么某个哨兵就会执行主备切换操作,此时首先要选举一个slave来,主要通过下面几个步骤:需要考虑slave的下面一些信息

    跟master断开连接的时长

    slave优先级

    复制offset

    run id

    如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍,再加上加master宕机的时长,那么slave就被认为不适合选举为master。

    (down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

    接下来会对slave进行排序

    按照slave优先级进行排序,slave priority越低,优先级就越高。

    如果slave priority相同,那么看replica offset,哪个slave复制了越多的数据,offset越靠后,优先级就越高。

    如果上面两个条件都相同,那么选择一个run id比较小的那个slave

    5,quorum和majority 关系

    每次一个哨兵要做主备切换的时候,首先需要quorum数量的哨兵认为odown,然后选举出一个哨兵来做切换,这个哨兵还得得到majority哨兵的授权,才能正式执行切换。

    如果quorum < majority,比如5个哨兵,majority就是3,quorum设置为2,那么就3个哨兵授权就可以执行切换

    如果quorum >= majority,那么必须quorum数量的哨兵都授权,比如5个哨兵,quorum是5,那么必须5个哨兵都同意授权,才能执行切换。

    6、configuration epoch

    哨兵会对一套redis master+slave进行监控,有相应的监控的配置

    执行切换的那个哨兵,会从要切换到的新master(salve->master)那里得到一个configuration epoch,这就是一个version号,每次切换的version号都必须是唯一的。

    如果第一个选举出的哨兵切换失败了,那么其他哨兵,会等待failover-timeout时间,然后接替继续执行切换,此时会重新获取一个新的configuration epoch,作为新的version号

    7、configuraiton传播

    哨兵完成切换之后,会在自己本地更新生成最新的master配置,然后同步给其他的哨兵,就是通过之前说的pub/sub消息机制

    这里之前的version号就很重要了,因为各种消息都是通过一个channel去发布和监听的,所以一个哨兵完成一次新的切换之后,新的master配置是跟着新的version号的,其他的哨兵都是根据版本号的大小来更新自己的master配置的。

    总结,今天我们学习了redis sentinel 机制的基本使用,同时在使用过程中对于可能出现的数据丢失进行相关避坑方案讲解,最后将哨兵的几个重要的底层知识进行了详细的讲解,希望帮助大家能更好的掌握redis的哨兵机制。

    展开全文
  • 3.3、运行机制 1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽. 2)节点的fail是通过集群中超过半数的master节点检测失效时才生效. 3)客户端与redis节点直连,不需要中间proxy层....

    一、Redis主从复制

    1.1、主从复制介绍

    1)使用异步复制。

    2)一个主服务器可以有多个从服务器。从服务器也可以有自己的从服务器。

    3)复制功能不会阻塞主服务器

    4)可以通过复制功能来让主服务器免于执行持久化操作,由从服务器去执行持久化操作即可。

    a98422b56d05bf7796f5242cbc03ea30.png

    1.2、数据安全

    当配置Redis复制功能时,强烈建议打开主服务器的持久化功能。否则的话,由于延迟等问题,部署的服务应该要避免自动拉起。为了帮助理解主服务器关闭持久化时自动拉起的危险性,参考一下以下会导致主从服务器数据全部丢失的例子:

    1. 假设节点A为主服务器,并且关闭了持久化。 并且节点B和节点C从节点A复制数据

    2. 节点A崩溃,然后由自动拉起服务重启了节点A. 由于节点A的持久化被关闭了,所以重启之后没有任何数据

    3. 节点B和节点C将从节点A复制数据,但是A的数据是空的, 于是就把自身保存的数据副本删除。

    4)在关闭主服务器上的持久化,并同时开启自动拉起进程的情况下,即便使用Sentinel来实现Redis的高可用性,也是非常危险的。 因为主服务器可能拉起得非常快,以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启,然后还是会执行上面的数据丢失的流程。

    无论何时,数据安全都是极其重要的,所以应该禁止主服务器关闭持久化的同时自动拉起。

    1.3、主从复制原理

    22402d9551ef518e8584772a4b8dc3d9.png

    原理说明:

    1. 副本库通过slaveof 10.0.0.51 6379命令,连接主库,并发送SYNC给主库

    2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库

    3. 副本库接收后会应用RDB快照

    4. 主库会陆续将中间产生的新的操作,保存并发送给副本库

    5. 到此,我们主复制集就正常工作了

    6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.

    7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.

    8. 如果发生主从临时断开。从库数据没有被破坏的情况下,在下次重连之后,,从库发送PSYNC给主库 (2.8版本之后)

    9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的

    其他说明:

    1)SYNC 命令执行示例

    84abca72aa5b465e6d3d5fa557d00e25.png

    2)命令传播

    在主从服务器完成同步之后,主服务器每执行一个写命令,它都会将被执行的写命令发送给从服务器执行,这个操作被称为“命令传播”(command propagate)。命令传播是一个持续的过程:只要复制仍在继续,命令传播就会一直进行,使得主从服务器的状态可以一直保持一致

    047b7ccf5fcc4fbfc51232c03ef853d9.png

    3)复制中的SYNC与PSYNC

    ①在 Redis 2.8 版本之前, 断线之后重连的从服务器总要执行一次完整重同步(full resynchronization)操作。

    ②从 Redis 2.8 开始,Redis 使用 PSYNC命令代替 SYNC 命令。PSYNC 比起 SYNC 的最大改进在于 PSYNC 实现了部分重同步(partial resync)特性:在主从服务器断线并且重新连接的时候,只要条件允许,PSYNC 可以让主服务器只向从服务器同步断线期间缺失的数据,而不用重新向从服务器同步整个数据库。

    SYNC 处理断线重连示例:

    bac6a1cd5205cae16a4592ee146a6c48.png

    PSYNC 处理断线重连示例:

    271dcd61e04b0223101fec478db431e3.png

    1.4、复制一致性

    1.4.1、问题引出

    7d7357702f6663285a2cf46ec9e03879.png

    1)在读写分离环境下,客户端向主服务器发送写命令 SET n 10086,主服务器在执行这个写命令之后,向客户端返回回复,并将这个写命令传播给从服务器。

    2)接到回复的客户端继续向从服务器发送读命令 GET n ,并且因为网络状态的原因,客户端的 GET命令比主服务器传播的 SET 命令更快到达了从服务器。

    3)因为从服务器键 n 的值还未被更新,所以客户端在从服务器读取到的将是一个错误(过期)的 n值。

    1.4.2、问题解决

    从 Redis 2.8 开始, 为了保证数据的安全性, 可以通过配置, 让主服务器只在有至少 N 个当前已连接从服务器的情况下, 才执行写命令。不过, 因为 Redis 使用异步复制, 所以主服务器发送的写数据并不一定会被从服务器接收到,因此, 数据丢失的可能性仍然是存在的。

    通过以下两个参数保证数据的安全:

    1.5、主从复制配置

    19f443ec959fba12ceaf57b91acac696.png

    1)环境准备

    准备两个或两个以上redis实例:主节点:6380  从节点:6381、6382

    2)配置文件

    3)启动

    4)开启主从

    6381/6382命令行上操作

    5)查询主从状态

    示例:

    1.6、主从切换

    1)模拟主库故障

    2)解除主从关系

    3)重新设置主从

    二、Redis Sentinel

    2.1、哨兵简介

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

    2.2、Sentinel 的构造

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

    f80d8498eb6cba4b5812b3d36bdd9aa6.png

    2.3、哨兵功能

    1)监控(Monitoring):Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

    2)提醒(Notification):当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

    3)自动故障迁移(Automatic failover):当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时,集群也会向客户端返回新主服务器的地址,使得集群可以使用新主服务器代替失效服务器。

    4)应用透明 ==>相当于mysql MHA vip功能

    ---------------------------------------------------------------------------------------------------------------------------------------------------

    1)发现并连接主服务器

    Sentinel 通过用户给定的配置文件来发现主服务器。Sentinel 会与被监视的主服务器创建两个网络连接:命令连接用于向主服务器发送命令。

    订阅连接用于订阅指定的频道,从而发现监视同一主服务器的其他 Sentinel

    86e0c1e5ebb158c8842ce0fab7a38190.png

    2)发现并连接从服务器

    Sentinel 通过向主服务器发送INFO 命令来自动获得所有从服务器的地址。跟主服务器一样,Sentinel 会与每个被发现的从服务器创建命令连接和订阅连接

    e45719ba972a9d6fa723d8d24bfa9bcb.png

    3)发现其他 Sentinel

    Sentinel 会通过命令连接向被监视的主从服务器发送 “HELLO” 信息,该消息包含 Sentinel 的 IP、端口号、ID 等内容,以此来向其他 Sentinel 宣告自己的存在。与此同时Sentinel 会通过订阅连接接收其他 Sentinel 的“HELLO” 信息,以此来发现监视同一个主服务器的其他 Sentinel 。sentinel1 通过发送HELLO 信息来让sentinel2 和 sentinel3发现自己,其他两个sentinel 也会进行类似的操作。

    77bcb90e271b9af494cef074dfc5d4bc.png

    4)多个Sentienl之间的链接

    Sentinel 之间只会互相创建命令连接,用于进行通信。因为已经有主从服务器作为发送和接收 HELLO 信息的中介,所以 Sentinel之间不会创建订阅连接。

    85958c16fee392c814cb298fb7d9d5ad.png

    5)检测实例的状态

    Sentinel 使用 PING 命令来检测实例的状态:如果实例在指定的时间内没有返回回复,或者返回错误的回复,那么该实例会被 Sentinel 判断为下线

    Redis 的 Sentinel 中关于下线(down)有两个不同的概念:

    ①主观下线(Subjectively Down, 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。

    ②客观下线(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 就会将这个服务器标记为主观下线。

    77b7257275c5c96e0c5aba61f99c88bd.png

    6)故障转移FAILOVER

    一次故障转移操作由以下步骤组成:

    ①发现主服务器已经进入客观下线状态。

    ②基于Raft leader election    协议 , 进行投票选举

    ③如果当选失败,那么在设定的故障迁移超时时间的两倍之后,重新尝试当选。 如果当选成功, 那么执行以下步骤。

    ④选出一个从服务器,并将它升级为主服务器。

    ⑤向被选中的从服务器发送 SLAVEOF NO ONE 命令,让它转变为主服务器。

    ⑥通过发布与订阅功能, 将更新后的配置传播给所有其他 Sentinel ,其他 Sentinel 对它们自己的配置进行更新。

    ⑦向已下线主服务器的从服务器发送 SLAVEOF 命令,让它们去复制新的主服务器。

    ⑧当所有从服务器都已经开始复制新的主服务器时, leader Sentinel 终止这次故障迁移操作。

    2.4、哨兵搭建过程

    1)创建哨兵目录

    2)哨兵配置文件

    d2ba9877d9387b6af84ef808d8f20304.png

    3)启动哨兵

    6deb7d97ea29a4bb2e36c8424608ef86.png

    如果有问题,可按如下方法解决:

    2.5、故障测试

    1)停主库

    7aee8ed9481f4e39d80d304e5f09e83a.png

    634d1634286f3590da9ae3ac31640661.png

    2)查看哨兵配置

    aabb6303b7cb99f30ca39a87e2c9e9e9.png

    3)重新启动宕机的实例

    bfcba6f7f83c1849273ab39286dbad9c.png

    2.6、哨兵管理命令

    三、Redis cluster

    3.1、cluster简介

    1)Redis 集群是一个可以在多个 Redis 节点之间进行数据共享的设施(installation)。

    2)Redis 集群不支持那些需要同时处理多个键的 Redis 命令, 因为执行这些命令需要在多个 Redis 节点之间移动数据, 并且在高负载的情况下, 这些命令将降低 Redis 集群的性能, 并导致不可预测的行为。

    3)Redis 集群通过分区(partition)来提供一定程度的可用性(availability): 即使集群中有一部分节点失效或者无法进行通讯,集群也可以继续处理命令请求。

    4)将数据自动切分(split)到多个节点的能力。当集群中的一部分节点失效或者无法进行通讯时, 仍然可以继续处理命令请求的能力。

    3.2、集群数据共享

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

    集群使用公式 CRC16(key) & 16384 计算键 key属于哪个槽

    e59b88e6847f0b137e4a25878a43c3e2.png

    5c3909bea7adf370e122aa56f8e43f57.png

    1)高性能

    1、在多分片节点中,将16384个槽位,均匀分布到多个分片节点中

    2、存数据时,将key做crc16(key),然后和16384进行取模,得出槽位值(0-16383之间)

    3、根据计算得出的槽位值,找到相对应的分片节点的主节点,存储到相应槽位上

    4、如果客户端当时连接的节点不是将来要存储的分片节点,分片集群会将客户端连接切换至真正存储节点进行数据存储

    2)高可用

    在搭建集群时,会为每一个分片的主节点,对应一个从节点,实现slaveof的功能,同时当主节点down,实现类似于sentinel的自动failover的功能。

    3.3、运行机制

    1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.

    2)节点的fail是通过集群中超过半数的master节点检测失效时才生效.

    3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

    4)把所有的物理节点映射到[0-16383]slot上,cluster 负责维护nodeslotkey

    3.4、集群的复制

    为了使得集群在一部分节点下线或者无法与集群的大多数(majority)节点进行通讯的情况下, 仍然可以正常运作, Redis 集群对节点使用了主从复制功能: 集群中的每个节点都有 1 个至 N 个复制品(replica), 其中一个复制品为主节点(master), 而其余的 N-1 个复制品为从节点(slave)。

    在之前列举的节点 A 、B 、C 的例子中, 如果节点 B 下线了, 那么集群将无法正常运行, 因为集群找不到节点来处理 5501 号至 11000 号的哈希槽。

    假如在创建集群的时候(或者至少在节点 B 下线之前), 我们为主节点 B 添加了从节点 B1 , 那么当主节点 B 下线的时候, 集群就会将 B1 设置为新的主节点, 并让它代替下线的主节点 B , 继续处理 5501 号至 11000 号的哈希槽, 这样集群就不会因为主节点 B 的下线而无法正常运作了。

    不过如果节点 B 和 B1 都下线的话, Redis 集群还是会停止运作。

    集群的复制特性重用了 SLAVEOF 命令的代码,所以集群节点的复制行为和 SLAVEOF 命令的复制行为完全相同。

    3.5、集群故障转移

    在集群里面,节点会对其他节点进行下线检测。当一个主节点下线时,集群里面的其他主节点负责对下线主节点进行故障移。换句话说,集群的节点集成了下线检测和故障转移等类似 Sentinel 的功能。因为 Sentinel 是一个独立运行的监控程序,而集群的下线检测和故障转移等功能是集成在节点里面的,它们的运行模式非常地不同,所以尽管这两者的功能很相似,但集群的实现没有重用 Sentinel 的代码。

    3.6、集群执行命令情况

    1)命令发送给正确的节点

    命令发送到了正确的节点:命令要处理的键所在的槽正好是由接收命令的节点负责,那么该节点执行命令,就像单机 Redis 服务器一样。键 date 位于 2022 槽,该槽由节点 7000 负责,命令会直接执行

    f56c77966f4fb6e171dc51e03dbbd91a.png

    2)命令发送给了错误的节点

    命令发送到了错误的节点:接收到命令的节点并非处理键所在槽的节点,那么节点将向客户端返回一个转向(redirection)错误,告知客户端应该到哪个节点去执行这个命令,客户端会根据错误提示的信息,重新向正确的节点发送命令。键 date 位于 2022 槽,该槽由节点 7000 负责,但错误发送到了7001节点

    dfd043662ee4d867a505052cac58cb61.png

    转向错误的实现:

    1)集群中的节点会互相告知对方,自己负责处理哪些槽

    d40b4c4df333e002900ea77b1ffe18a4.png

    2)集群中的每个节点都会记录 16384 个槽分别由哪个节点负责,从而形成一个“槽表”(slot table)。

    节点在接收到命令请求时,会通过槽表检查键所在的槽是否由本节点处理:如果是的话,那么节点直接执行命令;

    如果不是的话,那么节点就从槽表里面提取出正确节点的地址信息,然后返回转向错误。

    ae470e1022d64276520b525663eccb8e.png

    3.7、集群搭建过程

    1)环境准备

    6个redis实例,一般会放到3台硬件服务器

    注:在企业规划中,一个分片的两个分到不同的物理机,防止硬件主机宕机造成的整个分片数据丢失。

    端口号:7000-7005

    2)安装集群插件

    3)集群节点准备

    相关说明:

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

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

    4)启动节点

    5)将节点加入集群管理

    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

    #--replicas 1表示副本是一个(如果是2,至少要准备9个节点,一主两从)

    #前三个是主库,后三个是从库(需要保证对应的主库与从库在不同的节点上)

    6)查看节点信息

    关注点:

    3.8、集群节点管理

    3.8.1、增加新的节点

    1)创建新节点的目录及配置文件

    2)启动新节点

    3)添加主节点

    c9de349b11389fa85bcb275f00c4aa74.png

    4)转移slot(重新分片),从已有的节点上分配槽位给新添加的节点

    重新分片过程:

    分片完之后,再次查看节点的槽位变化:

    516c6c86429f1c0c99b190dc8658ce25.png

    5)添加从节点

    过程说明:

    3.8.2、删除节点

    1)查看当前槽位分配状态:

    2fced4ce5ecc3aa4337e8e69069aa383.png

    2)

    将之前获取的槽位分批归还

    查看最后归还结果:

    98bfbaf22cd801e71934bd04772ccd76.png

    3)删除主从节点(最好先删除从节点后删除主节点)

    注意:删除之后,删除节点的进程会自动关闭

    展开全文
  • 说到Redis不得不提哨兵模式,那么究竟哨兵是什么意思?为什么要使用哨兵呢?接下来一一为您讲解:1.为什么要用到哨兵哨兵(Sentinel)主要是为了解决在主从(master-slave)复制架构中出现宕机的情况,主要分为两种:1.1...
  • 针对这个情况,Sentinel 提供了对应的保护机制,让系统的入口流量和系统的负载达到一个平衡,保证系统在能力范围之内处理最多的请求。 6. 如何使用Sentinel Sentinel 可以简单的分为 Sentinel 核心库和 Dashboard。...
  • offset=169470,lag=1 以上实现了redis的sentinel机制 也就是 HA机制 其实对于现上环境的话,当redis发生了主从切换的时候,这个比如程序调用的ip就会改变,写两个ip和两个sentinel地址显然是不合理的,我们可以实现...
  • 一、redis的复制##redis2.8版本后的复制机制,是采用增量复制的##复制过程:同步(全量or增量)——命令传播1、同步流程:2、全量同步过程:3、增量同步过程:【哨兵机制】简介sentinel是redis高可用的解决方案,...
  • 1. 绪言在现实应用环境中,出于数据容量、容灾、性能等因素的考虑,往往不会只使用一台服务器,而是使用集群的方式。...本篇介绍redis的主从复制及哨兵机制。2. redis主从复制2.1 主从拓扑Redis 支持简单且易用的主...
  • redis如何实现高可用【主从复制、哨兵机制

    万次阅读 多人点赞 2018-09-05 21:07:27
    保证redis高可用机制需要redis主从复制、redis持久化机制、哨兵机制、keepalived等的支持。 主从复制的作用:数据备份、读写分离、分布式集群、实现高可用、宕机容错机制等。   redis主从复制原理 首先主从复制...
  • Mysql主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,Redis的主从结构可以采用一主多从或者级联结构,Redis主从复制可以根据是否是...
  • 同时避免一个redis服务宕机,导致应用宕机的情况,我们启用sentinel(哨兵)服务,实现主从切换的功能。https://www.cnblogs.com/jaycekon/p/6237562.html一,主从分离(读写分离,主从复制)首先我们默认已经安装了redis...
  • Redis主从以及哨兵集群搭建一、前言 Redis主从同步原理同MySQL的主从原理十分相似,而解决Redis单点故障的哨兵机制(sentinel)又同解决MySQL单点故障的MHA十分相似。因此我们在学习Redis时,可以将学习MySQL的知识...
  • │ 第十课MySQL8.0锁机制和事务.pdf │ 第十课MySQL机制和事务.pdf │ 第四课SQL基础语法.pdf │ ├─新版MySQL DBA综合实战班 第01天 │ 0_MySQL高级DBA公开课视频.avi │ 1_数据库通用知识介绍.avi │ 2_MySQL8...
  • 1 Redis为什么这么快完全基于内存,数据存储在内存中,类似HashMap,查找操作...底层模型和mysql不同,直接自己构建了VM机制。2 单线程可以通过在单机开多个Redis实例。3 解决单机瓶颈集群的部署方式也就是Redis clu...
  • 实现redis高可用机制的一些方法

    千次阅读 2018-09-30 10:29:13
    保证redis高可用机制需要redis主从复制、redis持久化机制、哨兵机制、keepalived等的支持。 主从复制的作用:数据备份、读写分离、分布式集群、实现高可用、宕机容错机制等。 redis主从复制原理 首先主从复制需要...
  • Redis主从复制,当用户往Master端写入数据时,通过Redis Sync机制将数据文件发送至Slave,Slave 也会执行相同的操作确保数据一致。同时slave上还可以开启二级slave、三级slave从库,和MySQL的主从类似。 Redis主从...
  • 小仙女讲Redis(3)——集群相关

    热门讨论 2019-08-16 21:27:18
    如果想保证系统的高可用,我们需要对mysql、redis等应用进行集群部署。这篇我们看看redis集群的使用。 主从复制 哨兵机制 集群的搭建与使用
  • Redis 面试简单介绍:首先它是一个处于缓存层的数据库:以键值对存储,基于内存(不是硬盘),所以速写快速;单线程运行,多路IO复用。...数据一致性:设置间隔时间更新删除数据,同时也可以使用事务机制操作redis...
  • java面试总结

    2019-04-22 13:45:16
    redis的哨兵机制 java父亲委托机制 数据库索引机制(为什么有索引会加快查询) springMVC的实现原理 mysql调优 HashMap实现原理 多线程之间怎么通讯 线程池可以设置哪些参数 jdk8的特性 怎么查看mysql索引 ...
  • JAVA高级面试题——2019

    万次阅读 多人点赞 2019-07-13 16:28:02
    HashMap是如何存储的?...Redis哨兵机制? RabbitMq如何做高可用? RabbitMq死信队列原理,应用场景? RabbitMq如何保证消费顺序? RabbitMq如何解决消息丢失?重复消费? Mybatis缓存怎么用? Mysql如何做高可...
  • 2、Nginx负载均衡实现高可用,Redis实现高可用(哨兵机制,主从复制)? 3、mq怎么实现数据去重、失败重发(rabbitmq、kafka)? 4、微服务系统之间如何通信和调用? 基于restful HTTP协议:使用RestTemplate调用、...
  • Docker实战之Redis-Cluster集群

    千次阅读 2020-03-01 19:15:50
    概述 接上一篇Docker实战之MySQL主从复制, 这里是Docker实战系列的第二篇,主要进行Redis-Cluster集群环境的快速搭建。Redis作为基于键值对的NoSQL数据库,具有高性能、丰富的数据结构...哨兵机制 Cluster Redis ...
  • 秒杀系统总结

    2020-08-04 22:35:08
    Redis 高可用 (集群,主从同步、读写分离,哨兵机制,开启持久化) Mysql高可用(集群、读写分离) 静态页面 消息队列(MQ,Redis等消息队列) 限流 降级 前端 : 按钮时间、链接等( 后端、秒杀次数 ...
  • 哨兵机制 Cluster Redis Cluster是Redis的分布式解决方案,在 3.0 版本正式推出。 集群方案的对比 1. 主从复制 同Mysql主从复制的原因一样,Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。...
  • 中间件笔记

    2021-04-16 17:29:44
    canal + kafka 实现mysql ACID靠什么保证数据库读写分离,解决主从延迟的方法对于类似亿级数据操作的场景,可以优先考虑分而治之redis 的 keys 和 scan 命令es 提升查询效率mysql limit 数字大时的优化Redis 哨兵和 ...

空空如也

空空如也

1 2 3
收藏数 48
精华内容 19
关键字:

mysql哨兵机制

mysql 订阅