redis安装和部署(含cluster以及sentinel)

redis安装部署

下载和安装

官网下载
菜鸟教程

下载最新稳定版(stable)即可.:redis-5.0.3.tar.gz

新建redis用户：

groupadd -g 1002 dba
useradd -s /bin/bash -d /home/redis -g dba -m redis

root用户将redis-5.0.3.tar.gz上传到redis用户目录下，修改其权限
chown redis:dba redis-5.0.3.tar.gz

chmod 755 redis-5.0.3.tar.gz

redis用户解压文件:

tar -zxvf redis-5.0.3.tar.gz

修改名称：
mv redis-5.0.3/ redis

代码编译

cd /home/redis/redis/src
make install

首先为了方便管理，将Redis文件中的conf配置文件和常用命令移动到统一文件中
创建bin和redis.conf文件

cd /home/redis
mkdir bin
mkdir ect

mv redis.conf etc/
mv sentinel.conf etc/
cd /home/redis/redis/src
mv mkreleasdhdr.sh redis-benchmark redis-check-aof redis-check-dump redis-cli redis-server /home/redis/redis/bin

###方便启动，将redis目录添加至环境变量中：

vi .bash_profile增加
export PATH=$PATH:/home/redis/redis/bin

启动

redis用户启动

redis-server

或者指定配置文件启动
redis-server etc/redis.conf

后台启动的话需要修改配置

cd etc/
Vi redis.conf

将daemonize属性改为yes，修改绑定IP，关闭持久化：save “”（记得删除rdb文件）

之后启动时指定配置文件即可（不指定的话会使用默认配置，以上配置不会生效）

redis@melody-ubuntu:~/redis$ redis-server etc/redis.conf
ps -ef  | grep 6379
redis     28392      1  0 12:16 ?        00:00:00 redis-server 192.168.1.250:6379
redis     28445  25247  0 12:16 pts/4    00:00:00 grep 6379

replication

复制功能，redis可以被配置为主从模式，主redis可以进行读写操作，一般从数据库只是可读的，master会将数据同步到slave节点中
一般可以配置一主两从的模式。

配置方法

1. master redis不需要做任何配置
2. slave redis 节点配置文件中加入如下配置：

slaveof master_ip master_port

同时也可以登录slave节点执行如下命令：

redis>SLAVEOF 127.0.0.1 6379

另外可以设置从数据库的配置文件中的slave-read-only为no式从数据库可写，但此时不会进行同步而且master中更新了相应数据后会被覆盖，所以一般不这样做.

从数据库不仅可以接受主数据库的同步数据，自己也可以同时作为主数据库存在，形成网状结构.

配置redis复制的时候如果master设置了密码，需要在从数据库的配置文件中配置master的密码，如下配置：

masterauth ****

命令

1. INFO replication：在master、slave节点中获取replication的相关信息
2. SLAVEOF NO ONE:将从数据库提升为主数据库
3. SLAVEOF master_ip master_port：将本节点作为master节点的slave节点

sentinel部署

redis2.8之后提供了哨兵实现自动化的系统监控和故障恢复功能
可以配置为一主两备三个哨兵

1. 哨兵可以对master、slave进行监控；
2. 当master出现故障时，三个哨兵会投票决定将哪个slave节点转为master
3. 哨兵之间也可以相互进行监控

sentinel的配置

将redis.conf复制出来一个sentinel.conf文件

1. 配置待监控的master节点

sentinel.conf

sentinel monitor mymaster 127.0.0.1 6379 1

mymaster:主数据库名称
1：最低通过票数，所以哨兵的个数最好为基数，最少为3，这样投票的时候可以设置为2，表示3个哨兵中有两个投票成功即可切换

注意哨兵仅需要配置监控主数据即可，哨兵会自动发现所有复制该主数据库的从数据库。另外一个哨兵可以同时监控多个redis主从系统，只需要配置多个即可。

2. 配置主观下线判断时长

sentinel.conf

sentinel down-after-milliseconds mymaster 60000

当down-after-milliseconds的值小于1s时，sentinel会每隔down-after-milliseconds指定的时间发送一次PING命令；当down-after-milliseconds的值大于1s时，sentinel会每隔1s发送一次PING命令。

当超过down-after-milliseconds指定时候后，如果被PING的数据库仍然未进行回复，认为其主观下线。如果该节点是master，哨兵会发送 SENTINEL is-master-down-by-addr命令询问其他哨兵是否也认为主观下线，如果达到指定数量，则会认为master客观下线，此时多个sentinel会选举领头的哨兵节点对主从系统发起故障恢复。
领头哨兵的选举过程使用Raft算法，注意当有多个sentinel参选领头哨兵时，会等待一个随机的时间重新选举，此处不赘述。

3. 选举优先级

redis.conf

slave-priority 100

当master挂掉后，领头哨兵选举新的master时会根据每个slave配置的该值进行参考选举，该值配置越小，越优先；
如果多个slave的slave-priority配置相同，会根据复制的命令偏移量越大越优先；
如果以上条件都一样，则会选中运行ID较小的从数据库。

选中之后，领头哨兵将向被选中的从数据库发送SENTINEL NO ONE命令使其升格为master；然后向其他slave发送SLAVEOF命令。

sentinel启动方式

redis-server etc/sentinel.conf --sentinel

哨兵监控的几个状态

+monitor：表示当前sentinel正在监控的节点
+slave：表示当前sentinel发现了从数据库
+sdown：表示当前sentinel主观认为主数据库停止服务了
+odown：表示哨兵客观认为主数据停止服务了，此时开始故障恢复，投票选举
+try-failover：表示sentinel开始进行故障恢复
+failover-end：表示sentinel完成故障恢复
+switch-master：表示已完成master的切换
-sdown：表示实例恢复
+convert-to-slave：表示该节点已切换为slave节点

sentinel工作机制

1. 每10s会向主数据库和从数据库发送INFO命令
2. 每2s哨兵会向主数据库和从数据库的_sentinel_:hello频道发送自己的信息
3. 每1s哨兵会向主数据、从数据库和其他哨兵发送PING命令

sentinel 命令

PING ：返回 PONG

SENTINEL masters ：列出所有被监视的主服务器，以及这些主服务器的当前状态；

SENTINEL slaves <master name> ：列出给定主服务器的所有从服务器，以及这些从服务器的当前状态；

SENTINEL get-master-addr-by-name <master name> ： 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作,或者针对这个主服务器的故障转移操作已经完成， 那么这个命令返回新的主服务器的 IP 地址和端口号；

SENTINEL reset <pattern> ： 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel;

SENTINEL failover <master name> ： 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移。

SUBSCRIBE +switch-master : 订阅master切换事件通知

cluster部署

1. redis3.0+
2. 拥有和单机同样的性能
3. 支持几乎所有的单机实例支持的命令
4. MGET操作时，如果每个key都位于同一个节点，则可以正常支持
5. 限制只能使用默认的0号数据库

cluster配置

cluster-enabled yes

使用集群，只需要将每个redis节点的cluster-enabled配置选项打开即可.

cluster-config-file nodes.conf

集群启动时，只需要将每个redis启动即可。集群会将当前节点记录的集群状态持久化地存储在指定文件中，这个文件默认为当前工作目录下的nodes.conf文件。每个节点对应的文件必须不同，否则会造成启动失败，可以通过上述配置指定.

cluster创建

首先在每个redis节点上执行INFO cluster,如果集群可以正常使用了，需要使用辅助工具redis-trib.rb来初始化集群(需要安装ruby程序)，使用如下命令初始化集群,以3主3从为例:

redis-trib.rb create --replicas 1 ip1:port1 ip2:port2 ip3:port3 ip4:port4 ip5:port5 ip6:port6

其中参数create表示要初始化集群，–replicas 1 表示每个数据库库拥有的从数据库个数为1.

1. 准备好后集群会向每个节点发送CLUSTER MEET ip port命令告诉当前节点指定的ip和port也是集群的一部分,从而使每个节点最终可以归入一个集群；
2. redis-trib.rb会分配主从节点，原则是尽量保证每个master允许在不同的ip上，同时保证每个主从库不在一个ip上，保证容灾能力.
3. 分配插槽，其实就是分配哪些键归哪些节点负责。
4. 对每个slave节点发送CLUSTER REPLICATION mast的运行ID来将当前几点转成slave并复制指定运行ID的节点。
5. 创建完成

cluster插槽分配

使用CLUSTER meet ip port新加入的节点，有以下两种运行方式：

1. 使用CLUSTER REPLICATE命令复制每个master库以slave的形式运行；
2. 向集群申请分配slot以maser库的形式运行；

一个集群中插槽是如何分配？

一个集群中的插槽供16384个，每个mster会负责处理一部分slot。
redis将每个key的名称的有效部分按CRC16算法计算出其hash值，后对16384取余，即为当前key所在的插槽的位置。key的有效部分如下：

1. 如果key中包含{符号，且在{后存在}符号，并且{和}之间至少一个字符，那么有效部分即为{}中的内容；
2. 如果不满足上一条，则整个key即为有效部分；

如：{user102}:last:name的有效部分为"user102"

如果在一个cluster中操作命令涉及多个键（MGET），只有当所有的相关键都位于同一个节点时才可正常支持。比如{user102}:last:name和{user102}:first:name会被分配在同一个节点，可以使用MGET同来操作这两个值，否则的话会出错。

插槽的迁移这里不做详细说明。

cluster命令

> info cluster  返回cluster_enabled:1表示集群正常启用了。

> cluster nodes   查看集群中的节点信息

> CLUSTER MEET ip1 port1   向集群中增加一个节点，登录该节点执行此命令，告诉集群中的任意一台设备即可，这里使用的是ip1、port1

> CLUSTER SLOTS  查看插槽的分配情况

> CLUSTER ADDSLOTS slot1 [slot2] ... [slotn]   为新节点分配插槽，如果指定插槽已经分配过了，则会报错

> CLUSTER SETSLOT 插槽号 NODE 新节点的运行ID     将已经被分配的插槽迁移至其他节点，迁移的前提是被迁移的插槽中不存在任何键

> CLUSTER GETKEYSINSLOT   插槽号   要返回的键的数量    获取某个插槽中存在哪些键

cluster模式下的故障恢复

集群中的每个节点每隔1s会随机选择其余节点中最久没有响应的节点发送PING命令，如果一定时间内没有响应回复，则该节点会被认为是疑似下线(PFAIL)

1. 一旦节点A发现B是疑似下线，会在集群中广播该消息
2. 当剧情中某一个节点C收集到半数以上的节点认为B疑似下线时，就会将B标记为下线，并在集群中传播该消息，使B在整个集群中下线。

在一个集群中，如果一个maser下线，则一部分插槽会出现无法写入的问题，集群会进行故障恢复将其中一个slave升格为master，多个slave的情况下至于选择那个slave升级，选择过程与哨兵选择领头哨兵的过程一致。
当某个slave当选为master后，会通过slave on one将自己转换为master。

如果master下线并且没有相应的slave进行故障恢复时，整个集群会默认进入无法工作状态，如果想在这种情况下使集群正常工作，可以通过修改以下配置为no

cluster-require-full-coverage no

redis常用配置

redis.conf

protected-mode no
port 6380
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile /home/redis/redis6380.pid
loglevel notice
logfile /home/redis/log/redis6380.log
databases 16
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump6380.rdb
dir /home/redis/db
slaveof 2018:7:11::211 6380
masterauth db10$AAA
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-timeout 180
repl-disable-tcp-nodelay no
repl-backlog-size 200mb
slave-priority 100
requirepass db10$AAA
maxclients 10000
appendonly no
appendfilename appendonly6380.aof
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
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-rewrite-incremental-fsync yes

sentinel.conf

protected-mode no
port 26380
dir "/home/redis/db"
sentinel myid 07189cde021c267325ee85e2f362337da5b5f592
sentinel monitor mymaster 2018:7:11::211 6380 2
sentinel auth-pass mymaster db10$AAA
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0

daemonize yes
sentinel known-slave mymaster 2018:7:11::212 6380
sentinel known-slave mymaster 2018:7:11::213 6380
sentinel known-sentinel mymaster 2018:7:11::212 26380 8e24cfdc1963e5d1ae3a3f8a8b2f9d22df1ff807
sentinel known-sentinel mymaster 2018:7:11::211 26380 c707baade43cd2cde3ad32c79361da9f94a2a287
sentinel current-epoch 0