标签：AOF 持久 redis ---- 集群 RDB 节点

一、resis的持久化

1、什么是持久化

----把内存中的数据持久化到磁盘。这个过程就是持久化。 当redis启动时会从磁盘上读取数据并加载到内存。

2、持久化的优点

----防止数据丢失，当redis宕机时能够完整的保存数据

3、redis持久化的方式

（1）RDB：以快照的方式进行持久化。 在一定时间间隔内进行快照。把数据进行保存到磁盘。

（2）AOF：会把每次对redis的写操作命令追加到一个日志尾，当redis启动时则把该日志中的命令执行一遍.

4、RDB的持久化方式

（1）RDB是由save命令和bgsave命令触发的，在配置文件中有默认是触发条件，如果有需要，可以手改修改。

（2）save和bgsave的区别

        ----在执行save命令期间，redis不能处理其他命令，直到RDB过程执行完为止，执行完成后如果存在旧的RDB文件，则会被新的替代．而redis可能会有大量的客户端发送命令，让几万甚至更多的命令在等待显然是不可取的。

        ----而ｂgsave在执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求，避免了redis其他命令等待的问题。

（３）rdb持久化方式的特点

优点：

     ----RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
     ----bgsave生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程       　不需要进行任何磁盘IO操作。
     -----RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

缺点：     

　  ----快照持久化期间修改的数据不会被保存，可能丢失数据。数据完整性比较差。

5、AOF的持久化方式

    （１） AOF是一种更加高效的方式，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。AOF默认不开启,需要配置手动开启。如下图

AOF的触发规则如下图：

开启appendonly后，当进行写操作时会把命令放入appendonly.aof文件中

（２）ＡＯＦ持久化方式的特点

优点：

        ----AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync          操作，最多丢失1秒钟的数据。
        ----AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
        ----AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写

缺点：

        ----对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大.
        ----恢复数据时时间要比快照模式慢很多。

6、redis的集群

        （１）搭建redis集群的原因：

        ----单个redis存在不稳定性。当redis服务宕机了，就没有可用的服务了。

        ----单个redis的读写能力是有限的。

        ----搭建集群，通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、

　　　高效的状态。

        （２）redis的主从关系

                创建一个主节点和多个从节点，主从节点的数据是同步的，主节点可以实现读和写

                操作，从节点只负责读操作。

        （３）搭建主从关系

                　准备三台机器 （1 主节点   2 从节点 ３从节点） 为了节省资源， 在一个虚拟机上启动　　　　　                    三台redis ，只是他们的端口号不同，

                　配从不配主

　　　　　 ----配置redis配置文件,修改三个redist的端口号， 6380(主)  6381（从）  6382（从）

　　　　　 ----修改rdb持久化文件的路径以及端口

        复制创建三个文件，如下图，分别为redis6380　6381　6382，　

分别启动80　81　82

启动成功后，连接不同的ｒｅｄｉｓ服务，端口号改变后连接ｒｅｄｉｓ命令如下

三台redis连接完毕，用info replication命令查看redis服务的关系

在没有三台redis设置之前可以看到他们之间是没有主从关系的，想要分别主从关系，需要进行如下的操作。

如上图，不改变6380，改变81和82，然后再查看三台redis的主从关系。可以发现81和82都变成了从，以80为主，80亦显示拥有两个从。

测试：

通过ｋｉｌｌ杀死主节点，然后查看从节点，发现从节点无法变成主节点

通过测试我们知道 主节点可以负责读写操作，但是从节点只能负责读操作。如果主节点宕机　，则从节点无法变成主节点，导致客户端无法进行写操作了，有很大的局限性。因此便有哨兵模式

（４）搭建哨兵模式

        ----因为从节点上备份了主节点的所有数据，那在主节点宕机的情况下，如果能够将从节点

             变成一个主节点，那么就可以解决整个集群没有可写的节点的缺点，这就是哨兵模式

        ----设置哨兵模式，修改sentinel.conf文件

修改后的哨兵文件，监视主节点6380，只要有一个哨兵认为主节点宕机了，就可以重新选择主节点。

启动哨兵，可以看到哨兵已经起到监视作用，显示6380为主节点，81、82为从节点。

杀死6380的redis进程，使主节点6380宕机

哨兵及时监视到主节点宕机了，随机选择6381为新的主节点。

通过查看，6381变成了主master，显示一个从节点，6382的主节点变成了6381。

重启之前的主节点6380，发现它并没有重新变为主节点，而是成了从节点。已6381为主

（５）redis集群搭建－－－去中心化

主从关系和哨兵模式虽然解决了部分问题，但是都没有解决并发量高的情况

配置三个主三个从

7001 7002      8001 8002       9001 9002

复制修改六个.conf文件

port 8001
bind 0.0.0.0
daemonize yes
appendonly yes  必须有aof持久化
# 开启集群
cluster-enabled yes             
# 集群的配置文件,该文件自动生成   
cluster-config-file nodes-8001.conf  
# 集群的超时时间
cluster-node-timeout 5000   

启动三主三从

  为上面这些redis分配主从关系以及槽。必须保证aof开启，保证redis中没有数据    

redis-cli --cluster create --cluster-replicas 1 192.168.125.3:7001 192.168.125.3:8001 192.168.125.3:9001   192.168.125.3:7002   192.168.125.3:8002 192.168.125.3:9002

客户端访问：

命令：redis-cli -c -h 127.0.0.1 -p 8001

标签：AOF,持久,redis,----,集群,RDB,节点
来源： https://blog.csdn.net/hzrxdh/article/details/118308206

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。