认识达内从这里开始

许多的企业在设计推送服务以及进行数据分析的时候一般都会使用Redis系统来进行相关功能的开发设计。

今天，我们就一起来了解一下在设计Redis配置功能的时候，我们都需要掌握哪些技术，下面就开始今天的主要内容吧。

一、Server配置

llkeys-lru还是noeviction

Redis的服务端有这样一个配置参数maxmemory-policyallkeys-lru，是说Redis的使用内存达到分配上限的时候默认使用lru的key淘汰策略(还有其它可选策略)。

使用Redis的一个核心优势就是Redis具有丰富的数据结构，当前的大部分业务也都是看中这一点才选择Redis，某些复杂结构的数据集一旦被清空，没有业务上的恢复机制是不可能自动重建的。如果你的Redis不是简单的字符串缓存，那么就需要慎重考虑是否禁用key淘汰了。

lua-time-limit

Redis支持自定义命令的一个优势是因为支持Lua脚本，我们部分业务使用了Lua脚本，这些自定义指令的运行时间需要被测试、评估，在要求QPS比较高的应用中，一定不要有Lua脚本长期占用CPU资源。虽然lua-time-limit不会终止Lua脚本，但会使Redis到达时限后开始响应客户端请求返回Busy错误，这样能在大量连接被挂起、超时时，避免不知道发生了什么。Lua时限需要设定，但还是建议提前测试lua脚本的性能。

slaveof

这个指令很特别，它指定了当前Redis实例是某个Master实例的slave。这个指令如果在配置文件中写死，那么实例启动后就只能是slave，除非有哨兵将它提升为master，或手动执行slaveofnoone。这个指令是一个会被哨兵动态从配置文件里删除或者添加的指令，它的存在与否最好交由哨兵决定。

我们之前的配置文件是通过子文件引入的这个指令，这样会有一个问题，如果某个slave被哨兵选举成为了master，它的slaveof指令要被移除，但子文件中写死的指令是无法移除的，一旦重启这个master实例，它又成了slave。如果不注意这个子文件的存在，问题还很不好排查，不知道发生了什么。线上没有遇到过问题，测试环境做过一次主从切换，操作过程中，重启了下master，结果掉坑了。这个测试的例子后面还会讲，因为它还涉及到哨兵及主从切换。

二、主从切换

Redis的使用一般有单点和集群两种方式，对QPS有很高的要求一般会搭建集群，目前我们这边一般业务对QPS没有那么高的需求，所以都是单点主从模式(集群各节点也是主从模式)。

说到主从切换不得不先说哨兵，Master节点故障时势必要求能及时地切换到slave节点，尽快恢复应用。那么监测Master状态，发起主从切换过程，最终将新选举的master通知给客户端应用的任务就是由哨兵完成的。哨兵一般需要部署一个集群。

三、持久化

Redis有两种持久化方式，AOF和RDB，AOF持久化是指追加写命令到aof文件的方式，RDB是指定期保存内存快照到rdb文件的方式。

RDB虽然可以通过bgsave指令后台保存快照，但fork()子进程是有开销的，在内存数据集较大的情况下会占用很长的cpu时间，fork新进程时，虽然可共享的数据内容不需要复制，但会复制之前进程空间的内存页表，如果内存空间有40G(考虑每个页表条目消耗8个字节)，那么页表大小就有80M，这个复制是需要时间的，在有的服务器结点上测试，35G的数据bgsave瞬间会阻塞200ms以上，一般建议Redis使用内存不超过20g。I/O消耗，我们线上是在Slave节点开启rdb持久化，磁盘性能一般，1.2g的rdb文件持久化一分钟一次，一次大概耗时30s左右，所以rdb的频率也不能太频繁，需要根据情况做好配置。

AOF是追加写命令到aof文件的方式，优点是可以基本做到数据无损，缺点是文件增长较快，需要间歇性bgrewrite，bgrewrite也是一个既耗cpu又耗磁盘IO的操作，单cpu利用率最高可达100%。bgrewrite期间可以设置将新的写请求暂时缓存，bgrewrite完成后同步写盘，同步会暂时停止处理客户端请求，如果bgrewrite时间较长，缓冲区积压数据较多，核心阻塞时间会很长，所以如果必须要开启aof，一般建议找几个空闲时段设置脚本来做bgrewrite。

AOF还有一个比较坑的地方是刷盘策略fsync的设置，这个设置一般有3种方式：always、everysec、no，如果设置为no，就将写盘的时机交给操作系统，这在很大程度上牺牲了aof数据无损的优势，如果设置为always就意味着每条命令都会同步刷盘，会造成频繁I/O，所以一般建议是设置everysec，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞，因为是同步操作所以核心处理阻塞，开启aof且要求Redis性能无损对磁盘有极高要求。

作者：闫东旭

微信公众号：DBAplus社群

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。