1. 主从复制（从可以作为备份，故障必须手动切换）

1.1 全量同步

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。

1.2 增量同步

Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。

1.3 Redis主从同步策略

主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

需要注意：如果多个Slave断线了，需重启时，因为只要Slave启动，就会发送sync请求和主机全量同步，当多个同时出现的时候，可能会导致Master IO剧增宕机。

1.4 部分重新同步

从Redis 2.8开始，如果遭遇连接断开，重新连接之后可以从中断处继续进行复制，而不必重新同步。

1.5 无磁盘复制

使用这种设置时，子进程直接将RDB通过网络发送给从服务器，不使用磁盘作为中间存储。

1.6 配置

• 主从复制的配置十分简单，把下面这行加入到从服务器的配置文件中即可。

slaveof <masterip> <masterport>

• 另外你可以调用 SLAVEOF 命令，主服务器就会开始与从服务器同步。

• 关于部分重新同步，还有一些针对复制内存缓冲区的优化参数。

• 使用 repl-diskless-sync 配置参数来启动无磁盘复制。

• 使用 repl-diskless-sync-delay 参数来配置传输开始的延迟时间，以便等待更多的从服务器连接上来。

1.7 只读从服务器

• 从Redis 2.6开始，从服务器支持只读模式，并且是默认模式。

这个行为是由Redis.conf文件中的 slave-read-only 参数控制的，可以在运行中通过 CONFIG SET 来启用或者禁用。

• rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

• rename-command CONFIG ""

1.8 限制有N个以上从服务器才允许写入

• 从Redis 2.8版本开始，可以配置主服务器连接N个以上从服务器才允许对主服务器进行写操作。

但是，因为Redis使用的是异步主从复制，没办法确保从服务器确实收到了要写入的数据，所以还是有一定的数据丢失的可能性。

• 还可以把这看做是CAP原则（一致性，可用性，分区容错性）不严格的一致性实现，虽然不能百分百确保一致性，但至少保证了丢失的数据不会超过M秒内的数据量。

min-slaves-to-write 3
min-slaves-max-lag 10

1.9 通过redis实现服务器崩溃等数据恢复

1.9.1 RDB方式 (默认)

• RDB是redis默认采用的持久化方式，在配置文件中已经预置了3个条件

save 900 1 #900秒内有至少1个键被更改则进行快照
save 300 10 #300秒内有至少10个键被更改则进行快照
save 60 10000 #60秒内有至少10000个键被更改则进行快照

• 可以通过定时备份RDB文件来实现Redis数据库备份

RDB文件是经过压缩（可以配置 rdbcompression 参数以禁用压缩节省CPU占用）的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。

• 除了自动快照，还可以手动发送SAVE或BGSAVE命令让Redis执行快照，两个命令的区别在于，前者是由主进程进行快照操作，会阻塞住其他请求，后者会通过fork子进程进行快照操作。

• 通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。

• 这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围。如果数据很重要以至于无法承受任何损失，则可以考虑使用AOF方式进行持久化。

1.9.2 AOF方式（类似MySQL数据库二进制日志方式）

• 默认情况下Redis没有开启AOF(append only file)方式的持久化，可以在redis.conf中通过appendonly参数开启：

appendonly yes

• 在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中，载入的速度相较RDB会慢一些。

• 开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。

AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改：

appendfilename appendonly.aof

• 配置redis自动重写AOF文件的条件：

auto-aof-rewrite-percentage 100  # 当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据
auto-aof-rewrite-min-size 64mb   # 允许重写的最小AOF文件大小

• 配置写入AOF文件后，要求系统刷新硬盘缓存的机制：

# appendfsync always  # 每次执行写入都会执行同步，最安全也最慢
appendfsync everysec  # 默认，每秒执行一次同步操作
# appendfsync no      # 不主动进行同步操作，而是完全交由操作系统来做（即每30秒一次），最快也最不安全

Redis允许同时开启AOF和RDB，既保证了数据安全又使得进行备份等操作十分容易。

此时重新启动Redis后Redis会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少。

到底选择什么呢？下面是来自官方的建议

• 通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。
• 如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用RDB。
• 很多用户仅使用了AOF，但是我们建议，既然RDB可以时不时的给数据做个完整的快照，并且提供更快的重启，所以最好还是也使用RDB。

实际上，当Redis服务器挂掉时，重启时将按照以下优先级恢复数据到内存。

• 如果只配置AOF,重启时加载AOF文件恢复数据；
• 如果同时 配置了RDB和AOF,启动是只加载AOF文件恢复数据;
• 如果只配置RDB,启动是将加载dump文件恢复数据。

2. 哨兵模式（无法进行主从切换？）

Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis 的高可用性解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。

sentinel是redis高可用的解决方案，sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。

Sentinel作用：

• Master状态检测。
• 如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave。
• Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。

3. 集群模式（推荐生产环境使用！）

这是Redis3.0之后，官方推出的server端集群方案。

Redis Cluster并非使用Porxy模式来连接集群节点，而是使用无中心节点的模式来组建集群。

在Cluster出现之前，只有Sentinel保证了Redis的高可用性。

Redis Cluster实现在多个节点之间进行数据共享，即使部分节点失效或者无法进行通讯时，Cluster仍然可以继续处理请求。

若每个主节点都有一个从节点支持，在主节点下线或者无法与集群的大多数节点进行通讯的情况下， 从节点提升为主节点，并提供服务，保证Cluster正常运行。

Redis Cluster的节点分片是通过哈希槽（hash slot）实现的，每个键都属于这16384（0～16383）个哈希槽的其中一个，每个节点负责处理一部分哈希槽。

核心的三个目标：

• 性能：这是Redis赖以生存的看家本领，增加集群功能后当然不能对性能产生太大影响，所以Redis采取了P2P而非Proxy方式、异步复制、客户端重定向等设计，而牺牲了部分的一致性、使用性。
• 水平扩展：集群的最重要能力当然是扩展，文档中称可以线性扩展到1000节点。
• 可用性：在Cluster推出之前，可用性要靠Sentinel保证。有了集群之后也自动具有了Sentinel的监控和自动Failover能力。

原文：https://www.cnblogs.com/varden/p/15255580.html