这样，重启服务器后则需要使用新命令来执行操作，否则服务器会报错unknown command
关闭maxclients 设置同时连接的最大客户端数量，一旦达到了限制，Redis会关闭所有的新连接并发送一个"max number of clients reached"的错误 关闭，默认10000
maxmemory 不要使用超过指定数量的内存，一旦达到了，Redis会尝试使用驱逐策略来移除键 关闭
maxmemory-policy
当达到了maxmemory之后Redis如何移除数据，有以下的一些策略：
volatile-lru，使用LRU算法，移除范围为设置了失效时间的
allkeys-lru，根据LRU算法，移除范围为所有的
volatile-random，使用随机算法，移除范围为设置了失效时间的
allkeys-random，使用随机算法，移除范围为所有的
volatile-ttl，移除最近过期的数据
noeviction，不过期，当写操作的时候返回错误
注意，当写操作且Redis发现没有合适的数据可以移除的时候，将会报错
关闭，noevictionappendonly 是否开启AOF，关于AOF后面再说 no
appendfilename AOF文件名称 appendonly.aof
appendfsync
操作系统实际写数据到磁盘的频率，有以下几个选项：
always，每次有写操作都进行同步，慢，但是最安全
everysec，对写操作进行累积，每秒同步一次，是一种折衷方案
no，当操作系统flush缓存的时候同步，性能更好但是会有数据丢失的风险
当不确定是使用哪种的时候，官方推荐使用everysec，它是速度与数据安全之间的一种折衷方案
everysecno-appendfsync-on-rewrite
aof持久化机制有一个致命的问题，随着时间推移，aof文件会膨胀，当server重启时严重影响数据库还原时间，因此系统需要定期重写aof文件。
重写aof的机制为bgrewriteaof（另外一种被废弃了，就不说了），即在一个子进程中重写从而不阻塞主进程对其他命令的处理，但是这依然有个问题。
bgrewriteaof和主进程写aof，都会操作磁盘，而bgrewriteaof往往涉及大量磁盘操作，这样就会让主进程写aof文件阻塞。
针对上述问题，可以使用此时可以使用no-appendfsync-on-rewrite参数做一个选择：
no，最安全，不丢失数据，但是需要忍受阻塞
yes，数据写入缓冲区，不造成阻塞，但是如果此时redis挂掉就会丢失数据，在Linux操作系统默认设置下，最坏场景下会丢失30秒数据
noauto-aof-rewrite-percentage 本次aof文件超过上次aof文件该值的百分比时，才会触发rewrite 100
auto-aof-rewrite-min-size aof文件最小值，只有到达这个值才会触发rewrite，即rewrite由auto-aof-rewrite-percentage+auto-aof-rewrite-min-size共同保证 64mb
aof-load-truncated
redis在以aof方式恢复数据时，对最后一条可能出问题的指令的处理方式：
yes，log并继续
no，直接恢复失败
yesslowlog-log-slower-than Redis慢查询的最低条件，单位微妙，即查询时间>这个值的会被记录 10000
slowlog-max-len Redis存储的慢查询最大条数，超过该值之后会将最早的slowlog剔除 128
lua-time-limit 一个lua脚本执行的最大时间，单位为ms 5000
cluster-enabled 正常来说Redis实例是无法称为集群的一部分的，只有以集群方式启动的节点才可以。为了让Redis以集群方式启动，就需要此参数。 关闭
cluster-config-file 每个集群节点应该有自己的配置文件，这个文件是不应该手动修改的，它只能被Redis节点创建且更新，每个Redis集群节点需要不同的集群配置文件 关闭，nodes-6379.conf
cluster-node-timeout 集群中一个节点向其他节点发送ping命令时，必须收到回执的毫秒数 关闭，15000
cluster-slave-validity-factor
如果该项设置为0，不管Slave节点和Master节点间失联多久都会一直尝试failover。