如何保证Redis的可靠性

如何保证Redis的可靠性

保证Redis的可靠性其实并不难,难的是如何做到持续稳定,下面会从资源隔离、多副本、故障恢复这三大维度,分析保障Redis可靠性的最佳实践。

①按业务线部署实例

提升可靠性的第一步就是资源隔离。最好按照不同的业务线来部署Redis实例,这样其中一个实例发生故障时,不会影响到其它业务,这种资源隔离的方案,实施成本是最低的,但是成效确实非常大的。

②部署主从集群

如果你只使用的那几版的Redis,那么就会存在机器宕机服务不可用的风险。所以需要部署多副本实例,即主从集群,这样当主库宕机之后,依旧有从库可以使用,避免了数据丢失的风险,也降低了服务不可用的时间。

在部署主从集群时,还需要注意组从库需要部署在不同机器上,避免交叉部署。这样的话,Redis的主库会承担所有的读写流量,所以我们一定要优先保证主库的稳定性,即使从库机器异常,也不要对主库造成影响。而且,有时我们需要对Redis做日常维护,例如数据定时备份等操作,这时你就可以只在从库上进行,这样只会消耗从库机器的资源,也避免了对主库的影响。

③合理配置主从复制参数

在部署主从集群时,如果参数配置不合理,也有可能导致主从复制发生问题:主从复制中断;从库发起全量复制,主库性能受到影响。

有以下2个建议:    

                        设置合理的repl-backlog参数:过小的repl-backlog在写流量较大的场景下,主从复制中断会引发全量复制数据的风险。

                        设置合理的slave client-output-buffer-limit:当从库复制发生问题时,过小的buffer会导致从库缓冲区溢出,从而导致复制中断。

④部署哨兵集群,实现故障自动切换

只部署了主从节点,但故障发生时是无法自动切换的,所以,你需要部署哨兵集群,实现故障的自动切换。而且,多个哨兵节点需要分布在不同机器上,实例为奇数个,防止哨兵选举失败,影响切换时间。

    以上这些就是保障Redis高可靠实践优化,这些都是部署和运维层的优化。


日常运维Redis需要注意什么

①禁止使用KEYS/FLUSHALL/FLUSHDB命令

执行这些命令,会长时间阻塞Redis主线程,危害极大。必须使用的话建议:

                SCAN替换KEYS  

                4.0+版本可使用FLUSHALL/FLUSHDB ASYNC,清空数据的操作放在后台线程执行

②扫描线上实例时,设置休眠时间

不管是使用SCAN扫描线上实例,还是对实例做bigkey统计分析,扫描一定要记得设置休眠时间,放置在扫描过程中,实例OPS过高对Redis产生性能抖动。

③慎用MONITOR命令

在排查Redis问题时,会使用MONITOR查看Redis正在执行的命令。但如果Redis OPS比较高,在执行MONITOR会导致Redis输出缓冲区的内存持续增长,这会严重消耗Redis的内存资源,甚至会导致实例内存超过maxmemory,引发数据淘汰,这种情况需要格外注意。

④从库必须设置为slave-read-only

从库必须设置为slave-read-only状态,避免从库写入数据,导致主从数据不一致。除此之外,从库如果是非only-read状态,4.0以下的Redis会存在一下bug:从库写入了有过期时间的数据,不会做定时清理和释放内存。这样会造成从库的内存泄露。

⑤合理timeout和tcp-keepalive参数

如果因为网络的原因,导致大量客户端链接与Redis意外中断,恰好Redis配置的maxclients参数比较小,此时有可能导致客户端无法与服务器建立新的连接(服务端认为超过了maxclients)。造成这个原因,在于客户端与服务端每建立一个连接Redis都会给这个客户端分配一个client fd。当客户端与服务端网络发生问题时,服务端并不会立即释放这个client fd。

Redis内部有一个定时任务,会定时检测所有的client的空闲时间是否超过配置的timeout值。如果Redis没有开启tcp-keepalive的话,服务端直到配置的timeout时间后,才会清理释放这个client fd。在没有清理之前,如果还有大量新连接进来,就有可能会导致Redis服务端内部持有的client fd超过了maxclients,这时新的链接就会被拒绝。针对这种情况,有以下建议:

            不要配置过高的timeout,让服务端尽快快无效的client fd清理掉。

            Redis开启tcp-keepalive:这样服务端会定时给客户端发送TCP心跳包,检测连接连通性,当网络异常时,可以尽快清理僵尸client fd。

⑥调整maxmemory时,注意主从库的调整顺序

Redis5.0以下版本存在这样一个问题:从库内存如果超过了maxmemory,也会触发数据淘汰。

在某些场景下。从库可能优先主库达到maxmemory的(例如在从库执行MONITOR命令,输出缓冲区占用大量内存),那么此时数据库开始淘汰数据,主从库就会产生不一致。所以要注意主从库的修改顺序:

                调大maxmemory:先修改从库,在修改主库

                调小maxmemory:先修改主库,在修改从库

直到Redis5.0,才增加一个配置replica-ignore-maxmemory,默认从库超过maxmemory不会淘汰数据,才解决此问题。


Redis安全如何保证

Redis被注入可执行脚本,然后拿到机器的root权限,这是很严重的安全问题,这是因为在部署Redis时,没有把安全风险注意起来,有以下建议:

1.不要把Redis部署在公网可访问的服务器上。

2.部署时不使用默认端口6379。

3.以普通用户启动Redis进程,禁止root用户启动。

4.限制Redis配置文件的目录访问权限。

5.推荐开启密码验证。

6.禁用/重命名危险命令(KEYS/FLUSHALL/FLUSHDB/CONFIG/EVAL)。

只要做到以上几点,基本上就可以保证Redis的安全风险在可控范围内。


如何预防Redis问题

合理的资源规划

在部署Redis时,提前做好资源规划,可以避免很多因为资源不足产生的问题。

1.保证机器有足够的CPU、内存、带宽、磁盘资源。

2.提前做好容量规划,主库机器预留一半内存资源,防止主从机器网络故障,引发大面积全量同步,导致主库机器内存不足的问题。

3.单个实例内存建议控制在10G以下,大实例在主从全量同步、RDB备份时有阻塞风险。

完善的监控预警

监控预警是提高稳定性的重要环节,完善的监控预警,可以把问题提前暴露出来,这样才可以快速反应,把问题最小化。有以下建议:

1.做好机器CPU、内存、带宽、磁盘监控,资源不足时及时报警,任意资源不足都会影响Redis性能。

2.设置合理的slowlog阈值,并对其进行监控,slowlog过多及时报警。

3.监控组件采集Redis INFO信息时,采用长连接,避免频繁的短连接。

4.做好实例运行时监控,重点关注expired_keys、evicted_keys、latest_fork_usec指标,这些指标短时突增可能会有阻塞风险。


点击显示
· 使用Redis连接池大小该如何合理设置
· 缅怀最爱
· 给自己
· 风儿悠悠醉墨翰
· C# 类的get、set方法以及方法重载