Redis常见问题
一、Redis主从配置不一致
这个问题一般很少见,但如果有,就会发生很多诡异的问题,例如:
(1)max memory配置不一致:这个会导致数据的丢失。
原因:例如master配置4G,slave配置2G,这个时候主从复制可以成功,但如果在进行某一次全量复制的时候,slave拿到master的RDB加载数据时发现自身的2G内存不够用,这时就会触发slave的maxmemory策略,将数据进行淘汰。更可怕的是,在高可用的集群环境下,如果将这台slave升级成master的时候,就会发现数据已经丢失了。
(2)数据结构优化参数不一致(例如hash-max-ziplist-entries):这个就会导致内存不一致。
原因:例如在master上对这个参数进行了优化,而在slave没有配置,就会造成主从节点内存不一致的诡异问题。
(3)Redis主从复制的性能问题
第一次Slave向Master同步的实现是:Slave向Master发出同步请求,Master先dump出rdb文件,然后将rdb文件全量 传输给slave,然后Master把缓存的命令转发给Slave,初次同步完成。第二次以及以后的同步实现是:Master将变量的快照直接实时依次发 送给各个Slave。不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从复制是建立在内存快照的持久化基础上,只要有 Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞,但由于Redis使用单线程服务,如果Master快照文件比较大,那么第一次全量传输会耗费比较长时间,且文件传输过程中Master可能无法提供服务,也就是说服务会中断,对于关键服务,这个后果也是很可怕的。
以上根本问题的原因都离不开系统IO瓶颈问题,也就是硬盘读写速度不够快,主进程 fsync()/write() 操作被阻塞。
(4)单点故障问题
由于目前Redis的主从复制还不够成熟,所以存在明显的单点故障问题,这个目前只能自己做方案解决,如:主动复制,Proxy实现Slave对 Master的替换等,这个也是目前比较优先的任务之一。
总结:
Master最好不要做任何持久化工作,包括内存快照和AOF日志文件,特别是不要启用内存快照做持久化。
如果数据比较关键,某个Slave开启AOF备份数据,策略为每秒同步一次。
为了主从复制的速度和连接的稳定性,Slave和Master最好在同一个局域网内。
尽量避免在压力较大的主库上增加从库
为了Master的稳定性,主从复制不要用图状结构,用单向链表结构更稳定,即主从关系 为:Master<–Slave1<–Slave2<–Slave3…….,这样的结构也方便解决单点故障问题,实现Slave对 Master的替换,如果Master挂了,可以立马启用Slave1做Master,其他不变。
相关阅读:
1、Redis搭建哨兵
2、Redis搭建和主从复制
3、Redis配置文件详细总结
4、Redis常用数据类型
5、Redis三主三从集群
6、欢迎加入技术交流
更多相关文章
- Redis搭建和主从复制
- Redis 数据备份与恢复
- redis高可用集群架构总结
- postgresql12 流复制搭建
- [灾备]数据库容灾方式
- Power BI基础知识——编辑表
- 用Python关于 文件的复制移动压缩解压
- 实战:一文带你解决Mysql主从复制日常错误
- vs2019中解决scanf报错问题