FWQ
如何搭建Redis高可用架构?
如何搭建Redis高可用架构? 0浏览 收藏 从现在开始,我们要努力学习啦!今天我给大家带来《如何搭建Redis高可用架构?》,感兴趣的朋友请继续看下去吧!下文中的内容我们主要会涉及到等等知识点,如果在阅读本文过程中有遇到不清楚的地方,欢迎留言呀!我们一起讨论,一起学习! 持久化机制 在理解集群架构前,先要介绍一下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自动快照持久化数据外,还有两个命令可以帮助我们手动进行内存数据快照,这两个命令分别为save和bgsave。 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" # 持久化文件名 AOF提供了三种方式,可以让命令保存到磁盘。默认情况下,AOF采用appendfsync everysec的方式进行命令持久化。 appendfsync always #每次有新的改写命令时,都会追加到磁盘的aof文件中。数据安全性最高,但效率最慢。 appendfsync everysec # 每一秒,都会将改写命令追加到磁盘中的aof文件中。如果发生宕机,也只会丢失1秒的数据。 appendfsync no #不会主动进行命令落盘,而是由操作系统决定什么时候写入到磁盘。数据安全性不高。 开启AOF后需要重新启动redis服务,当再次执行相关改写命令时,aof文件中会记录操作的命令。 相对于RDB,虽然AOF的数据安全性更高,但是随着服务的持续运行,aof的文件也会越来越大,等到下次恢复数据时,速度会越来越慢。如果RDB和AOF都开启,在恢复数据时,redis会优先选择AOF,毕竟AOF丢失的数据更少啊。 RDB AOF 恢复效率…