Redis 单机主从高可用性优化

redis是一款高性能的内存数据库,本文侧重描述redis在主从模式下遇到的一些问题以及如何调优,特别是在云环境下遇到的一些特殊问题,至于redis如何使用以及数据结构等,可以百度,网上有大量的资料。

主结点

在非集群环境的情况下,使用redis主从模式来保证业务的高可用性,因此在此种模式下,读写都在主机,要保证主机高性能必须在主机上尽量少的IO操作同时又要兼顾网络导致的主从断链而带来的频繁的fullsync,因此针对主机优化要点如下:

关闭主结点aof

关闭主aof比较简单,可以通过如下命令进行关闭,在主结点上执行

config set appendonly no

关闭主结点save

关闭主上的save原因是避免save的规则导致的bgsave而引起业务波动,bgsave是非常消耗性能的,redis的默认save规则为" 900 1 "," 300 10 ","," 60 10000 ",在此规则下写入量大的情况下会导致主机频繁的bgsave而导致性能急剧下降,可以通过命令config set save关闭主机上因写入而触发的bgsave,数据的完整性交给备机完成,即使这样也无法完全杜绝bgsave,在从机第一连上来或者从机断开过久的情况下还是会触发bgsave

主从同步后key数量不一致问题

因为redis只会在主上进行定期key淘汰并命令传播到从机,因此在key数量很多而且很多key又带有过期时间的情况下,因为淘汰机制问题会导致主从同步后从机的key数量和主机的key数量不一致(过期的key不会同步到从机),而最根本原因是主机在在serverCron函数中进行淘汰的时候一次默认只会淘汰20个key,默认值在redis.h#define ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP 20 /* Loopkups per loop. */定义,解决该问题的方式一是修改该数量重新编译,而是修改redis.conf中的hz属性,加快serverCron执行频率

发送缓冲区满导致主从断开频繁fullsync问题

redis为每一个链接的客户端维护了一个发送缓冲区,并限定了大小(有软硬之分),当发送缓冲区满后(超过了设定的值)redis即会断开该链接从而实现自我保护功能,但是问题也出现,当写入量非常大的时候而该值又设置的不合理会导致主从频繁断连,而且因为写入量巨大新连接上来的从机不能进行部分同步而触发全量同步,因此为了避免该问题可以根据redis实际的写入数据以及网络情况综合来修改参数client-output-buffer-limit,具体修改多大要结合实际写量和网络情况而定,设置方式为:

config set client-output-buffer-limit "slave 4295000768 4295000768 0"

slave 表示从机链接,普通客户端为normal,发布订阅客户端为:pubsub

复制积压缓冲区repl-backlog-size

复制积压缓冲区缓存了最近的写命令,在有从机链接的时候创建,该缓冲区大小默认为1M,改值决定了从机断开在重新链接上来后是全量同步还是部分同步,如果复制偏移量在复制积压缓冲区内为部分同步,小于或者大于复制积压缓冲区那么就行全量同步,可以根据实际情况通过config set 命令重新设定repl-backlog-size

节点死活判定

在高可用系统中,节点的死活检查非常重要,检测逻辑要快速发现问题并迅速切换,检测手段也是多重多样, redis检测节点死活采用了进程探测加服务ping的方式进行,进程探测是为了确认目标进程存在,但是目标进程存在也不一定确认服务可用,所以另加了去ping指定服务节点的方式

在实际使用过程中发现某些节点会奇怪的进行切换,而去看机器的内存、网络、以及IO都很低,除了某些CPU核在切换的时刻被跑满,然后分析切换节点的slowlog发现,用户在那个时间点提交了耗时高达几分钟的查询,因为redis是单线程处理,因为某一个耗时高的命令而导致了ping超时导致了切换,优化逻辑就是适当增加ping的耗时和增加ping的次数,这个过程中也要有所取舍,即要很快的发现问题,又不能因为高耗时命令而误判进行切换

从结点

从结点主要用来保证数据安全性,并在主结点死掉后快速恢复成主结点并提供服务,在作为从结点的时候需要打开rdb和aof,并按照一定的时间规则把用户的rdb放入到冷备中心,在提升为主节点后,相关设置要立刻恢复到和主节点一样的配置。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏微服务生态

论代码级性能优化变迁之路(一)

大家好,很久没有和大家一起讨论技术了,那么今天我将和大家一起探讨我负责的某项目的性能变迁之路。

602
来自专栏风火数据

高级Java研发师在解决大数据问题上的一些技巧

众所周知, Java 在处理数据量比较大的时候,加载到内存必然会导致内存溢出,而在一些数据处理中我们不得不去处理海量数据,在做数据处理中,我们常见的手段是分解,...

672
来自专栏java达人

调用外部api时的数据一致性问题

春节又要来了,远行的小伙伴们将开始一场刺激的抢票之旅,关于购票,从程序角度上而言,大致分为这么几步: 1、 检查是否有剩余的票 2、 购票后票数减一 3、...

4128
来自专栏腾讯云数据库(TencentDB)

【腾讯云 MongoDB】 基于snapshot的从库读优化

我们发现腾讯云上一些腾讯云MongoDB实例在主库写压力比较大的情况下,这时从库上会出现很多慢查询,经过调查发现,从库在回放oplog的时候加了全局锁,阻塞了所...

4830
来自专栏牛肉圆粉不加葱

为什么 Spark Streaming + Kafka 无法保证 exactly once?

结合文章 揭开Spark Streaming神秘面纱④ - job 的提交与执行我们画出了如下 job 调度执行流程图:

651
来自专栏杨建荣的学习笔记

通过Oracle来辅助MySQL数据问题的恢复(r5笔记第31天)

今天琢磨一个问题,在平时的工作中如果碰到一些不规范的操作,drop,truncate,delete,恢复起来还是很困难的,drop操作在oracle中如果开启了...

3318
来自专栏晨星先生的自留地

超哥的Linux私房菜(1)---硬盘以及分区表

1796
来自专栏CSDN技术头条

资源控制在大数据和云计算平台中的应用

本文针对大数据平台中资源控制这个层面来详细介绍资源控制在不同操作系统上的具体技术实现,以及大数据平台和资源控制的集成。

5468
来自专栏Vamei实验室

Linux进程间通信

我们在Linux信号基础中已经说明,信号可以看作一种粗糙的进程间通信(IPC, interprocess communication)的方式,用以向进程封闭的内...

17810
来自专栏杨建荣的学习笔记

一则报警信息所折射出来的诸多问题(r9笔记第14天)

在主备库环境中,如果出现数据文件级的一些不一致,后期修复会很麻烦,所以这种情况可以提前规避,减少后期的隐患,我定制了一个数据库监控选项,即数据文件状态的检查。 ...

3398

扫码关注云+社区