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选择： 响应旧的数据或返回错误，提示同步进行中， 不同应用对数据一致性有不同的容忍程度，可灵活选择。