简介

Redis作为一个开源的key-value存储系统，目前已经使用在很多大型系统中。作为key-value存储系统的代表，同时也经受过千万级应用的检验，它的强大性、易用性、安全性都不言而喻。而我们在进行key-value存储系统选型时，很多时候都会默认把Redis作为默认的备选对象。所以，Redis就变的越来越重要，基本上是运维人员、开发人员的必备技能。而我这里总结的这篇文章主要面向的是运维人员，目的是告诉大家搭建Redis、如何配置Redis，希望通过我的这篇文章，你能掌握以下技能：

• Redis的搭建
• Redis的配置

好了，开始Redis的学习之旅。（注：以下操作均在CentOS Linux release 7.3下完成）

单机版安装

我们先从单机版安装开始，因为我们在搭建开发环境时，都是安装的单机版，所以单机版的安装是运维人员、开发人员必备的技能。

安装单机版主要分为以下几步：

1. 下载源码
   打开https://redis.io/download网站，下载Redis最新稳定版源码。

    

2. 上传至服务器，解压缩、编译

   # 解压缩
   tar -xzf redis-4.0.10.tar.gz 
   
   # 进入Redis源码目录
   cd redis-4.0.10
   
   # 编译
   make
   
   # 测试编译结果
   make test

3. 到这里，Redis已经编译完成，我们就可以使用单机版的，通过以下命令启动Redis：

   # 编译生成的可执行文件都在src目录下
   cd src
   
   #指定配置文件运行redis
   ./redis-server ../redis.conf

4. 使用自带的redis-cli客户端连接redis-server进行测试：

   ./redis-cli -h 127.0.0.1 -p 6379

到此关于Redis的单机版安装就结束了。单机版安装是非常简单的，只需要按照官网说明进行执行即可。

Redis主从模式配置

在实际生产环境下，Redis基本上是不可能部署单节点的，而是通过部署Redis集群实现Redis的高可用，从而保障实际生产业务的正常运行。

说到集群安装，那就需要先来说说Redis简单的主从配置。在一些简单的，小型应用中，我们可能会看到这样的Redis部署架构：

如上图所示，也就是所谓的一主多从。主机和从机的数据完全一致，主机支持数据的写入和读取等各项操作，而从机则只支持与主机数据的同步和读取，也就是说，客户端可以将数据写入到主机，由主机自动将数据的写入操作同步到从机。主从模式很好的解决了数据备份问题，并且由于主从服务数据几乎是一致的，因而可以将写入数据的命令发送给主机执行，而读取数据的命令发送给不同的从机执行，从而达到读写分离的目的。下面我部署一个一主三从的例子。

我们都知道每个Redis实例都是一个单独的进程，都会有一个对应的进程。为了搭建一主三从这个例子，我准备以下三个配置文件：

角色	配置文件	监听端口
主	redis-6379.conf	6379
从	redis-6380.conf	6380
从	redis-6381.conf	6381
从	redis-6382.conf	6382

redis-6379.conf配置文件内容如下：

bind 127.0.0.1
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"

redis-6380.conf配置文件内容如下：

bind 127.0.0.1
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 127.0.0.1 6379

redis-6381.conf配置文件内容如下：

bind 127.0.0.1
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 127.0.0.1 6379

redis-6382.conf配置文件内容如下：

bind 127.0.0.1
port 6382
daemonize yes
logfile "6382.log"
dbfilename "dump-6382.rdb"
slaveof 127.0.0.1 6379

接下来使用以下命令启动Redis：

./redis-server ../redis-6379.conf 
./redis-server ../redis-6380.conf 
./redis-server ../redis-6381.conf
./redis-server ../redis-6382.conf

然后使用redis-cli命令连接Redis实例：

./redis-cli -h 127.0.0.1 -p 6379
./redis-cli -h 127.0.0.1 -p 6380
./redis-cli -h 127.0.0.1 -p 6381
./redis-cli -h 127.0.0.1 -p 6382

分别在三个命令行工具中执行一个get命令，获取键名为website的数据，如下所示：

127.0.0.1:6379> get website
(nil)

127.0.0.1:6380> get website
(nil)

127.0.0.1:6381> get website
(nil)

127.0.0.1:6381> get website
(nil)

可以看到，在三个redis实例中都不存在键为msg的数据，现在我们在主机6379上设置一个键为website的数据，如下所示：

127.0.0.1:6379> set website https://www.jellythink.com
OK
127.0.0.1:6379> get website
"https://www.jellythink.com"

可以看到设置成功了，此时我们在6380、6381和6382的实例上执行get website的命令，如下所示：

127.0.0.1:6380> get website
"https://www.jellythink.com"

127.0.0.1:6381> get website
"https://www.jellythink.com"

127.0.0.1:6381> get website
"https://www.jellythink.com"

可以看到，虽然我们只是在6379的实例上设置了website这条数据，但是在6380、6381和6382的实例上也有了相应的数据，说明我们成功配置了redis的主从模式。

Redis sentinel哨兵配置

通过上面配置的最简单的主从模式，我们可以实现读写分离，解决了数据备份和单例可能存在的性能问题，但是也引入了新的问题。由于主从模式配置了四个redis实例，并且每个实例都使用不同的ip（如果在不同的机器上）和端口号，根据前面所述，主从模式下可以将读写操作分配给不同的实例进行从而达到提高系统吞吐量的目的，但也正是因为这种方式造成了使用上的不便，因为每个客户端连接redis实例的时候都是指定了ip和端口号的，如果所连接的redis实例因为故障下线了，而主从模式也没有提供一定的手段通知客户端另外可连接的客户端地址，因而需要手动更改客户端配置重新连接。另外，主从模式下，如果主节点由于故障下线了，那么从节点因为没有主节点而同步中断，因而需要人工进行故障转移工作。

为了解决上面的这个不能自动进行故障转移的问题，在2.8版本之后redis正式提供了sentinel（哨兵）架构。

Sentinel（哨兵）是Redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

Redis的Sentinel系统用于管理多个Redis服务器(instance) 该系统执行以下三个任务：

• 监控(Monitoring): Sentinel会不断地定期检查主服务器和从服务器是否运作正常
• 提醒(Notification): 当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知
• 自动故障迁移(Automaticfailover): 当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器

当然了Redis sentinel的哨兵机制是一个非常复杂的机制，如果做更多的了解，推荐阅读《redis-Sentinel配置》和《Redis 高可用架构最佳实践》这两篇文章。我这里重点说说如何配置。

先根据上一节内容做好Redis主从模式配置。再看看sentienl规划：

角色	配置文件	监听端口
sentienl	sentinel-26379.conf	26379
sentienl	sentinel-26380.conf	26380
sentienl	sentinel-26381.conf	26381

建议哨兵至少部署3个，并且使用奇数个哨兵。Redis Sentinel的节点数量要满足2n+1（n>=1）的奇数个。

sentinel-26379.conf配置文件如下：

port 26379
bind 127.0.0.1
daemonize yes
dir /home/jelly/redis/data/sentinel-26379
logfile "/home/jelly/redis/data/sentinel-26379/sentinel.log"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

sentinel-26380.conf配置文件如下：

port 26380
bind 127.0.0.1
daemonize yes
dir /home/jelly/redis/data/sentinel-26380
logfile "/home/jelly/redis/data/sentinel-26380/sentinel.log"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

sentinel-26381.conf配置文件如下：

port 26381
bind 127.0.0.1
daemonize yes
dir /home/jelly/redis/data/sentinel-26381
logfile "/home/jelly/redis/data/sentinel-26381/sentinel.log"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

上述主要配置说明如下：

• sentinel monitor mymaster 127.0.0.1 6379 2
  表示sentinel监控的master的名字叫做mymaster，监控的的master地址为127.0.0.1，端口号为6379；行尾最后的2表示当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了
• sentinel down-after-milliseconds mymaster 30000
  表示master在多少毫秒内无反应，哨兵会开始进行master-slave间的切换，使用“选举”机制
• sentinel parallel-syncs mymaster 1
  在发生failover主备切换时，这个选项指定了最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态
• sentinel failover-timeout mymaster 180000
  • 同一个sentinel对同一个master两次failover之间的间隔时间
  • 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时所对应的最大时间
  • 当想要取消一个正在进行的failover所需要的时间
  • 当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了

接下来就是启动Redis和Redis sentinel了。启动顺序如下：

Redis Master -> Redis Slave -> Redis Sentinel

关于Redis Master和Redis Slave的启动命令上一节已经说了，这里说一下Redis Sentinel的启动命令：

./redis-sentinel ../sentinel-26379.conf
./redis-sentinel ../sentinel-26380.conf
./redis-sentinel ../sentinel-26381.conf

启动成功后，我们可以通过redis-cli命令来连接sentinel，从而完成管理。

./redis-cli -h 127.0.0.1 -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=3,sentinels=3

目前我们已经搭建好了Redis sentinel哨兵以及Redis Master-Slave。现在我们就可以通过关闭Master来模拟Master故障，从而检测Redis sentinel哨兵。

./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> shutdown

接下来，我们再连接sentinel，检查sentinel信息：

./redis-cli -h 127.0.0.1 -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6380,slaves=3,sentinels=3

我们可以看到Master变成了127.0.0.1:6380。这个时候，Master-Slave信息如下：

127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6381,state=online,offset=858977,lag=1
slave1:ip=127.0.0.1,port=6382,state=online,offset=858977,lag=1
master_replid:94cd21d5f654f52f56e4de4d729e215a3dab16d0
master_replid2:8c589ce46bc707d0d062ba4e035ce55c84faf67d
master_repl_offset:859110
second_repl_offset:841553
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:859110

很明显的，一主两备。

接下来，我们再将127.0.0.1:6379启动。

./redis-server ../redis-6379.conf

# 此时，准备信息又发生了变化
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:3
slave0:ip=127.0.0.1,port=6381,state=online,offset=889947,lag=0
slave1:ip=127.0.0.1,port=6382,state=online,offset=889548,lag=1
slave2:ip=127.0.0.1,port=6379,state=online,offset=889681,lag=1
master_replid:94cd21d5f654f52f56e4de4d729e215a3dab16d0
master_replid2:8c589ce46bc707d0d062ba4e035ce55c84faf67d
master_repl_offset:889947
second_repl_offset:841553
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:889947

再次变成了一主三备。

Redis cluster集群配置

Redis Cluster是一种服务器Sharding技术，3.0版本开始正式提供。Redis Cluster并没有使用一致性hash，而是采用slot(槽)的概念，一共分成16384个槽。将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。当客户端操作的key没有分配到该node上时，就像操作单一Redis实例一样，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这有点儿像浏览器页面的302 redirect跳转。

Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务，具有以下特点：

• 无中心架构，支持动态扩容，对业务透明
• 具备Sentinel的监控和自动Failover能力
• 客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
• 高性能，客户端直连redis服务，免去了proxy代理的损耗

缺点是运维也很复杂，数据迁移需要人工干预，只能使用0号数据库，不支持批量操作，分布式逻辑和存储模块耦合等。

由于Redis cluster是redis官方提供的，目前官方一直都在维护中，具有代表性，建议生产使用。目前我们的生产环境的Redis就是使用的Redis cluster，已经经历过百万次调用的考验。

官方推荐集群至少需要六个节点，即三主三从。六个节点的配置文件基本相同，只需要修改端口号。Redis cluster规划如下：

角色	配置文件	监听端口
主	cluster-6383.conf	6383
主	cluster-6384.conf	6384
主	cluster-6385.conf	6385
备	cluster-6386.conf	6386
备	cluster-6387.conf	6387
备	cluster-6388.conf	6388

配置文件内容如下（只是端口号不同）：

port 6383
bind 127.0.0.1
daemonize yes
cluster-enabled yes
cluster-config-file nodes_6383.conf
cluster-node-timeout 15000

现在，先使用redis-server命令将6个Redis节点启动。然后使用Redis官方提供的redis-trib.rb这个工具创建集群，比如这样：

./redis-trib.rb create --replicas 1 127.0.0.1:6383 127.0.0.1:6384 127.0.0.1:6385 127.0.0.1:6386 127.0.0.1:6387 127.0.0.1:6388

在任意一台Redis节点上运行，不要在每台机器上都运行，一台就够了

但是要运行redis-trib.rb命令，我们的主机还是要安装一些软件的。而在一台新的机器上离线安装这些软件，会让你非常难受，下面就来说说如何离线安装这些软件：

1. 离线安装ruby
   可以在这里下载ruby源码。编译源码，然后进行安装：

    

   # 解压源码包
   tar -xzvf ruby-2.5.1.tar.gz
   cd ruby-2.5.1
   
   # 生成编译配置
   ./configure --prefix=/home/jelly/ruby
   
   # 编译并安装
   make && make install
   
   # 配置环境变量
   PATH=$PATH:/home/jelly/ruby/bin
   
   # 测试
   ruby -v

2. 离线安装zlib
   可以在这里下载zlib源码。编译源码，然后进行安装：

    

   # 解压缩源码
   tar -xzvf zlib-1.2.11.tar.gz
   cd zlib-1.2.11
   
   # 生成编译配置
   ./configure --prefix=/home/jelly/zlib
   
   # 编译并安装
   make && make install

3. 离线安装rubygems
   可以在这里下载rubygems源码。编译源码，然后进行安装：

    

   # 编译ruby中的zlib
   cd /home/jelly/ruby-2.5.1/ext/zlib
   ruby extconf.rb --with-zlib-include=/home/jelly/zlib/include/ --with-zlib-lib=/home/jelly/zlib/lib
   
   # 解压源码包
   tar -xzvf rubygems-2.7.7.tgz
   cd rubygems-2.7.7
   
   # 执行安装脚本，在这个过程中可能需要安装zlib
   ruby setup.rb
   
   # 验证gem是否可以使用
   gem -v

4. 安装rubygems的redis api
   可以在这里下载rubygems的redis api。然后进行安装：

    

   gem install -l redis-4.0.1.gem
   gem list redis

此时再执行以下命令就可以执行成功：

# 创建集群
./redis-trib.rb create --replicas 1 127.0.0.1:6383 127.0.0.1:6384 127.0.0.1:6385 127.0.0.1:6386 127.0.0.1:6387 127.0.0.1:6388

# 查看集群信息
127.0.0.1:6383> cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:1
cluster_stats_messages_ping_sent:717
cluster_stats_messages_pong_sent:250
cluster_stats_messages_sent:967
cluster_stats_messages_ping_received:250
cluster_stats_messages_pong_received:221
cluster_stats_messages_received:471

# 查看集群当前节点信息
127.0.0.1:6383> cluster nodes
97ec5f3606ef995f952ffa17f05a4b1e70dbc392 127.0.0.1:6383@16383 myself,master - 0 1531145554000 1 connected 0-5460
1bddffff033ccf2182b3937e2d5f8af257d97416 127.0.0.1:6388@16388 slave 85162c300cf1701ff7ab5ef2bb14b9e5d7a9fc9c 0 1531145554000 6 connected
85162c300cf1701ff7ab5ef2bb14b9e5d7a9fc9c 127.0.0.1:6384@16384 master - 0 1531145555880 2 connected 5461-10922
c7b6fef3312033ede2993fcb0b0acabe3f6b9d78 127.0.0.1:6386@16386 slave 6edac8e90957060ef176cf5ac627f9f68bac054e 0 1531145554874 4 connected
3865043ff47b60ddd099c93741d76abda3be9ecc 127.0.0.1:6387@16387 slave 97ec5f3606ef995f952ffa17f05a4b1e70dbc392 0 1531145555000 5 connected
6edac8e90957060ef176cf5ac627f9f68bac054e 127.0.0.1:6385@16385 master - 0 1531145553000 3 connected 10923-16383

# 查看集群状态信息
./redis-trib.rb check 127.0.0.1:6383
>>> Performing Cluster Check (using node 127.0.0.1:6383)
M: 97ec5f3606ef995f952ffa17f05a4b1e70dbc392 127.0.0.1:6383
   slots:0-5460 (5461 slots) master
   1 additional replica(s)
S: 1bddffff033ccf2182b3937e2d5f8af257d97416 127.0.0.1:6388
   slots: (0 slots) slave
   replicates 85162c300cf1701ff7ab5ef2bb14b9e5d7a9fc9c
M: 85162c300cf1701ff7ab5ef2bb14b9e5d7a9fc9c 127.0.0.1:6384
   slots:5461-10922 (5462 slots) master
   1 additional replica(s)
S: c7b6fef3312033ede2993fcb0b0acabe3f6b9d78 127.0.0.1:6386
   slots: (0 slots) slave
   replicates 6edac8e90957060ef176cf5ac627f9f68bac054e
S: 3865043ff47b60ddd099c93741d76abda3be9ecc 127.0.0.1:6387
   slots: (0 slots) slave
   replicates 97ec5f3606ef995f952ffa17f05a4b1e70dbc392
M: 6edac8e90957060ef176cf5ac627f9f68bac054e 127.0.0.1:6385
   slots:10923-16383 (5461 slots) master
   1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

到此，关于redis cluster如何搭建就到此总结完毕。

Redis配置

关于Redis配置文件，这里需要分为两部分来说明，因为在Redis的安装包中，有以下两个配置文件的示例文件：

• sentinel.conf
• redis.conf

sentinel.conf配置文件说明

# sentinel实例进程监听端口，sentinel之间的通讯端口
port 26379

# sentinel的工作目录，定义一个合理的工作目录
dir /tmp

# sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字，只能由字母A-z、数字0-9 、这三个字符".-_"组成
# quorum 将这个主实例判断为失效至少需要quorum个Sentinel进程的同意，只要同意Sentinel的数量不达标，自动failover就不会执行
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

# 当在Redis实例中开启了requirepass foobared授权密码，这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel连接主从的密码
# 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
# sentinel auth-pass mymaster MySUPER--secret-0123passw0rd

# 指定多少毫秒之后，主节点没有应答哨兵sentinel；此时哨兵主观上认为主节点下线
# 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000

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

# 故障转移的超时时间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>
sentinel failover-timeout mymaster 180000

# SCRIPTS EXECUTION
# 配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发短信通知相关人员。
# 对于脚本的运行结果有以下规则：
# 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
# 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行
# 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同
# 一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行

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

# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是“failover”
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的
# sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

redis.conf配置文件说明

################################## 引用设置 ###################################

# 不同redis server可以使用同一个模版配置作为主配置，并引用其它配置文件用于本server的个性化设置
# include并不会被CONFIG REWRITE命令覆盖。但是主配置文件的选项会被覆盖。
# 想故意覆盖主配置的话就把include放文件前面，否则最好放末尾
# include /path/to/local.conf
# include /path/to/other.conf

################################## 网络设置 ###################################

# 不指定bind的话redis将会监听所有网络接口。这个配置是肯定需要指定的
# 下面这个配置是只允许本地客户端访问
bind 127.0.0.1

# 是否开启保护模式。默认开启，如果没有设置bind项的ip和redis密码的话，服务将只允许本地访问
protected-mode yes

# 端口设置，默认为 6379 
# 如果port设置为0 redis将不会监听tcp socket
port 6379

# 在高并发环境下需要一个高backlog值来避免慢客户端连接问题。注意Linux内核默默将这个值减小到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和tcp_max_syn_backlog 两个值来达到需要的效果。
tcp-backlog 511

# 指定用来监听Unix套接字的路径。没有默认值，没有指定的情况下Redis不会监听Unix socket
# unixsocket /tmp/redis.sock
# unixsocketperm 700

# 当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
timeout 0

# tcp-keepalive设置。
# 如果非零，则设置SO_KEEPALIVE选项来向空闲连接的客户端发送ACK，用途如下：
# （1）能够检测无响应的对端
# （2）让该连接中间的网络设备知道这个连接还存活
# 在Linux上，这个指定的值(单位秒)就是发送ACK的时间间隔
# 注意：要关闭这个连接需要两倍的这个时间值
tcp-keepalive 300

################################# 通用设置 #####################################

# daemonize no 默认情况下，redis不是在后台运行的，如果需要在后台运行，把该项的值更改为yes
daemonize no

# pid文件在redis启动时创建，退出时删除。当Redis没有以守护进程的方式运行，这个pid文件的配置选项不会起作用
pidfile /var/run/redis_6379.pid

# 配置日志级别。选项有debug, verbose, notice, warning
loglevel notice

# 日志名称。空字符串表示标准输出。注意如果redis配置为后台进程，标准输出中信息会发送到/dev/null
logfile ""

# 当配置为yes时，Redis的日志会输出到系统日志
# syslog-enabled no

# 指定系统日志身份。
# syslog-ident redis

# 指定syslog设备。必须是user或LOCAL0 ~ LOCAL7之一
# syslog-facility local0

# 设置数据库个数。默认数据库是DB 0
databases 16

# 是否输出Redis logo
always-show-logo yes

################################ 备份设置  ################################
#
# 下面的例子将会进行把数据写入磁盘的操作：
# 900秒（15分钟）之后，且至少1次变更
# 300秒（5分钟）之后，且至少10次变更
# 60秒之后，且至少10000次变更
# 不写磁盘的话就把所有 "save" 设置注释掉就行了
# 通过添加一条带空字符串参数的save指令也能移除之前所有配置的save指令，如: save ""
save 900 1
save 300 10
save 60 10000

# 默认情况下如果上面配置的RDB模式开启且最后一次的保存失败，redis将停止接受写操作，让用户知道问题的发生
# 如果后台保存进程重新启动工作了，redis也将自动的允许写操作。如果有其它监控方式也可关闭
stop-writes-on-bgsave-error yes

# 是否在备份.rdb文件时是否用LZF压缩字符串，默认设置为yes。如果想节约cpu资源可以把它设置为no
rdbcompression yes

# 因为版本5的RDB有一个CRC64算法的校验和放在了文件的末尾。这将使文件格式更加可靠
# 但在生产和加载RDB文件时，这有一个性能消耗(大约10%)，可以关掉它来获取最好的性能
# 生成的关闭校验的RDB文件有一个0的校验和，它将告诉加载代码跳过检查
rdbchecksum yes

# rdb文件名称
dbfilename dump.rdb

# 备份文件目录，文件名就是上面的 "dbfilename" 的值。累加文件也放这里
# 注意你这里指定的必须是目录，不是文件名
dir ./

################################# 主从同步 #################################

# 主从同步配置
#
# 1) redis主从同步是异步的，但是可以配置在没有指定slave连接的情况下使master停止写入数据
# 2) 连接中断一定时间内，slave可以执行部分数据重新同步
# 3) 同步是自动的，slave可以自动重连且同步数据
# slaveof <masterip> <masterport>

# master连接密码
# masterauth <master-password>

# 当一个slave失去和master的连接，或者同步正在进行中，slave的行为有两种可能：
# 1) 如果 slave-serve-stale-data 设置为 "yes" (默认值)，slave会继续响应客户端请求，可能是正常数据，也可能是还没获得值的空数据
# 2) 如果 slave-serve-stale-data 设置为 "no"，slave会回复"正在从master同步（SYNC with master in progress）"来处理各种请求，除了INFO和SLAVEOF命令
slave-serve-stale-data yes

# 配置salve实例是否接受写操作。可写的slave实例可能对存储临时数据比较有用(因为写入salve的数据在同master同步之后将很容被删除)，但是如果客户端由于配置错误在写入时也可能产生一些问题
# 从Redis2.6默认所有的slave为只读
slave-read-only yes

# 复制同步策略：disk或socket
# -------------------------------------------------------
# 警告：无磁盘的复制当前还处于试验阶段
# -------------------------------------------------------
repl-diskless-sync no

# 如果非磁盘同步方式开启，可以配置同步延迟时间，以等待master产生子进程通过socket传输RDB数据给slave
# 默认值为5秒，设置为0秒则每次传输无延迟
repl-diskless-sync-delay 5

# slave根据指定的时间间隔向master发送ping请求。默认10秒
# repl-ping-slave-period 10

# 同步的超时时间设置：
# 1) slave在与master SYNC期间有大量数据传输，造成超时
# 2) 在slave角度，master超时，包括数据、ping等
# 3) 在master角度，slave超时，当master发送REPLCONF ACK ping
#
# 确保这个值大于指定的repl-ping-slave-period，否则在主从间流量不高时每次都会检测到超时
# repl-timeout 60

# 是否在slave套接字发送SYNC之后禁用 TCP_NODELAY
#
# 如果选择yes，Redis将使用更少的TCP包和带宽来向slaves发送数据。但是这将使数据传输到slave上有延迟，Linux内核的默认配置会达到40毫秒
# 如果选择no，数据传输到salve的延迟将会减少但要使用更多的带宽
#
# 默认我们会为低延迟做优化，但高流量情况或主从之间的跳数过多时，可以设置为“yes”
repl-disable-tcp-nodelay no

# 设置数据备份的backlog大小。backlog是一个slave在一段时间内断开连接时记录salve数据的缓冲，所以一个slave在重新连接时，不必要全量的同步，而是一个增量同步就足够了，将在断开连接的这段# 时间内把slave丢失的部分数据传送给它
# 同步的backlog越大，slave能够进行增量同步并且允许断开连接的时间就越长
# backlog只分配一次并且至少需要一个slave连接
# repl-backlog-size 1mb

# 当master在一段时间内不再与任何slave连接，backlog将会释放。以下选项配置了从最后一个slave断开开始计时多少秒后，backlog缓冲将会释放
# 0表示永不释放backlog
# repl-backlog-ttl 3600

# slave的优先级是一个整数展示在Redis的Info输出中。如果master不再正常工作了，sentinel将用它来选择一个slave提升为master
# 优先级数字小的salve会优先考虑提升为master，所以例如有三个slave优先级分别为10，100，25，sentinel将挑选优先级最小数字为10的slave
# 0作为一个特殊的优先级，标识这个slave不能作为master，所以一个优先级为0的slave永远不会被sentinel挑选提升为master
# 默认优先级为100
slave-priority 100

################################## 安全设置 ###################################

# 要求客户端在处理任何命令时都要验证身份和密码
# requirepass foobared

################################### 限制 ####################################

# 设置能连上redis的最大客户端连接数量。默认是10000个客户端连接。由于redis不区分连接是客户端连接还是内部打开文件或者和slave连接等，所以maxclients最小建议设置到32。
# 如果超过了maxclients，redis会给新的连接发送’max number of clients reached’，并关闭连接。
# maxclients 10000

############################## 内存管理 ################################

# redis配置的最大内存容量。当内存满了，需要配合maxmemory-policy策略进行处理。注意slave的输出缓冲区是不计算在maxmemory内的。所以为了防止主机内存使用完，建议设置的maxmemory需要更小一些
# maxmemory <bytes>

# 内存容量超过maxmemory后的处理策略：
# volatile-lru：利用LRU算法移除设置过过期时间的key
# volatile-random：随机移除设置过过期时间的key
# volatile-ttl：移除即将过期的key，根据最近过期时间来删除
# allkeys-lru：利用LRU算法移除任何key
# allkeys-random：随机移除任何key
# noeviction：不移除任何key，只是返回一个写错误
# 上面的这些驱逐策略，如果redis没有合适的key驱逐，对于写命令，还是会返回错误。redis将不再接收写请求，只接收get请求
# maxmemory-policy noeviction

# lru检测的样本数。使用lru或者ttl淘汰算法，从需要淘汰的列表中随机选择sample个key，选出闲置时间最长的key移除
# maxmemory-samples 5

############################## 追加模式 ###############################

# 默认情况下，Redis是异步的把数据导出到磁盘上。这种模式在很多应用里已经足够好，但Redis进程出问题或断电时可能造成一段时间的写操作丢失(这取决于配置的save指令)
# 默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。但是redis如果中途宕机，会导致可能有几分钟的数据丢失
# Append Only File是另一种持久化方式，可以提供更好的持久化特性。Redis会把每次写入的数据在接收后都写入appendonly.aof文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件
appendonly no

# aof文件名
appendfilename "appendonly.aof"

# aof持久化策略的配置
# no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快
# always表示每次写入都执行fsync，以保证数据同步到磁盘
# everysec表示每秒执行一次fsync，可能会导致丢失这1s数据
appendfsync everysec

# 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no
# 如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择
# 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据
no-appendfsync-on-rewrite no

# aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写
# 当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100

# 设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写
auto-aof-rewrite-min-size 64mb

# aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项（redis宕机或者异常终止不会造成尾部不完整现象）出现这种现象，可以选择让redis退出，或者导入尽可能多的数据
# 如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。
aof-load-truncated yes

################################ LUA脚本配置  ###############################

# 如果达到最大时间限制（毫秒），redis会记个log，然后返回error。当一个脚本超过了最大时限。只有SCRIPT KILL和SHUTDOWN NOSAVE可以用。第一个可以杀没有调write命令的东西。要是已经调用了write，只能用第二个命令杀
lua-time-limit 5000

################################ 集群  ###############################
#
# 集群开关，默认是不开启集群模式
# cluster-enabled yes

# 集群配置文件的名称，每个节点都有一个集群相关的配置文件，持久化保存集群的信息。这个文件并不需要手动配置，这个配置文件由Redis生成并更新，每个Redis集群节点需要一个单独的配置文件，请确保与实例运行的系统中配置文件名称不冲突
# cluster-config-file nodes-6379.conf

# 节点互连超时的阀值。集群节点超时毫秒数
# cluster-node-timeout 15000

# 在进行故障转移的时候，全部slave都会请求申请为master，但是有些slave可能与master断开连接一段时间了，导致数据过于陈旧，这样的slave不应该被提升为master。该参数就是用来判>断slave节点与master断线的时间是否过长。判断方法是：
# 比较slave断开连接的时间和(node-timeout * slave-validity-factor) + repl-ping-slave-period
# 如果节点超时时间为三十秒, 并且slave-validity-factor为10,假设默认的repl-ping-slave-period是10秒，即如果超过310秒slave将不会尝试进行故障转移 
# 可能出现由于某主节点失联却没有从节点能顶上的情况，从而导致集群不能正常工作，在这种情况下，只有等到原来的主节点重新回归到集群，集群才恢复运作
# 如果设置成0，则无论从节点与主节点失联多久，从节点都会尝试升级成主节
# cluster-slave-validity-factor 10

# master的slave数量大于该值，slave才能迁移到其他孤立master上，如这个参数若被设为2，那么只有当一个主节点拥有2 个可工作的从节点时，它的一个从节点会尝试迁移。
# 主节点需要的最小从节点数，只有达到这个数，主节点失败时，它从节点才会进行迁移。
# cluster-migration-barrier 1

# 默认情况下如果redis集群如果检测到至少有1个hash slot不可用，集群将停止查询数据
# 如果所有slot恢复则集群自动恢复
# 如果需要集群部分可用情况下仍可提供查询服务，设置为no
# cluster-slave-no-failover no

################################## 慢日志查询 ###################################

# slog log是用来记录redis运行中执行比较慢的命令耗时。当命令的执行超过了指定时间，就记录在slow log中，slog log保存在内存中，所以没有IO操作。
# 执行时间比slowlog-log-slower-than大的请求记录到slowlog里面，单位是微秒，所以1000000就是1秒。注意，负数时间会禁用慢查询日志，而0则会强制记录所有命令。
slowlog-log-slower-than 10000

# 慢查询日志长度。当一个新的命令被写进日志的时候，最老的那个记录会被删掉。这个长度没有限制。只要有足够的内存就行。你可以通过 SLOWLOG RESET 来释放内存。
slowlog-max-len 128

################################ LATENCY MONITOR ##############################

# 延迟监控功能是用来监控redis中执行比较缓慢的一些操作，用LATENCY打印redis实例在跑命令时的耗时图表。只记录大于等于下边设置的值的操作
# 0的话，就是关闭监视。默认延迟监控功能是关闭的，如果你需要打开，也可以通过CONFIG SET命令动态设置。
latency-monitor-threshold 0

############################# EVENT NOTIFICATION ##############################

notify-keyspace-events ""

############################### ADVANCED CONFIG ###############################

hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10

# 在aof重写的时候，如果打开了aof-rewrite-incremental-fsync开关，系统会每32MB执行一次fsync。这对于把文件写入磁盘是有帮助的，可以避免过大的延迟峰值
aof-rewrite-incremental-fsync yes

总结

这是一篇关于如何在CentOS 7上离线搭建Redis的文章，文章详细的总结了单节点搭建，简单的主从搭建，Sentinel搭建和Redis Cluster搭建。文章内容有点多，但是很全，其中搭建方式可以直接用于生产环境搭建。希望我的这篇文章能够帮助到大家。