Redis高可用架构搭建到原理分析

本篇文章给大家带来了关于Redis的相关知识,其中主要介绍了关于高可用架构搭建到原理分析的相关内容,下面一起来看一下,希望对大家有帮助。

Redis高可用架构搭建到原理分析

由于近期公司在做系统优化,前段时间将大表进行分表后,现在又来搞redis了。关于redis,其中有一项要求就是将redis服务由阿里云迁移到公司自己的服务器中(由于公司性质原因)。刚好借着这次机会,重新回顾一下redis的高可用集群架构。redis集群方式有三种,分别为主从复制模式,哨兵模式以及Cluster集群模式,一般情况下哨兵和Cluster集群用的相对多一些,下面就来简单理解这三种模式。

持久化机制

在理解集群架构前,先要介绍一下redis的持久化机制,因为在后面的集群中会涉及到持久化。redis持久化是将缓存在内存中的数据根据一些规则进行落盘,以防止在redis服务宕机时可以进行数据恢复或者是集群架构中进行主从节点数据同步。redis持久化的方式有RDB和AOF两种,在4.0版本后新出了混合持久化模式。

RDB

RDB是redis默认开启的持久化机制,其持久化方式是按照用户配置的规则"X秒内至少发生过Y次改动",生成快照并落盘到dump.rdb二进制文件中。默认情况下,redis配置了三种,分别为900秒内至少发生过1次缓存key的改动,300秒内至少发生过10次缓存key的改动以及60秒内至少发生过10000次改动。

Redis高可用架构搭建到原理分析

除了redis自动快照持久化数据外,还有两个命令可以帮助我们手动进行内存数据快照,这两个命令分别为savebgsave

Redis高可用架构搭建到原理分析

  • save:以同步的方式进行数据快照,当缓存数据量大,会阻塞其他命令的执行,效率不高。

  • bgsave:以异步的方式进行数据快照,有redis主线程fork出一个子进程来进行数据快照,不会阻塞其他命令的执行,效率较高。由于是采用异步快照的方式,那么就有可能发生在快照的过程中,有其他命令对数据进行了修改。为了避免这个问题reids采用了写时复制(Cpoy-On-Write)的方式,因为此时进行快照的进程是由主线程fork出来的,所以享有主线程的资源,当快照过程中发生数据改动时,那么该数据会被复制一份并生成副本数据,子进程会将改副本数据写入到dump.rdb文件中。

RDB快照是以二进制的方式进行存储的,所以在数据恢复时,速度会比较快,但是它存在数据丢失的风险。假如设置的快照规则为60秒内至少发生100次数据改动,那么在50秒时,redis服务由于某种原因突然宕机了,那在这50秒内的所有数据将会丢失。

AOF

AOF是Redis的另一种持久化方式,与RDB不同时是,AOF记录着每一条更改数据的命令并保存到磁盘下的appendonly.aof文件中,当redis服务重启时,会加载该文将并再次执行文件中保存的命令,从而达到数据恢复的效果。默认情况下,AOF是关闭的,可以通过修改conf配置文件来进行开启。

 # appendonly no  关闭AOF持久化
 appendonly yes   # 开启AOF持久化
 # The name of the append only file (default: "appendonly.aof")
 appendfilename "appendonly.aof" # 持久化文件名复制代码
登录后复制

郑重声明:本文版权包含图片归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们(delete@yzlfxy.com)修改或删除,多谢。

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

留言与评论(共有 0 条评论)
昵称:
匿名发表
   
验证码: