OK,一般我们在生产上采用的持久化策略为 (1)master关闭持久化 (2)slave开RDB即可,必要的时候AOF和RDB都开启
该策略能够适应绝大部分场景,绝大部分集群架构。
为什么是绝大部分场景? 因为这套策略存在部分的数据丢失可能性。redis的主从复制是异步的,master执行完客户端请求的命令后会立即返回结果给客户端,然后异步的方式把命令同步给slave。因此master可能还未来得及将命令传输给slave,就宕机了,此时slave变为master,数据就丢了。
幸运的是,绝大部分业务场景,都能容忍数据的部分丢失。假设,真的遇到缓存雪崩的情况,代码中也有熔断器来进行资源保护,不至于所有的请求都转发到数据库上,导致我们的服务崩溃! ps:这里的缓存雪崩是指同一时间来了一堆请求,请求的key在redis中不存在,导致请求全部转发到数据库上。
为什么是绝大部分集群架构? 因为在集群中存在redis读写分离的情况,就不适合这套方案了。 幸运的是,由于采用redis读写分离架构,就必须要考虑主从同步的延迟性问题,徒增系统复杂度。目前业内采用redis读写分离架构的项目,真的太少了。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。