在不使用redis-cluster集群的情况下，配置完成两台redis实例配置成主从模式即可较好的实现实时备份，同时sentinel实际上也是一个redis实例，用于监控各个redis节点的状态，实现当主服务器down掉后自动的切换至从服务器。
以下试验是在单机上启动三个redis实例（一个物理机可以启动多个redis实例，用端口区分），一个master，一个slave，一个sentinel用于监控master的状态，如果把每个redis实例映射为主机，对应如下图所示。
首先手动安装redis
wget http://download.redis.io/releases/redis-stable.tar.gz
tar -zxzf redis-2.8.17.tar.gz
cd redis-stable
make （要保证gcc环境）
make MALLOC=libc // 如果编译报错
tar -zcvf redis.tar.gz redis-stable // 返回打包redis文件夹，上传服务器使用make完后redis-stable目录下会出现编译后的redis服务程序redis-server，还有用于测试的客户端程序redis-cli，两个程序位于安装目录src目录下：
下面启动redis服务：
cd src
./redis-server注意这种方式启动redis使用的是默认配置。也可以通过启动参数告诉redis使用指定配置文件使用下面命令启动。
cd src
./redis-server redis.confredis.conf是一个默认的配置文件，我们可以根据需要使用自己的配置文件。
启动redis服务进程后，就可以使用测试客户端程序redis-cli和redis服务交互了。 比如：
cd src
./redis-cli
redis> set name zhangsan
OK
redis> get name
"zhangsan"为方便管理，可以在/usr/local/下创建需要的目录
cd /usr/local
sudo mkdir redis然后在redis目录，新建bin和conf目录。(不是必须的，只不是过为了方便而已)
把前面编译后的redis的可执行文件(在redis-stable/src/目录)，复制到/usr/local/redis/bin里面去
拷贝redis开头的所有文件
sudo cp redis* /usr/local/redis/bin/redis提供给我们了一个默认的配置文件redis.conf在其根目录下，把它复制到/usr/local/redis/conf目录下，并改名为6379.conf
sudo cp redis.conf /usr/local/redis/conf/6379.conf修改配置文件6379.conf，修改如下几个配置：
daemonize no修改为：daemonize yes (后台程序方式运行)
#pidfile /var/run/redis_6379.pid修改为：pidfile /usr/local/redis/redis_6379.pid
将 bind 127.0.0.1 使用#注释掉，改为# bind 127.0.0.1（bind配置的是允许连接的ip，默认只允许本机连接；若远程连接需注释掉，或改为0.0.0.0）
将 protected-mode yes 改为 protected-mode no（3.2之后加入的新特性，目的是禁止公网访问redis cache，增强redis的安全性）
将 requirepass foobared 注释去掉，foobared为密码，也可修改为别的值（可选，建议设置）
添加iptables规则
iptables -I INPUT 1 -p tcp -m state --state NEW -m tcp --dport 6379 -j ACCEPT保存
service iptables save配置iptables开机自启
保存后重启依然没有生效，后百度得知，需要设置iptables开机自启才可使配置生效。
service iptables on启动，注意文件夹路径不要搞错
/usr/local/redis/bin/redis-server /usr/local/redis/conf/6379.conf
ps -ef | grep redis // 验证进程启动配置从节点，这里采用启动另一个实例的方式
cp 6379.conf 6380.conf
修改6380.conf
修改对应的端口和pid配置
port 6379修改为：port 6380
pidfile /usr/local/redis/redis_6379.pid修改为：pidfile /usr/local/redis/redis_6380.pid
增加一行：slaveof 127.0.0.1 6379
启动2个redis实例
/usr/local/redis/bin/redis-server /usr/local/redis/conf/6379.conf
/usr/local/redis/bin/redis-server /usr/local/redis/conf/6380.conf
ps -ef | grep redis // 验证进程启动
启动redis客户端，去连接6379那个实例
cd /usr/local/redis/bin/
./redis-cli -h 127.0.0.1 -p 6379
连上之后输入：info命令，查看主从配置成功。
测试新增
set name zhangsan
读取
get name
然后访问6380那个实例
./redis-cli -h 127.0.0.1 -p 6380
get name
我们发现这2个实例已经完成了数据的同步。
如果我们要在从服务器写入
set name lisi
会提示：(error) READONLY You can't write against a read only slave.
因为从服务器只有读权限，我们做的就是redis的读写分离。
配置redis-sentinel，用于自动检测问题，自动选择主服务器。
cp sentinel.conf /usr/local/redis/conf/
sentinel 节点启动有两种方式:
使用redis-sentinel sentinel_6379.conf
/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/sentinel.conf
或使用redis-server sentinel_6379.conf --sentinel
port 26379
daemonize no
#bind 192.168.56.11 // 当前试验环境不需要配置
l#ogfile "/data/app/redis/logs/sentinel_26379.log" // 当前试验环境不需要配置
#dir "/data/db/sentinel_26379" // 当前试验环境不需要配置
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，地址为127.0.0.1:6379。我们知道，网络是不可靠的，有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了，当sentinel集群式，解决这个问题的方法就变得很简单，只需要多个sentinel互相沟通来确认某个master是否真的死了，这个2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了。（sentinel集群中各个sentinel也有互相通信，通过gossip协议）。
除了第一行配置，我们发现剩下的配置都有一个统一的格式：
sentinel <option_name> <master_name> <option_value>
接下来我们根据上面格式中的option_name一个一个来解释这些配置项：
down-after-milliseconds
sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了(subjectively down, 也简称为SDOWN)。而这个down-after-milliseconds就是用来指定这个“一定时间范围”的，单位是毫秒。
这个时候sentinel并不会马上进行failover主备切换，这个sentinel还需要参考sentinel集群中其他sentinel的意见，如果超过某个数量的sentinel也主观地认为该master死了，那么这个master就会被客观地(注意哦，这次不是主观，是客观，与刚才的subjectively down相对，这次是objectively down，简称为ODOWN)认为已经死了。需要一起做出决定的sentinel数量在上一条配置中进行配置。
parallel-syncs
在发生failover主备切换时，这个选项指定了最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1来保证每次只有一个slave处于不能处理命令请求的状态。
其他配置项在sentinel.conf中都有很详细的解释。
所有的配置都可以在运行时用命令SENTINEL SET command动态修改。