# Protected mode
is a layer of security protection, in order to avoid that
# Redis instances left open on the internet are accessed and exploited.
#
# When
protected mode is on and if:
#
#
1) The server is not binding explicitly to a set of addresses using the
#
"bind" directive.
#
2) No password is configured.
#
# The server only accepts connections
from clients connecting from the
# IPv4 and IPv6 loopback addresses
127.0.0.1 and ::1, and from Unix domain
# sockets.
#
# By
default protected mode is enabled. You should disable it only if
# you are sure you want clients
from other hosts to connect to Redis
# even
if no authentication is configured, nor a specific set of interfaces
# are explicitly listed
using the "bind" directive.
protected-mode no //yes该为no
# Accept connections on the specified port,
default is 6379 (IANA #815344).
# If port
0 is specified Redis will not listen on a TCP socket.
port
6379
# TCP listen() backlog.
#
# In high requests
-per-second environments you need an high backlog in order
# to avoid slow clients connections issues. Note that the Linux kernel
# will silently truncate it to the value of
/proc/sys/net/core/somaxconn so
# make sure to raise both the value of somaxconn and tcp_max_syn_backlog
#
in order to get the desired effect.
tcp
-backlog 511
# Unix socket.
#
# Specify the path
for the Unix socket that will be used to listen for
# incoming connections. There
is no default, so Redis will not listen
# on a unix socket when not specified.
#
# unixsocket
/tmp/redis.sock
# unixsocketperm
700
# Close the connection after a client
is>
timeout 0
# TCP keepalive.
#
# If non
-zero, use SO_KEEPALIVE to send TCP ACKs to clients in absence
# of communication. This
is useful for two reasons:
#
#
1) Detect dead peers.
#
2) Take the connection alive from the point of view of network
# equipment
in the middle.
#
# On Linux, the specified value (
in seconds) is the period used to send ACKs.
# Note that to close the connection the
double of the time is needed.
# On other kernels the period depends on the kernel configuration.
#
# A reasonable value
for this option is 300 seconds, which is the new
# Redis
default starting with Redis 3.2.1.
tcp
-keepalive 300
################################ REDIS CLUSTER ###############################
#
#
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# WARNING EXPERIMENTAL: Redis Cluster
is considered to be stable code, however
#
in order to mark it as "mature" we need to wait for a non trivial percentage
# of users to deploy it
in production.
#
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#
# Normal Redis instances can
't be part of a Redis Cluster; only nodes that are
# started as cluster nodes can. In order to start a Redis instance as a
# cluster node enable the cluster support uncommenting the following:
#
cluster-enabled yes
# Every cluster node has a cluster configuration file. This file is not
# intended to be edited by hand. It is created and updated by Redis nodes.
# Every Redis Cluster node requires a different cluster configuration file.
# Make sure that instances running in the same system do not have
# overlapping cluster configuration file names.
#
cluster-config-file nodes-6379.conf
# Cluster node timeout is the amount of milliseconds a node must be unreachable
# for it to be considered in failure state.
# Most other internal time limits are multiple of the node timeout.
#
# cluster-node-timeout 15000
# A slave of a failing master will avoid to start a failover if its data
# looks too old.
#
# There is no simple way for a slave to actually have an exact measure of
# its "data age", so the following two checks are performed:
#
# 1) If there are multiple slaves able to failover, they exchange messages
# in order to try to give an advantage to the slave with the best
# replication offset (more data from the master processed).
# Slaves will try to get their rank by offset, and apply to the start
# of the failover a delay proportional to their rank.
#
# 2) Every single slave computes the time of the last interaction with
# its master. This can be the last ping or command received (if the master
# is still in the "connected" state), or the time that elapsed since the
# disconnection with the master (if the replication link is currently down).
# If the last interaction is too old, the slave will not try to failover
# at all.
#
# The point "2" can be tuned by user. Specifically a slave will not perform
# the failover if, since the last interaction with the master, the time