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

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值