Redis 简单HA方案小结

策略摘要

主从各一台互备，不做读写分离，备库只同步，不对外提供服务。主库无持久化策略，备库选用rdb。

HA方案

原有cache01做master，无需persistence以便提供最佳读写性能。

新申请cache02做slave，persistence采用RDB，同步自cache01的数据，不对外提供服务，仅作为backup。

应用指向F5上的VIP，间接调用master。

注1：配置文件无论主备统一使用master的配置（除内存使用限制），启动服务后通过执行相应命令切换到所属角色。

注2：RDB持久化的触发策略为：A分钟更新达N条或B分钟内有更新。启动命令为config set save "B 1 A N"；关闭命令为config set save ""。

挂载slave的步骤：

1、拷贝master的配置文件，并修改内存使用限制配置项maxmemory。

2、启动slave的redis服务进程，执行命令slaveof masterIP masterPort进行同步。

3、启动RDB持久化策略。

4、执行验证确认数据同步完毕。

若master挂掉，需要执行以下步骤：

1、原slave上执行命令 slaveof no one切断同步并升级为新master

2、F5改为指向原slave，以保证应用可继续对外服务

3、恢复原master后，启动redis服务进程，并执行命令slaveof 原slaveIP 原slavePort，从而降级为新slave，并从master同步数据。

4、关闭master并打开slave上的rdb，以保证master的读写性能。

Q&A

1、为什么在master中不做持久化，但是在slave中却要做持久化？slave中的持久化意义是什么？

答：redis持久化支持两种模式，RDB（内存快照）和AOF（类似于redo log），无论哪种都有一定的性能开销。在高并发访问的情况下，RDB模式会使服务的性能指标出现明显抖动甚至骤停1秒；AOF在性能开销上比RDB要好，但数据恢复时重新加载到内存的时间与数据量成正比。

为了让master有最佳性能表现，可将持久化关闭，因为有主从互备，数据安全不成问题。定期备份有额外的好处，例如可以很方便地将数据回滚到某个时间点，也便于线下环境取线上真实数据测试。

2、主从同步的原理使用replication,其意义好像是用于读写分离提升性能，而不是灾备？

答：replication能同时提供灾备和读写分离，两者并不冲突。现阶段应用层面并未给redis造成较大压力，也就暂未考虑读写分离。其实单机用持久化来灾备也是可以的，只是这样做可用性会差一些（数据重新加载到内存类似于PC从休眠状态恢复需要一点时间），其次极端情况下如果硬盘坏了麻烦就大了。

可以肯定的是redis的replication与持久化无关。一旦主从连接从断开状态恢复，slave并不关心这是否是第一次连接，始终会执行全量同步。因此正在同步的过程中，slave无法提供与master一致的数据。redis提供两种策略供slave选择：响应旧的数据或返回错误，提示同步进行中，不同应用对数据一致性有不同的容忍程度，可灵活选择。