文章目录
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节点中
一般可以配置一主两从的模式。
配置方法
- master redis不需要做任何配置
- 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之后提供了哨兵实现自动化的系统监控和故障恢复功能
可以配置为一主两备三个哨兵
- 哨兵可以对master、slave进行监控;
- 当master出现故障时,三个哨兵会投票决定将哪个slave节点转为master
- 哨兵之间也可以相互进行监控
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工作机制
- 每10s会向主数据库和从数据库发送INFO命令
- 每2s哨兵会向主数据库和从数据库的_sentinel_:hello频道发送自己的信息
- 每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部署
- redis3.0+
- 拥有和单机同样的性能
- 支持几乎所有的单机实例支持的命令
- MGET操作时,如果每个key都位于同一个节点,则可以正常支持
- 限制只能使用默认的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.
- 准备好后集群会向每个节点发送
CLUSTER MEET ip port
命令告诉当前节点指定的ip和port也是集群的一部分,从而使每个节点最终可以归入一个集群; - redis-trib.rb会分配主从节点,原则是尽量保证每个master允许在不同的ip上,同时保证每个主从库不在一个ip上,保证容灾能力.
- 分配插槽,其实就是分配哪些键归哪些节点负责。
- 对每个slave节点发送
CLUSTER REPLICATION mast的运行ID
来将当前几点转成slave并复制指定运行ID的节点。 - 创建完成
cluster插槽分配
使用CLUSTER meet ip port
新加入的节点,有以下两种运行方式:
- 使用
CLUSTER REPLICATE
命令复制每个master库以slave的形式运行; - 向集群申请分配slot以maser库的形式运行;
一个集群中插槽是如何分配?
一个集群中的插槽供16384个,每个mster会负责处理一部分slot。
redis将每个key的名称的有效部分按CRC16算法计算出其hash值,后对16384取余,即为当前key所在的插槽的位置。key的有效部分如下:
- 如果key中包含{符号,且在{后存在}符号,并且{和}之间至少一个字符,那么有效部分即为{}中的内容;
- 如果不满足上一条,则整个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)
- 一旦节点A发现B是疑似下线,会在集群中广播该消息
- 当剧情中某一个节点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