启动6390的redis之后，没有主动加到原来的主从架构里面去，并且可以在6390实例中进行操作；该场景主要目的是测试提升从库需要怎么样进行操作，以及在从库被提升为主之后我们对旧的从库进行了相关的数据操作之后，是否能再次加入到原来的主从架构中。这种级联操作，并将中间的一个从库提升为主的场景，可能会使用在异地机房等不同环境的数据迁移的场景中。在整个过程中需要思路清晰，以及注意更改各个哨兵的配置信息；以及我们哨兵节点在后面的启动的时候最好监控哨兵日志，等我们后面启动的的哨兵被发现之后再启动其他哨兵。

RDB持久化可以在指定的时间间隔内生成数据集的时间点快照。AOF文件中的命令全部以Redis协议的格式来保存，新命令会被追加到文件的末尾。Redis还可以在后台对AOF文件进行重写，使得AOF文件的体积不会超出保存数据集状态所需的实际大小。Redis还可以同时使用AOF持久化和RDB持久化。在这种情况下，当Redis重启时，它会优先使用AOF文件来还原数据集，因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。RDB是一种表示某个即时点的Redis数据的紧凑文件。RDB最大化了Redis的性能，因为Redis父进程持久化时唯一需要做的是启动一个子进程，由子进程完成所有剩余工作。然而，你通常每隔5分钟或更久创建一个RDB快照，所以一旦Redis因为任何原因没有正确关闭而停止工作，你就得做好最近几分钟数据丢失的准备了。快照功能并不是非常耐久：如果Redis因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。

Redis的主从集群实操。沿用在上面单实例的的安装和部署过程，我们创建出来一个6379的单实例之后，对单实例进行主从搭建；slaveof下面添加一句。Thefilenamewheretodumpthe.redis6380.conf和redis6390.conf差异对比：。在主库查看inforeplication主从复制情况：。以上除了logfile、dir皆为默认配置

RedisCluster提供一种Redis安装方式：数据自动在多个Redis节点间分片。RedisCluster提供一定程度的高可用，在实际的环境中当某些节点失败或者不能通讯的情况下能够继续提供服务。每个Redis集群节点需要打开两个TCP连接。集群总线的作用：失败检测、配置升级、故障转移授权等。命令端口和总线端口之间总是相差10000。Redis集群不是使用一致性哈希，而是使用哈希槽。整个redis集群有16384个哈希槽，决定一个key应该分配到那个槽的算法是：计算该key的CRC16结果再模16834。如果真的需要，Redis集群支持同步复制的方式，通过WAIT指令来实现，这可以让丢失写操作的可能性降到很低。我们后面会部署一个Redis集群作为例子，在那之前，先介绍一下集群在redis.conf中的参数。clusternodetimeout:这是集群中的节点能够失联的最大时间，超过这个时间，该节点就会被认为故障。注意，任何一个节点在这个时间之内如果还是没有连上大部分的主节点，则此节点将停止接收任何请求。

对于主从集群模式，如果从库发生了故障，还有主库和其它的从库可以接收请求，但是如果主库挂了，就不能进行正常的数据写入，同时数据同步也不能正常的进行了，当然这种情况，我们需要想办法避免，于是就引入了下面的哨兵机制。sentinel：是Redis中集群的高可用方式，哨兵节点是特殊的Redis服务，不提供读写，主要来监控Redis中的实例节点，如果监控服务的主服务器下线了，会从所属的从服务器中重新选出一个主服务器，代替原来的主服务器提供服务。哨兵会通过PING命令检测它和从库，主库之间的连接情况，如果发现响应超时就会认为该服务已经下线了。当然这个数值在Redis中是可以配置的。sentinel的领导者从从机中选举出合适的丛机进行故障转移；1，应用端配置所有哨兵节点的信息，来连接我们的redis主从集群。

本文是集群的基础介绍，没有介绍复杂难懂的概念。如果你想深入了解集群原理请参考Redis集群规范。在旧版本，Redis2.8之前，如果发生了网络闪断，就会进行一次全量复制。replicationbuffer用于主节点与各个从节点间，数据的批量交互。如何主从断开了，当然对应的replicationbuffer也就没有了。在实际应用中，考虑到可能存在一些突发的请求压力，我们通常需要把这个缓冲空间扩大一倍，即replbacklogsize缓冲空间大小2，这也就是replbacklogsize的最终值。

单实例安装1，安装选择相关稳定版本：http://download.redis.io/releases/![image20220808112313636](/Users/a