redis笔记

 

redis的持久化机制

说白了，就是在指定的时间间隔内，将内存当中的数据集快照写入磁盘，它恢复时是将快照文件直接读到内存

什么意思呢？我们都知道，内存当中的数据，如果我们一断电，那么数据必然会丢失，但是玩过redis的同学应该都知道，我们一关机之后再启动的时候数据是还在的，所以它必然是在redis启动的时候重新去加载了持久化的文件

redis提供两种方式进行持久化，

RDB默认持久化，可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）

AOF（append only file）持久化，记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。

你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

1.RDB

RDB是一次的全量备份，即周期性的把redis当前内存中的全量数据写入到一个快照文件中。redis是单线程程序，这个线程要同时负责多个客户端的读写请求，还要负责周期性的把当前内存中的数据写到快照文件中RDB中，数据写到RDB文件是IO操作，IO操作会严重影响redis的性能，甚至在持久化的过程中，读写请求会阻塞，为了解决这些问题，redis需要同时进行读写请求和持久化操作，这样又会导致另外的问题，持久化的过程中，内存中的数据还在改变，假如redis正在进行持久化一个大的数据结构，在这个过程中客户端发送一个删除请求，把这个大的数据结构删掉了，这时候持久化的动作还没有完成，那么redis该怎么办呢？

redis使用操作系统的多进程COW机制(Copy On Write)机制来实现快照的持久化，在持久化过程中调用 glibc(Linux下的C函数库) 的函数fork()产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端的读写请求。子进程刚刚产生时，和父进程共享内存里面的代码段和数据段，这是Linux操作系统的机制，为了节约内存资源，所以尽可能让父子进程共享内存，这样在进程分离的一瞬间，内存的增长几乎没有明显变化。

子进程对当前内存中的数据进行持久化，并不会修改当前的数据结构，如果父进程收到了读写请求，那么会把处理的那一部分数据复制一份到内存，对复制后的数据进行修改，所以即使对某个数据进行了修改，redis持久化到RDB中的数据也是未修改的数据，这也是把RDB文件称为"快照"文件的原因，子进程所看到的数据在它被创建的一瞬间就固定下来了，父进程修改的某个数据只是该数据的复制品。子进程是先将数据写入到一个临时文件中，待持久化结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程不进行任何的io操作，这就确保了极高的性能。

实际上，内存中的全量数据由一个个的"数据段页面"组成，每个数据段页面的大小为4K，客户端要修改的数据在哪个页面中，就会复制一份这个页面到内存中，这个复制的过程称为"页面分离"，在持久化过程中，随着分离出的页面越来越多，内存就会持续增长，但是不会超过原内存的2倍，因为在一次持久化的过程中，几乎不会出现所有的页面都会分离的情况，读写请求针对的只是原数据中的小部分，大部分redis数据还是"冷数据"。

如果需要进行大规模的数据恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方法要比 AOF 方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失。

隐患：若当前的进程的数据量庞大，那么 fork 之后数据量*2,此时就会造成服务器压力大，运行性能降低

如何触发RDB快照

可以配置符合快照触发条件，默认的是 1 分钟内改动 1 万次，或者 5 分钟改动 10 次，或者是 15 分钟改动一次；

Save：save 时只管保存，其他不管，全部阻塞。

Bgsave：redis 会在后台进行快照操作，快照操作的同时还可以响应客户端的请求，可以通过 lastsave 命令获取最后一次成功执行快照的时间。

执行 fluhall 命令，也会产生 dump.rdb 文件，但里面是空的。

2.AOF

AOF日志存储的是redis服务器的顺序指令序列，即对内存中数据进行修改的指令记录。当redis收到客户端修改指令后，先进行参数校验，如果校验通过，先把该指令存储到AOF日志文件中，也就是先存到磁盘，然后再执行该修改指令。

当redis宕机后重启后，可以读取该AOF文件中的指令，进行数据恢复，恢复的过程就是把记录的指令再顺序执行一次，这样就可以恢复到宕机之前的状态。

redis在长期运行过程中，AOF日志会越来越大，如果redis服务重启后根据很大的AOF文件来顺序执行指令，将会非常耗时，导致redis服务长时间无法对外提供服务，所以需要对AOF文件进行"瘦身"。"瘦身"的过程称作AOF重写(rewrite)。

AOF Rewrite 的原理是，主进程fork一个子进程，对当前内存中的数据进行遍历，转换成一系列的redis操作指令，并序列化到一个新的AOF日志中，然后把序列化操作期间新收到的操作指令追加到新的AOF文件中，追加完毕后就立即替换旧的AOF文件，这样就完成了"瘦身"工作，即AOF Rewrite。

redis把操作指令追加到AOF文件这个过程，并不是直接写到AOF文件中，而是先写到操作系统的内存缓存中，这个内存缓存是由操作系统内核分配的，然后操作系统内核会异步地把内存缓存中的redis操作指令刷写到AOF文件中。

一个新问题是，假如内存缓存中的redis指令还没有来得及刷写到AOF文件中就宕机了，那么这部分未刷写的指令就会丢失，不过，glibc函数库提供了 fsync() 函数，该函数可以将指定文件的内容强制从内存缓存中刷写到磁盘上。fsync操作的周期对redis的性能有很大影响，如何配置将在本文后续的内容中给出建议。

 

4.redis4.0后混合持久化机制

开启混合持久化

4.0版本的混合持久化默认关闭的，通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，5.0之后默认开启。

重启redis时，我们很少使用RDB来恢复内存状态，因为会丢失大量数据。我们通常使用AOF日志重放，但是重放AOF日志性能相对RDB来说要慢很多，这样在redis实例很大的情况下，启动需要花费很长的时间。redis-4.0为了解决这个问题，带来了一个新的持久化选项——混合持久化。将RDB文件的内容和增量的AOF日志文件存在一起。这里的AOF日志不再是全量
的日志，而是自持久化开始到持久化结束的这段时间发生的增量AOF日志，通常这部分AOF日志很小。

混合持久化是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据。redis重启的时候，可以先加载RDB的内容，然后再重放增量AOF日志，就可以完全替代之前的AOF全量文件重放，恢复效率因此大幅得到提升。

redis 持久化机制对比

(1) RDB的优缺点

优点：

• RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去。
• 当进行RDB持久化时，对redis服务处理读写请求的影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。生成一次RDB文件的过程就是把当前时刻内存中的数据一次性写入文件中，而AOF则需要先把当前内存中的小量数据转换为操作指令，然后把指令写到内存缓存中，然后再刷写入磁盘。
• 相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis的数据会更加快速。AOF，存放的是指令日志，做数据恢复的时候，要回放和执行所有的指令日志，从而恢复内存中的所有数据。而RDB，就是一份数据文件，恢复的时候，直接加载到内存中即可。

缺点：

• 如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据。这个问题，也是RDB最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多。
• RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，甚至数秒。所以一般不要让生成RDB文件的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能会有影响。

(2) AOF的优缺点

优点：

• AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
• AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
• AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite的时候，会对其中的指令进行压缩，会创建出一份需要恢复数据的最小日志出来。
• AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。

缺点：

• 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
• AOF的写性能比RDB的写性能低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的，只不过比起RDB来说性能低，如果要保证一条数据都不丢，也是可以的，AOF的fsync设置成每写入一条数据，fsync一次，但是这样，redis的性能会大大下降。
• 基于AOF文件做恢复的速度不如基于RDB文件做恢复的速度。

(3) 混合持久化的优缺点

优点：结合了RDB和AOF的优点，使得数据恢复的效率大幅提升

缺点：兼容性不好，redis-4.x新增，虽然最终的文件也是.aof格式的文件，但在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差。

(4) 如何选择redis持久化机制

RDB和AOF到底该如何选择

• 不要仅仅使用RDB，因为那样会导致你丢失很多数据
• 也不要仅仅使用AOF，一是数据恢复慢，二是可靠性也不如RDB，毕竟RDB文件中存储的就是某一时刻实实在在的数据，而AOF只是操作指令，把数据转换为操作指令不一定是百分百没问题的。
• 综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。

(5) AOF和RDB同时工作

• redis在写RDB文件的时候不会执行AOF rewrite; redis在执行AOF rewrite的时候不会生成新的RDB;
• 如果redis正在生成新的RDB文件，此时用户执行bgrewriteaof命令手动重写AOF文件，那么等RDB快照生成之后，才会去执行AOF rewrite；
• 同时有RDB文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整。

性能建议（这里只针对单机版redis持久化做性能建议）：

因为RDB文件只用作后备用途，只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。 代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。 只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。 默认超过原大小100%大小时重写可以改到适当的数值。

---

redis集群专题

Redis主从复制

单机有什么问题：单机故障，容量瓶颈，qps瓶颈

主从复制：主节点负责写数据，从节点负责读数据，主节点定期把数据同步到从节点保证数据的一致性。达到了1.读写分离，2.容灾备份

主从复制的方式

• // 命令行使用
  slaveof ip port // 使用命令后自身数据会被清空，但取消slave只是停止复制，并不清空
  

  优点：无需重启。缺点：不便于管理

• // 配置文件中配置
  slaveof ip port
  slave-read-only yes //只允许从节点进行读操作

  优点：统一配置。缺点：需要重启

从节点建议用只读模式slave-read-only=yes, 若从节点修改数据，主从数据不一致

拓扑结构

a)一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响 

b)一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定

c)树状主从：一主多从的缺点（主节点推送次数多压力大）可用些方案解决，主节点只推送一次数据到从节点B，再由从节点B推送到C，减轻主节点推送的压力。

主从复制

全量复制

一般用于初次复制场景（第一次建立SLAVE后全量）或其它无法进行部分复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作，当数据量较大时，会对主从节点和网络造成很大的开销

全量复制过程

1. Redis内部会发出一个同步命令，刚开始是Psync命令，Psync ? -1表示要求master主机同步数据
2. 主机会向从机发送run_id和offset，因为slave并没有对应的 offset，所以是全量复制
3. 从机slave会保存主机master的基本信息
4. 主节点收到全量复制的命令后，执行bgsave（异步执行），在后台生成RDB文件（快照），并使用一个缓冲区（称为复制缓冲区）记录从现在开始执行的所有写命令
5. 主机发送RDB文件给从机
6. 发送缓冲区数据
7. 刷新旧的数据。从节点在载入主节点的数据之前要先将老数据清除
8. 加载RDB文件将数据库状态更新至主节点执行bgsave时的数据库状态和缓冲区数据的加载。

全量复制开销

• 主节点需要bgsave
• RDB文件网络传输占用网络io
• 从节点要清空数据
• 从节点加载RDB
• 全量复制会触发从节点AOF重写

部分复制

https://blog.csdn.net/u010013573/article/details/88288941

部分复制是Redis 2.8以后出现的，用于处理在主从复制中因网络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果条件允许，主节点会补发丢失数据给从节点。因为补发的数据远远小于全量数据，可以有效避免全量复制的过高开销，需要注意的是，如果网络中断时间过长，造成主节点没有能够完整地保存中断期间执行的写命令，则无法进行部分复制，仍使用全量复制

部分复制过程

1. 如果网络抖动（连接断开 connection lost）
2. 主机master 还是会写 repl_back_buffer（复制缓冲区）
3. 从机slave 会继续尝试连接主机
4. 从机slave 会把自己当前 run_id 和偏移量传输给主机 master，并且执行 pysnc 命令同步
5. 如果master发现你的偏移量是在缓冲区的范围内，就会返回 continue命令
6. 同步了offset的部分数据，所以部分复制的基础就是偏移量 offset。

服务器运行ID(run_id)：每个Redis节点(无论主从)，在启动时都会自动生成一个随机ID(每次启动都不一样)，由40个随机的十六进制字符组成；run_id用来唯一识别一个Redis节点。 通过info server命令，可以查看节点的run_id。

 

心跳

主从有长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率

 

缺点

1.由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

2.当主机宕机之后，将不能进行写操作，需要手动将从机升级为主机，从机需要重新制定master

redis哨兵模式

在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。

通俗来讲哨兵模式的出现是就是为了解决我们主从复制模式中需要我们人为操作的东西变为自动版，并且它比人为要更及时。当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。整个过程只需要一个哨兵节点来完成，首先使用Raft算法（选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知

监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。

自动故障转移（Automatic Failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。

配置提供者（Configuration Provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。

通知（Notification）：哨兵可以将故障转移的结果发送给客户端。

其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。

架构

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的Redis节点，不存储数据。

数据节点：主节点和从节点都是数据节点。

基本原理

关于哨兵的原理，关键是了解以下几个概念：

主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。

客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。

需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。

定时任务

每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：

1.每10秒通过向主从节点发送info命令获取最新的主从结构；发现slave节点，确定主从关系

2.每2秒通过发布订阅功能获取其他哨兵节点的信息；SUBSCRIBE c2 PUBLISH c2 hello-redis，交互对节点的“看法”和自身情况

3.每1秒通过向其他节点发送ping命令进行心跳检测，判断是否下线（monitor）。心跳检测，失败判断依据

领导者哨兵选举流程

a)每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
b)当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
c)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………

故障转移

选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：

a)由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了

 b) 当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移

c) 由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行

流程：

　　  1. 将slave-1脱离原从节点，升级主节点，

         2. 将从节点slave-2指向新的主节点

         3. 通知客户端主节点已更换

         4. 将原主节点（oldMaster）变成从节点，指向新的主节点

 d) 故障转移后的redis sentinel的拓扑结构图

 

在从节点中选择新的主节点：选择的原则是，

1.首先过滤掉不健康的从节点；

2.然后选择优先级最高的从节点（由replica-priority指定）；如果优先级无法区分，

3.则选择复制偏移量最大的从节点；如果仍无法区分，

4.则选择runid最小的从节点。

更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。

将已经下线的主节点（即6379）保持关注，当6379从新上线后设置为新的主节点的从节点

8.实践建议

哨兵节点的数量应不止一个。一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈；另一方面减少对下线的误判。此外，这些不同的哨兵节点应部署在不同的物理机上。

哨兵节点的数量应该是奇数，便于哨兵通过投票做出“决策”：领导者选举的决策、客观下线的决策等。

各个哨兵节点的配置应一致，包括硬件、参数等；此外应保证时间准确、一致。

 

9.总结

在主从复制的基础上，哨兵引入了主节点的自动故障转移，进一步提高了Redis的高可用性；但是哨兵的缺陷同样很明显：哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要我们对从节点做额外的监控、切换操作。此外，哨兵仍然没有解决写操作无法负载均衡、及存储能力受到单机限制的问题

 

---

redis cluster高可用集群

Redis有三种集群模式，分别是：

* 主从模式

* Sentinel模式

* Cluster模式

redis cluster集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特 性。Redis cluster集群不需要sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点 设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到 1000节点。redis cluster集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单

redis cluster集群搭建

1.原生搭建

1.配置开启cluster节点

cluster-enabled yes（启动集群模式）

cluster-config-file nodes-8001.conf（这里800x最好和port对应上）

2.meet

cluster meet ip port

3.指派槽

查看crc16 算法算出key的槽位命令 cluster keyslot key

16384/3 0-5461 5462-10922 10923-16383 16384/4 4096

cluster addslots slot（槽位下标）

4.分配主从

cluster replicate node-id

2.使用redis提供的rb脚本

redis cluster集群需要至少要三个master节点，我们这里搭建三个master节点，并且给每个 master再搭建一个slave节点，总共6个redis节点，由于节点数较多，这里采用在一台机器 上创建6个redis实例，并将这6个redis实例配置成集群模式，所以这里搭建的是伪集群模 式，当然真正的分布式集群的配置方法几乎一样，搭建伪集群的步骤如下： 第一步：在/usr/local下创建文件夹redis-cluster，然后在其下面分别创建6个文件夾如下 （1）mkdir -p /usr/local/redis-cluster （2）mkdir 8001、 mkdir 8002、 mkdir 8003、 mkdir 8004、 mkdir 8005、 mkdir 8006 第一步：把之前的redis.conf配置文件copy到8001下，修改如下内容： （1）daemonize yes （2）port 8001（分别对每个机器的端口号进行设置） （3）bind 127.0.0.1（如果只在本机玩则可以指定为127.0.0.1 如果需要外网访问则需要指定本机真实ip） 定可能会出现循环查找集群节点机器的情况） （4）dir /usr/local/redis-cluster/8001/（指定数据文件存放位置，必须要指定不同的目 录位置，不然会丢失数据） （5）cluster-enabled yes（启动集群模式） （6）cluster-config-file nodes-8001.conf（这里800x最好和port对应上） （7）cluster-node-timeout 5000 （8）appendonly yes 第三步：把修改后的配置文件，分别 copy到各个文夹下，注意每个文件要修改第2、4、6 项里的端口号，可以用批量替换： :%s/源字符串/目的字符串/g 第四步：由于 redis集群需要使用 ruby命令，所以我们需要安装 ruby（redis5.0之后省略） （1）yum install ruby （2）yum install rubygems （3）gem install redis --version 3.0.0（安装redis和 ruby的接囗） 第五步：分别启动6个redis实例，然后检查是否启动成功 （1）/usr/local/redis/bin/redis-server /usr/local/redis-cluster/800*/redis.conf （2）ps -ef | grep redis 查看是否启动成功

第六步：在redis3的安装目录下执行 redis-trib.rb命令创建整个redis集群 （1）cd /usr/local/redis3/src （2）./redis-trib.rb create --replicas 1 127.0.0.1:9000 127.0.0.1:9001 127.0.0.1:9002 127.0.0.1:9003 127.0.0.1:9004 127.0.0.1:9005

redis5.0使用/usr/local/bin/redis-cli --cluster create 192.168.0.104:7000 192.168.0.104:7001 192.168.0.104:7002 192.168.0.104:7003 192.168.0.104 :7004 192.168.0.104:7005 --cluster-replicas 1

第七步：验证集群： （1）连接任意一个客户端即可：./redis-cli -c -h -p (-c表示集群模式，指定ip地址和端口 号）如：/usr/local/redis/bin/redis-cli -c -h 127.0.0.1 -p 800* （2）进行验证： cluster info（查看集群信息）、cluster nodes（查看节点列表） （3）进行数据操作验证 （4）关闭集群则需要逐个进行关闭，使用命令： /usr/local/redis/bin/redis-cli -c -h 127.0.0.1 -p 800* shutdown

集群伸缩

1.扩容集群

1.准备新节点

2.加入集群

使用redis-cli 语法：add-node 新节点ip 端口 已存在节点ip 端口

使用原生命令 语法：cluster meet ip port

指定主从

使用redis-cli 语法（加入时指定）：add-node 新节点ip 端口 已存在节点ip 端口 --cluster-slave --cluster-master-id masterID

使用原生命令 语法：cluster replicate node-id

3.迁移槽和数据

1.槽迁移计划

语法：/redis-cli --cluster reshard 已存在节点ip ： 端口

/usr/local/bin/redis-cli --cluster reshard 192.168.0.104:7000

2.迁移数据

执行流程：提示要分配多少槽-》接收节点ID-》all/done

3.添加从节点

2.缩容集群

1.下线迁移槽

语法：redis-cli --cluster reshard --cluster-from 要迁出节点ID --cluster-to 接收槽节点ID --cluster-slots 迁出槽数量 已存在节点ip 端口

/usr/local/bin/redis-cli --cluster reshard --cluster-from a2fdd1359d03acacf2a6e558acbc006639445d53 --cluster-to 1794864d5f8af79e88cfc0f699f02b6341c78b5c --cluster-slots 1366 192.168.0.104 7000

2.忘记节点.关闭节点

语法： redis-cli --cluster del-node 已存在节点IP：端口 要删除的节点ID

/usr/local/bin/redis-cli --cluster del-node 192.168.0.104:7000 8de55e2a7419983184cede9daab5d36ee9da1fa3

cluster客户端

1.moved重定向：指我们发送命令时，会对发送的key进行crc16算法，得到一个数字，然而我们连接的客户端并不是管理这个数字的范围，所以会返回错误并告诉你此key应该对应的槽位，然后客户端需要捕获此异常，重新发起请求到对应的槽位

2.asx重定向：指在我们送发命令时，对应的客户端正在迁移槽位中，所以此时我们不能确定这个key是还在旧的节点中还是新的节点中

3.smart客户端

1.从集群中选取一个可运行节点，使用cluster slots初始化槽和节点映射。

2.将cluster slots的结果映射到本地，为每个节点创建jedispool

3.准备执行命令

故障转移（与哨兵相似）

1.故障发现： 通过ping/pong消息实现故障发现（不依赖sentinel）

2.故障恢复

1.检查资格

1.每个从节点检查与主节点的断开时间

超过cluster-node-timeout * cluster-replica-validity-factor 时间取消资格

2.选择偏移量最大的

替换主节点

1.当前从节点取消复制变为主节点（slaveof no one）

2.撤销以前主节点的槽位，给新的主节点

3.向集群广播消息，表明已经替换了故障节点

redis集群演变过程

1.单机版

核心技术：持久化

持久化是最简单的高可用方法（有时甚至不被归为高可用的手段），主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。

2.主从复制

复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。

3.哨兵

在复制的基础上，哨兵实现了自动化的故障恢复。缺陷是写操作无法负载均衡；存储能力受到单机的限制。

4.集群

通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案