高性能Redis缓存服务器-redis.conf文件配置端口号、授权IP、Redis后台启动、Redis日志、Redis密码

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/king_kgh/article/details/83115829

Redis的强大功能依赖于Redis的配置文件,比如密码验证,授权机器访问,端口号配置,集群配置等,我们可以通过配置文件非常方便的对Redis进行配置。Redis的核心配置文件只有一个,就是redis.conf。在发行包中就有提供。在启动Redis服务器的时候我们可以通过redis-server 命令后跟配置文件的具体路径来指定要使用的配置文件。

1. 配置redis的端口号

Redis是一个单线程的架构,这也是Redis高性能的一个原因。也正是由于这个原因,在一般的小型项目中使用Redis一般会在一台机器上规划部署多个Redis进程,因此要保证多个Redis进程都能正常工作,就要给不同的Redis进程分配不同的端口号。Redis端口号默认是6379。

直接修改配置文件第92行即可,一般来讲,规划多台redis会按照 16379,26379的方式设置,或者使用6379,6380,6381这种方式设置端口号,一般不建议随意设置,更不要设置1024以下的端口号。

 2. 配置所有机器均可访问Redis服务器

Redis为了安全,在默认情况下,只能在本机访问,因此为了能让局域网内机器访问,或者让全网内机器都能访问,也需要修改默认配置。

这里需要修改两个地方,第一个是上面截图中的第88行,把protected-mode改为no第二个是把69行的bind指定为0.0.0.0,表示全网内计算机都能访问。

3.配置Redis授权密码

Redis默认启动后可以直接通过客户端连接,但这样会有一定的安全隐患,可以通过设置密码的方式来增强Redis的安全性。对于密码的配置非常简单。

 通过修改requirepass的值就可以了。

4. 后台方式启动

我们在启动Redis的时候,都会看到这么一个样子

虽然看起来挺好看,但是毕竟不实用,在服务器上没人去看,这个时候如果你Ctrl+ C一下,Redis的进程就退出了,因此我们在启动Redis服务的时候一般是后台启动,输出的信息全部记录到日志文件中去。这个可以修改配置的第136行,改为yes就可以了。

5. 停止Redis服务

启用了deamon之后,就以后台的方式启动了,这样也就不能通过Ctrl+C的方式停止服务了。那么怎么才能停止Redis又成了困扰我们的一个问题。其实很简单,有多种方式来停止Redis服务。

首先我们要获取到Redis服务的进程号,然后通过kill命令杀死Redis进程就可以了。通过第配置文件第135行可以看到,当以deamon启动,会生成一个redis.pid文件,这个文件中保存的就是Redis当前进程的进程号。除了读取文件获取pid以外,也可以通过linux命令

pstree -p | grep redis

可以看到Redis当前的进程号为 12880,执行下面的linux命令结束redis进程

kill -9 12880

6. 记录日志

如果启用了deamon,那么就要记得配置日志,否则的话日志就被输出到黑洞里了。Redis日志一共有四个等级,等级越高,输出的信息越少,从低到高分别是 debug,verbose,notice,warning。默认为notice。在测试环境可以使用debug,获取更多的调试信息,在生产一般会使用notice或者warning。

7. 持久化

Redis支持两种持久化方式,分别是AOF和RDB。这两种持久化的方式有什么区别呢,RDB可以简单理解为全量备份,速度比较快,但是不可能实时备份。就类似于我们使用数据库的全量备份,只能是间隔一段时间备份一次。这样就有一个问题,如果在备份的间隔期间挂了,那么在这期间的数据就都丢失了,很难找回。AOF的思路是实时备份,备份的是对Redis的写操作,非常类似于MySQL的binlog,当进行数据恢复的时候,可以再执行一次这个持久化文件,数据就都恢复了。但是AOF这种方式,产生的日志文件会非常大。

Redis默认是开启RDB持久化方式的,但没有开启AOF方式,这两种持久化方式都可以通过配置的方式来进行控制。

 

8.总结

上面总结了一些Redis的常用配置像,Redis的配置还有很多。其他的配置项一般都是和Redis的具体功能相联系的,比如Redis集群,Redis Sentinel以及Redis Cluster。这些的配置项最好是在了解了具体的功能之后再来配置,我们这里只说一些简单的常用的对于单台Redis节点的配置,像集群,哨兵这些后面再说吧。

猜你喜欢

转载自blog.csdn.net/king_kgh/article/details/83115829