如何保证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指标，这些指标短时突增可能会有阻塞风险。