Redis配置

1、基础配置

1.1、daemonize yes

#是否以后台进程运行

1.2、pidfile /var/run/redis/redis-server.pid

#pid文件位置

1.3、port 6379

#监听端口

1.4、bind 127.0.0.1

#绑定地址,如外网需要连接,设置0.0.0.0

1.5、timeout 300

 #连接超时时间,单位秒

1.6、loglevel notice

#日志级别,分别有:

# debug :适用于开发和测试

# verbose :更详细信息

# notice :适用于生产环境

# warning :只记录警告或错误信息

1.7、logfile /var/log/redis/redis-server.log

#日志文件位置

1.8、syslog-enabled no

#是否将日志输出到系统日志

1.9、databases 16

#设置数据库数量,默认数据库为0

2、快照方式

2.1、save 900 1

#在900s(15m)之后,至少有1个key发生变化,则快照

2.2、save 300 10

#在300s(5m)之后,至少有10个key发生变化,则快照

2.3、save 60 10000

#在60s(1m)之后,至少有1000个key发生变化,则快照

2.4、rdbcompression yes

#dump时是否压缩数据

2.5、dir /var/lib/redis

#数据库(dump.rdb)文件存放目录

3、主从复制

slaveof  #主从复制使用,用于本机redis作为slave去连接主redis

masterauth    #当master设置密码认证,slave用此选项指定master认证密码

slave-serve-stale-data yes     #当slave与master之间的连接断开或slave正在与master进行数据同步时,如果有slave请求,当设置为yes时,slave仍然响应请求,此时可能有问题,如果设置no时,slave会返回"SYNC with master in progress"错误信息。但INFO和SLAVEOF命令除外。

4、安全

requirepass foobared   #配置redis连接认证密码

5、限制

maxclients 128#设置最大连接数,0为不限制

maxmemory #内存清理策略,如果达到此值,将采取以下动作:

# volatile-lru :默认策略,只对设置过期时间的key进行LRU算法删除

# allkeys-lru :删除不经常使用的key

# volatile-random :随机删除即将过期的key

# allkeys-random :随机删除一个key

# volatile-ttl :删除即将过期的key

# noeviction :不过期,写操作返回报错

maxmemory-policy volatile-lru#如果达到maxmemory值,采用此策略

maxmemory-samples 3   #默认随机选择3个key,从中淘汰最不经常用的

6、附加模式

appendonly no    #AOF持久化,是否记录更新操作日志,默认redis是异步(快照)把数据写入本地磁盘

appendfilename appendonly.aof  #指定更新日志文件名

# AOF持久化三种同步策略:

# appendfsync always #每次有数据发生变化时都会写入appendonly.aof

# appendfsync everysec #默认方式,每秒同步一次到appendonly.aof

# appendfsync no #不同步,数据不会持久化

no-appendfsync-on-rewrite no   #当AOF日志文件即将增长到指定百分比时,redis通过调用BGREWRITEAOF是否自动重写AOF日志文件。

7、虚拟内存

vm-enabled no      #是否启用虚拟内存机制,虚拟内存机将数据分页存放,把很少访问的页放到swap上,内存占用多,最好关闭虚拟内存

vm-swap-file /var/lib/redis/redis.swap   #虚拟内存文件位置

vm-max-memory 0    #redis使用的最大内存上限,保护redis不会因过多使用物理内存影响性能

vm-page-size 32    #每个页面的大小为32字节

vm-pages 134217728  #设置swap文件中页面数量

vm-max-threads 4    #访问swap文件的线程数

8、高级配置

hash-max-zipmap-entries 512   #哈希表中元素(条目)总个数不超过设定数量时,采用线性紧凑格式存储来节省空间

hash-max-zipmap-value 64     #哈希表中每个value的长度不超过多少字节时,采用线性紧凑格式存储来节省空间

list-max-ziplist-entries 512  #list数据类型多少节点以下会采用去指针的紧凑存储格式

list-max-ziplist-value 64    #list数据类型节点值大小小于多少字节会采用紧凑存储格式

set-max-intset-entries 512   #set数据类型内部数据如果全部是数值型,且包含多少节点以下会采用紧凑格式存储

activerehashing yes        #是否激活重置哈希

Redis-Sentinel配置

1、基础配置

1.1、port 26379

 sentinel监听端口,默认是26379,可以修改。

1.2、sentinel monitor mymaster 127.0.0.1 6379 2

告诉sentinel去监听地址为ip:port的一个master,这里的master-name可以自定义,quorum是一个数字,指明当有多少个sentinel认为一个master失效时,master才算真正失效。master-name只能包含英文字母,数字,和“.-_”这三个字符需要注意的是master-ip 要写真实的ip地址而不要用回环地址(127.0.0.1)。

sentinel monitor <master-name> <ip> <redis-port> <quorum>

1.3、sentinel auth-pass mymaster 123456

设置连接master和slave时的密码,注意的是sentinel不能分别为master和slave设置不同的密码,因此master和slave的密码应该设置相同。

sentinel auth-pass <master-name> <password>

1.4、sentinel down-after-milliseconds mymaster 30000

这个配置项指定了需要多少失效时间,一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒,默认为30秒

sentinel down-after-milliseconds <master-name> <milliseconds>


1.5、sentinel parallel-syncs mymaster 1

这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步,这个数字越小,完成failover所需的时间就越长,但是如果这个数字越大,就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。

sentinel parallel-syncs <master-name> <numslaves>

1.6、sentinel failover-timeout mymaster1 20000

  failover-timeout 可以用在以下这些方面: 

      1. 同一个sentinel对同一个master两次failover之间的间隔时间。

      2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。

      3.当想要取消一个正在进行的failover所需要的时间。  

      4.当进行failover时,配置所有slaves指向新的master所需的最大时间。不过,即使过了这个超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了。

sentinel failover-timeout <master-name> <milliseconds>

2、高级设置

sentinel的notification-script和reconfig-script是用来配置当某一事件发生时所需要执行的脚本,可以通过脚本来通知管理员,例如当系统运行不正常时发邮件通知相关人员。对于脚本的运行结果有以下规则:

        若脚本执行后返回1,那么该脚本稍后将会被再次执行,重复次数目前默认为10

        若脚本执行后返回2,或者比2更高的一个返回值,脚本将不会重复执行。

        如果脚本在执行过程中由于收到系统中断信号被终止了,则同返回值为1时的行为相同。

        一个脚本的最大执行时间为60s,如果超过这个时间,脚本将会被一个SIGKILL信号终止,之后重新执行。

2.1、sentinel notification-script mymaster /var/redis/notify.sh

通知型脚本:当sentinel有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等),将会去调用这个脚本,这时这个脚本应该通过邮件,SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时,将传给脚本两个参数,一个是事件的类型,一个是事件的描述。如果sentinel.conf配置文件中配置了这个脚本路径,那么必须保证这个脚本存在于这个路径,并且是可执行的,否则sentinel无法正常启动成功。

sentinel notification-script <master-name> <script-path>

2.2、sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

 当一个master由于failover而发生改变时,这个脚本将会被调用,通知相关的客户端关于master地址已经发生改变的信息。以下参数将会在调用脚本时传给脚本:

<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>

目前state总是“failover”, role是“leader”或者“observer”中的一个。 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的。这个脚本应该是通用的,能被多次调用,不是针对性的。

sentinel client-reconfig-script <master-name> <script-path>