Redis
1、NoSQL 数据库
数据库主要分为两大类：关系型数据库与 NoSQL 数据库。
关系型数据库，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据。主流的 MySQL、Oracle、MS SQL Server 和 DB2 都属于这类传统数据库。
NoSQL 数据库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候可以考虑使用更加合适的数据存储。NoSQL 是对不同于传统的关系型数据库的数据库管理系统的统称。
NoSQL用于超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
1-1、为什么使用NoSQL
主要是由于随着互联网发展，数据量越来越大，对性能要求越来越高，传统数据库存在着先天性的缺陷，即单机（单库）性能瓶颈，并且扩展困难。这样既有单机单库瓶颈，却又扩展困难，自然无法满足日益增长的海量数据存储及其性能要求，所以才会出现了各种不同的 NoSQL 产品，NoSQL 根本性的优势在于在云计算时代，简单、易于大规模分布式扩展，并且读写性能非常高
通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL 数据库的发展却能很好的处理这些大的数据。
1-2、RDBMS和NOSQL对比
RDBMS
- 高度组织化结构化数据
- 结构化查询语言（SQL）
- 数据和关系都存储在单独的表中。
- 数据操纵语言，数据定义语言
- 严格的一致性
- 基础事务
NoSQL
- 代表着不仅仅是SQL, 没有声明性查询语言
- 没有预定义的模式
- 最终一致性，而非ACID属性
- 非结构化和不可预知的数据
- CAP定理
- 高性能，高可用性和可伸缩性
1-2-1、NoSQL的优点/缺点
1-2-2、CAP定理
在计算机科学中, CAP定理（CAP theorem）, 又被称为布鲁尔定理（Brewer's theorem）, 它指出对于一个分布式计算系统来说，不可能同时满足以下三点:
一致性(Consistency) :所有节点在同一时间具有相同的数据
可用性(Availability) :保证每个请求不管成功或者失败都有响应
分区容忍(Partition tolerance) :系统中任意信息的丢失或失败不会影响系统的继续运作
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较的满足两个。
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
- CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
- CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
- AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
1-2-3、NoSQL 数据库分类
1-3、Redis 特性
速度快: 10W QPS,基于内存,C语言实现
单线程
持久化
支持多种数据结构
支持多种编程语言
功能丰富: 支持Lua脚本,发布订阅,事务,pipeline等功能
简单: 代码短小精悍(单机核心代码只有23000行左右),单线程开发容易,不依赖外部库,使用简单
主从复制
支持高可用和分布式
1-3-1、单线程
单线程为何如此快?
注意事项:
- 一次只运行一条命令
- 避免执行长(慢)命令:keys *, flushall, flushdb, slow lua script, mutil/exec, operate big value(collection)
- 其实不是单线程: 早期版本是单进程单线程,3.0 版本后实际还有其它的线程, 实现特定功能,如: fysnc file descriptor,close file descriptor
1-3-2、 Redis 常见应用场景
- 缓存：缓存RDBMS中数据,比如网站的查询结果、商品信息、微博、新闻、消息
- Session 共享：实现Web集群中的多服务器间的session共享
- 计数器：商品访问排行榜、浏览数、粉丝数、关注、点赞、评论等和次数相关的数值统计场景
- 社交：朋友圈、共同好友、可能认识他们等
- 地理位置: 基于地理信息系统GIS（Geographic Information System)实现摇一摇、附近的人、外卖等功能
- 消息队列：ELK等日志系统缓存、业务的订阅/发布系统
1-3-3、缓存穿透,缓存击穿和缓存雪崩
a、缓存穿透
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，比如： 发起为id为 “-1” 的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
解决方法：
接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截
从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
b、缓存击穿
缓存击穿是指缓存中没有但数据库中有的数据，比如：热点数据的缓存时间到期后，这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力
解决方法：
设置热点数据永远不过期。
c、缓存雪崩
缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
解决方法：
缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生
如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中
设置热点数据永远不过期
1-4、Redis 安装
1-4-1、包安装
#Ubuntu
[root@ubuntu2004 ~]#apt install redis
#centos、rocky：
[root@rocky8 ~]#dnf install redis
1-4-2、编译安装 Redis
Redis 源码包官方下载链接：
http://download.redis.io/releases
https://redis.io/download/
a、安装依赖包
#Ubuntu
[root@ubuntu2004 ~]#apt install -y make gcc libjemalloc-dev libsystemd-dev
#centos、rocky：
[root@rocky8 ~]#yum -y install gcc make jemalloc-devel systemd-devel
b、解压编译
[root@ubuntu2004 ~]#tar xf redis-7.0.5.tar.gz -C /usr/local/src/
[root@ubuntu2004 ~]#cd /usr/local/src/redis-7.0.5/
[root@ubuntu2004 redis-7.0.5]#make USER_SYSTEMD=yes PREFIX=/apps/redis install #支持systemd
[root@ubuntu2004 redis-7.0.5]#ln -sv /apps/redis/bin/* /usr/bin/
c、修改配置文件
[root@ubuntu2004 redis-7.0.5]#cp /usr/local/src/redis-7.0.5/redis.conf /apps/redis/etc/
[root@ubuntu2004 ~]#vim /apps/redis/etc/redis.conf
bind 10.0.0.101 #监听ip
requirepass 123456 # 连接密码
d、创建 Redis 用户和设置数据目录权限
[root@ubuntu2004 ~]#useradd -r -s /sbin/nologin redis
[root@ubuntu2004 ~]#chown -R redis.redis /apps/redis
f、 创建 Redis 服务 Service 文件
[root@ubuntu2004 ~]#vim /usr/lib/systemd/system/redis.service
[Unit]
Description=Redis persistent key-value database
After=network.target
[Service]
ExecStart=/apps/redis/bin/redis-server /apps/redis/etc/redis.conf --supervised systemd
ExecStop=/bin/kill -s QUIT \$MAINPID
Type=notify
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755
LimitNOFILE=1000000
[Install]
WantedBy=multi-user.target
[root@ubuntu2004 ~]#systemctl daemon-reload
[root@ubuntu2004 ~]#systemctl start redis.service
[root@ubuntu2004 ~]#systemctl status redis.service
1-4-3、开启redis多实例
[root@rocky8 etc]#cp /apps/redis/bin/etc/redis.conf /apps/redis/bin/etc/redis6380.conf
[root@rocky8 etc]#cp /apps/redis/bin/etc/redis.conf /apps/redis/bin/etc/redis6381.conf
[root@rocky8 etc]#sed -i 's/6379/6381/g' /apps/redis/bin/etc/redis6381.conf
1-4-4、消除启动时的三个Warning提示信息(可选)
1、Tcp backlog
WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
Tcp backlog 是指TCP的第三次握手服务器端收到客户端 ack确认号之后到服务器用Accept函数处理请求前的队列长度，即全连接队列
#vim /etc/sysctl.conf
net.core.somaxconn = 1024
#sysctl -p
2、overcommit_memory
WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
内核参数说明:
内核参数overcommit_memory 实现内存分配策略,可选值有三个：0、1、2
0 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则内存申请失败，并把错误返回给应用进程
1 表示内核允许分配所有的物理内存，而不管当前的内存状态如何
2 表示内核允许分配超过所有物理内存和交换空间总和的内存
#vim /etc/sysctl.conf
vm.overcommit_memory = 1
#sysctl -p
3、transparent hugepage
WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
警告：您在内核中启用了透明大页面（THP,不同于一般4k内存页,而为2M）支持。 这将在Redis中造成延迟和内存使用问题。 要解决此问题，请以root 用户身份运行命令“echo never> /sys/kernel/mm/transparent_hugepage/enabled”，并将其添加到您的/etc/rc.local中，以便在重启后保留设置。禁用THP后，必须重新启动Redis
#ubuntu：
[root@rocky8 ~]#echo 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' >> /etc/rc.d/rc.local
[root@rocky8 ~]#chmod +x /etc/rc.d/rc.local
#centos：
[root@rocky8 ~]#echo 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' >> /etc/rc.d/rc.local
[root@rocky8 ~]#chmod +x /etc/rc.d/rc.local
1-5、Redis 相关工具和客户端连接
1-5-1、安装的相关程序介绍
[root@ubuntu2004 ~]#ll /apps/redis/bin/
-rwxr-xr-x 1 root root 8113680 10月 29 11:39 redis-benchmark* #性能测试程序
lrwxrwxrwx 1 root root 12 10月 29 11:39 redis-check-aof -> redis-server* #AOF文件检查程序
lrwxrwxrwx 1 root root 12 10月 29 11:39 redis-check-rdb -> redis-server* #RDB文件检查程序
-rwxr-xr-x 1 root root 8083712 10月 29 11:39 redis-cli* #客户端程序
lrwxrwxrwx 1 root root 12 10月 29 11:39 redis-sentinel -> redis-server* #哨兵程序，软连接到服务器端主程序
-rwxr-xr-x 1 root root 15566776 10月 29 11:39 redis-server* #服务端主程序
1-5-2、客户端程序 redis-cli
#默认为本机无密码连接
redis-cli
#远程客户端连接,注意:Redis没有用户的概念
redis-cli -h <Redis服务器IP> -p <PORT> -a <PASSWORD>
1-5-3、python连接redis
[root@ubuntu2004 ~]#apt install -y python3-pip python3-redis
2、Redis 配置管理
2-1、 Redis 配置文件说明
bind 0.0.0.0 #指定监听地址，支持用空格隔开的多个监听IP
protected-mode yes #redis3.2之后加入的新特性，在没有设置bind IP和密码的时候,redis只允许访问127.0.0.1:6379，可以远程连接，但当访问将提示警告信息并拒绝远程访问
port 6379 #监听端口,默认6379/tcp
tcp-backlog 511 #三次握手的时候server端收到client ack确认号之后的队列值，即全连接队列长度
timeout 0 #客户端和Redis服务端的连接超时时间，默认是0，表示永不超时
tcp-keepalive 300 #tcp 会话保持时间300s
daemonize no #默认no,即直接运行redis-server程序时,不作为守护进程运行，而是以前台方式运行，如果想在后台运行需改成yes,当redis作为守护进程运行的时候，它会写一个 pid 到/var/run/redis.pid 文件
supervised no #和OS相关参数，可设置通过upstart和systemd管理Redis守护进程，centos7后都使用systemd
pidfile /var/run/redis_6379.pid #pid文件路径,可以修改为/apps/redis/run/redis_6379.pid
loglevel notice #日志级别
logfile "/path/redis.log" #日志路径,示例:logfile "/apps/redis/log/redis_6379.log"
databases 16 #设置数据库数量，默认：0-15，共16个库
always-show-logo yes #在启动redis 时是否显示或在日志中记录记录redis的logo
save 900 1 #在900秒内有1个key内容发生更改,就执行快照机制
save 300 10 #在300秒内有10个key内容发生更改,就执行快照机制
save 60 10000 #60秒内如果有10000个key以上的变化，就自动快照备份
stop-writes-on-bgsave-error yes #默认为yes时,可能会因空间满等原因快照无法保存出错时，会禁止redis写入操作，生产建议为no
rdbcompression yes #持久化到RDB文件时，是否压缩，"yes"为压缩，"no"则反之
rdbchecksum yes #是否对备份文件开启RC64校验，默认是开启
dbfilename dump.rdb #快照文件名
dir ./ #快照文件保存路径，示例：dir "/apps/redis/data"
#主从复制相关
# replicaof <masterip> <masterport> #指定复制的master主机地址和端口，5.0版之前的指令为slaveof
# masterauth <master-password> #指定复制的master主机的密码
replica-serve-stale-data yes #当从库同主库失去连接或者复制正在进行，从机库有两种运行方式：
1、设置为yes(默认设置)，从库会继续响应客户端的读请求，此为建议值
2、设置为no，除去特定命令外的任何请求都会返回一个错误"SYNC with master in progress"。
replica-read-only yes #是否设置从库只读，建议值为yes,否则主库同步从库时可能会覆盖数据，造成数据丢失
repl-diskless-sync no #是否使用socket方式复制数据(无盘同步)，新slave第一次连接master时需要做数据的全量同步，redis server就要从内存dump出新的RDB文件，然后从master传到slave，有两种方式把RDB文件传输给客户端：
1、基于硬盘（disk-backed）：为no时，master创建一个新进程dump生成RDB磁盘文件，RDB完成之后由父进程（即主进程）将RDB文件发送给slaves，此为默认值
2、基于socket（diskless）：master创建一个新进程直接dump RDB至slave的网络socket，不经过主进程和硬盘
#推荐使用基于硬盘（为no），是因为RDB文件创建后，可以同时传输给更多的slave，但是基于socket(为yes)， 新slave连接到master之后得逐个同步数据。只有当磁盘I/O较慢且网络较快时，可用diskless(yes),否则一般建议使用磁盘(no)
repl-diskless-sync-delay 5 #diskless时复制的服务器等待的延迟时间，设置0为关闭，在延迟时间内到达的客户端，会一起通过diskless方式同步数据，但是一旦复制开始，master节点不会再接收新slave的复制请求，直到下一次同步开始才再接收新请求。即无法为延迟时间后到达的新副本提供服务，新副本将排队等待下一次RDB传输，因此服务器会等待一段时间才能让更多副本到达。推荐值：30-60
repl-ping-replica-period 10 #slave根据master指定的时间进行周期性的PING master,用于监测master状态,默认10s
repl-timeout 60 #复制连接的超时时间，需要大于repl-ping-slave-period，否则会经常报超时
repl-disable-tcp-nodelay no #是否在slave套接字发送SYNC之后禁用 TCP_NODELAY，如果选择"yes"，Redis将合并多个报文为一个大的报文，从而使用更少数量的包向slaves发送数据，但是将使数据传输到slave上有延迟，Linux内核的默认配置会达到40毫秒，如果 "no" ，数据传输到slave的延迟将会减少，但要使用更多的带宽
repl-backlog-size 512mb #复制缓冲区内存大小，当slave断开连接一段时间后，该缓冲区会累积复制副本数据，因此当slave 重新连接时，通常不需要完全重新同步，只需传递在副本中的断开连接后没有同步的部分数据即可。只有在至少有一个slave连接之后才分配此内存空间,建议建立主从时此值要调大一些或在低峰期配置,否则会导致同步到slave失败
repl-backlog-ttl 3600 #多长时间内master没有slave连接，就清空backlog缓冲区
replica-priority 100 #当master不可用，哨兵Sentinel会根据slave的优先级选举一个master，此值最低的slave会优先当选master，而配置成0，永远不会被选举，一般多个slave都设为一样的值，让其自动选择
#min-replicas-to-write 3 #至少有3个可连接的slave，mater才接受写操作
#min-replicas-max-lag 10 #和上面至少3个slave的ping延迟不能超过10秒，否则master也将停止写操作
requirepass foobared #设置redis连接密码，之后需要AUTH pass,如果有特殊符号，用" "引起来,生产建议设置
rename-command #重命名一些高危命令，示例：rename-command FLUSHALL "" 禁用命令
#示例: rename-command del wang
maxclients 10000 #Redis最大连接客户端
maxmemory <bytes> #redis使用的最大内存，单位为bytes字节，0为不限制，建议设为物理内存一半，
8G内存的计算方式8(G)*1024(MB)1024(KB)*1024(Kbyte)，需要注意的是缓冲区是不计算在maxmemory内,生产中如果不设置此项,可能会导致OOM
#maxmemory-policy noeviction 此为默认值
# MAXMEMORY POLICY：当达到最大内存时，Redis 将如何选择要删除的内容。您可以从以下行为中选择一种：
#
# volatile-lru -> Evict 使用近似 LRU，只有设置了过期时间的键。
# allkeys-lru -> 使用近似 LRU 驱逐任何键。
# volatile-lfu -> 使用近似 LFU 驱逐，只有设置了过期时间的键。
# allkeys-lfu -> 使用近似 LFU 驱逐任何键。
# volatile-random -> 删除设置了过期时间的随机密钥。
# allkeys-random -> 删除一个随机密钥，任何密钥。
# volatile-ttl -> 删除过期时间最近的key（次TTL）
# noeviction -> 不要驱逐任何东西，只是在写操作时返回一个错误。
#
# LRU 表示最近最少使用
# LFU 表示最不常用
#
# LRU、LFU 和 volatile-ttl 都是使用近似随机算法实现的。
#
# 注意：使用上述任何一种策略，当没有合适的键用于驱逐时，Redis 将在需要更多内存的写操作时返回错误。这些通常是创建新密钥、添加数据或修改现有密钥的命令。一些示例是：SET、INCR、HSET、LPUSH、SUNIONSTORE、SORT（由于 STORE 参数）和 EXEC（如果事务包括任何需要内存的命令）。
#MAXMEMORY POLICY：当达到最大内存时，Redis 将如何选择要删除的内容。可以从下面行为中进行选择：
# volatile-lru -> 在具有过期集的键中使用近似 LRU 驱逐。
# allkeys-lru -> 使用近似 LRU 驱逐任何键。
# volatile-lfu -> 在具有过期集的键中使用近似 LFU 驱逐。
# allkeys-lfu -> 使用近似 LFU 驱逐任何键。
# volatile-random -> 从具有过期设置的密钥中删除一个随机密钥。
# allkeys-random -> 删除一个随机密钥，任何密钥。
# volatile-ttl -> 删除过期时间最近的key（次TTL）
# noeviction -> 不要驱逐任何东西，只是在写操作时返回一个错误。
#
# LRU 表示最近最少使用
# LFU 表示最不常用
#
# LRU、LFU 和 volatile-ttl 均使用近似实现随机算法。
#
# 注意：使用上述任何一种策略，Redis 都会在写入时返回错误操作，当没有合适的键用于驱逐时。
appendonly no #是否开启AOF日志记录，默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dump数据的间隔时间)，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。默认不启用此功能
appendfilename "appendonly.aof" #文本文件AOF的文件名，存放在dir指令指定的目录中
appendfsync everysec #aof持久化策略的配置
#no表示由操作系统保证数据同步到磁盘,Linux的默认fsync策略是30秒，最多会丢失30s的数据
#always表示每次写入都执行fsync，以保证数据同步到磁盘,安全性高,性能较差
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据,此为默认值,也生产建议值
#同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形,以下参数实现控制no-appendfsync-on-rewrite no #在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘IO开支和请求阻塞时间。
#默认为no,表示"不暂缓",新的aof记录仍然会被立即同步到磁盘，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
#为yes,相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？Linux的默认fsync策略是30秒，最多会丢失30s的数据,但由于yes性能较好而且会避免出现阻塞因此比较推荐
#rewrite 即对aof文件进行整理,将空闲空间回收,从而可以减少恢复数据时间auto-aof-rewrite-percentage 100 #当Aof log增长超过指定百分比例时，重写AOF文件，设置为0表示不自动重写Aof日志，重写是为了使aof体积保持最小，但是还可以确保保存最完整的数据
auto-aof-rewrite-min-size 64mb #触发aof rewrite的最小文件大小
aof-load-truncated yes #是否加载由于某些原因导致的末尾异常的AOF文件(主进程被kill/断电等)，建议yes
aof-use-rdb-preamble no #redis4.0新增RDB-AOF混合持久化格式，在开启了这个功能之后，AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容，其中RDB格式的内容用于记录已有的数据，而AOF格式的内容则用于记录最近发生了变化的数据，这样Redis就可以同时兼有RDB持久化和AOF持久化的优点（既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据）,默认为no,即不启用此功能
lua-time-limit 5000 #lua脚本的最大执行时间，单位为毫秒
cluster-enabled yes #是否开启集群模式，默认不开启,即单机模式
cluster-config-file nodes-6379.conf #由node节点自动生成的集群配置文件名称
cluster-node-timeout 15000 #集群中node节点连接超时时间，单位ms,超过此时间，会踢出集群
cluster-replica-validity-factor 10 #单位为次,在执行故障转移的时候可能有些节点和master断开一段时间导致数据比较旧，这些节点就不适用于选举为master，超过这个时间的就不会被进行故障转移,不能当选master，计算公式：(node-timeout * replica-validity-factor) + repl-ping-replica-period
cluster-migration-barrier 1 #集群迁移屏障，一个主节点至少拥有1个正常工作的从节点，即如果主节点的slave节点故障后会将多余的从节点分配到当前主节点成为其新的从节点。
cluster-require-full-coverage yes #集群请求槽位全部覆盖，如果一个主库宕机且没有备库就会出现集群槽位不全，那么yes时redis集群槽位验证不全,就不再对外提供服务(对key赋值时,会出现CLUSTERDOWN The cluster is down的提示,cluster_state:fail,但ping 仍PONG)，而no则可以继续使用,但是会出现查询数据查不到的情况(因为有数据丢失)。生产建议为no
cluster-replica-no-failover no #如果为yes,此选项阻止在主服务器发生故障时尝试对其主服务器进行故障转移。 但是，主服务器仍然可以执行手动强制故障转移，一般为no
#Slow log 是 Redis 用来记录超过指定执行时间的日志系统，执行时间不包括与客户端交谈，发送回复等I/O操作，而是实际执行命令所需的时间（在该阶段线程被阻塞并且不能同时为其它请求提供服务）,由于slow log 保存在内存里面，读写速度非常快，因此可放心地使用，不必担心因为开启 slow log 而影响Redis 的速度
slowlog-log-slower-than 10000 #以微秒为单位的慢日志记录，为负数会禁用慢日志，为0会记录每个命令操作。默认值为10ms,一般一条命令执行都在微秒级,生产建议设为1ms-10ms之间
slowlog-max-len 128 #最多记录多少条慢日志的保存队列长度，达到此长度后，记录新命令会将最旧的命令从命令队列中删除，以此滚动删除,即,先进先出,队列固定长度,默认128,值偏小,生产建议设为1000以上
2-2、config 命令实现动态修改配置
config 命令用于查看当前redis配置、以及不重启redis服务实现动态更改redis配置等
注意：不是所有配置都可以动态修改,且此方式无法持久保存
CONFIG SET parameter value
时间复杂度：O(1)
CONFIG SET 命令可以动态地调整 Redis 服务器的配置(configuration)而无须重启。
可以使用它修改配置参数，或者改变 Redis 的持久化(Persistence)方式。
CONFIG SET 可以修改的配置参数可以使用命令 CONFIG GET * 来列出，所有被 CONFIG SET 修改的配置参数都会立即生效。
CONFIG GET parameter
时间复杂度： O(N)，其中 N 为命令返回的配置选项数量。
CONFIG GET 命令用于取得运行中的 Redis 服务器的配置参数(configuration parameters)，在Redis 2.4 版本中， 有部分参数没有办法用 CONFIG GET 访问，但是在最新的 Redis 2.6 版本中，所有配置参数都已经可以用 CONFIG GET 访问了。
CONFIG GET 接受单个参数 parameter 作为搜索关键字，查找所有匹配的配置参数，其中参数和值以“键-值对”(key-value pairs)的方式排列。
比如执行 CONFIG GET s* 命令，服务器就会返回所有以 s 开头的配置参数及参数的值：
2-2-1、设置客户端连接密码
127.0.0.1:6379> config set requirepass 123456 #只是在未重启服务前生效，重启服务后失效
OK
127.0.0.1:6379> CONFIG GET requirepass
1) "requirepass"
2) "123456"
#另开一终端
[root@ubuntu2004 ~]#redis-cli
127.0.0.1:6379> info
NOAUTH Authentication required.
127.0.0.1:6379> auth 123456
OK
2-2-2、获取当前配置
127.0.0.1:6379> CONFIG GET * #奇数行为键，偶数行为值
1) "stop-writes-on-bgsave-error"
2) "yes"
3) "active-defrag-cycle-max"
4) "25"
5) "cluster-node-timeout"
6) "15000"
7) "cluster-config-file"
8) "nodes.conf"
9) "cluster-enabled"
10) "no"
......
127.0.0.1:6379> config get bind #查看bind的IP
1) "bind"
2) "0.0.0.0"
127.0.0.1:6379> config get port #查看bind的端口
1) "port"
2) "6379"
2-2-3、设置 Redis 使用的最大内存量
127.0.0.1:6379> config set maxmemory 1G
OK
127.0.0.1:6379> config get maxmemory
1) "maxmemory"
2) "1000000000"
2-3、慢查询
[root@ubuntu2004 ~]#vim /apps/redis/etc/redis.conf
slowlog-log-slower-than 1 #单位为us，指定超过1us即为慢的指令，默认值为10000us
slowlog-max-len 1024 #指定只保存最近的1024条慢记录，默认值为12
127.0.0.1:6379> SLOWLOG LEN #查看慢日志的记录条数
(integer) 1024
127.0.0.1:6379> SLOWLOG GET #查看慢日志，默认为10
127.0.0.1:6379> slowlog get 2 #查看慢日志的最近n条记录
1) 1) (integer) 189297
2) (integer) 1667024815
3) (integer) 13
4) 1) "slowlog"
2) "get"
3) "3"
5) "127.0.0.1:58348"
6) ""
2) 1) (integer) 189296
2) (integer) 1667024778
3) (integer) 17
4) 1) "SLOWLOG"
2) "GET"
5) "127.0.0.1:58348"
6) ""
127.0.0.1:6379> SLOWLOG RESET #清空慢日志
OK
2-4、Redis 持久化
Redis 是基于内存型的NoSQL, 和MySQL是不同的,使用内存进行数据保存
如果想实现数据的持久化,Redis也也可支持将内存数据保存到硬盘文件中
Redis支持两种数据持久化保存方法
- RDB:Redis DataBase
- AOF:AppendOnlyFile
2-4-1、RDB
RDB(Redis DataBase)：是基于某个时间点的快照，注意RDB只保留当前最新版本的一个快照
RDB 持久化功能所生成的 RDB 文件是一个经过压缩的二进制文件，通过该文件可以还原生成该 RDB 文件时数据库的状态。因为 RDB 文件是保存在磁盘中的，所以即便 Redis 服务进程甚至服务器宕机，只要磁盘中 RDB 文件存在，就能将数据恢复
RDB bgsave 实现快照的具体过程:
首先从redis 主进程先fork生成一个新的子进程,此子进程负责将Redis内存数据保存为一个临时文件tmp-<子进程pid>.rdb，当数据保存完成后,再将此临时文件改名为RDB文件,如果有前一次保存的RDB文件则会被替换，最后关闭此子进程
由于Redis只保留最后一个版本的RDB文件,如果想实现保存多个版本的数据,需要人为实现
2-4-1-1、RDB 相关配置
#在配置文件中的 save 选项设置多个保存条件，只有任何一个条件满足，服务器都会自动执行 BGSAVE 命令
save 900 1 #900s内修改了1个key即触发保存RDB
save 300 10 #300s内修改了10个key即触发保存RDB
save 60 10000 #60s内修改了10000个key即触发保存RDB
dbfilename dump.rdb
dir ./ #编泽编译安装时默认RDB文件存放在Redis的工作目录,此配置可指定保存的数据目录
stop-writes-on-bgsave-error yes #当快照失败是否仍允许写入,yes为出错后禁止写入,建议为no
rdbcompression yes
rdbchecksum yes
127.0.0.1:6379> config get save
1) "save"
2) "3600 1 300 100 60 10000
#禁用系统的自动快照
[root@ubuntu2004 ~]#vim /apps/redis/etc/redis.conf
save ""
# save 3600 1
# save 300 100
# save 60 10000
2-4-1-2、实现 RDB 方法
save: 同步,不推荐使用，使用主进程完成快照，因此会阻赛其它命令执行
bgsave: 异步后台执行,不影响其它命令的执行，会开启独立的子进程，因此不会阻赛其它命令执行
配置文件实现自动保存: 在配置文件中制定规则,自动执行bgsave
2-4-1-3、RDB 模式的优缺点
RDB 模式优点
RDB快照只保存某个时间点的数据，恢复的时候直接加载到内存即可，不用做其他处理，这种文件适合用于做灾备处理.可以通过自定义时间点执行redis指令bgsave或者save保存快照，实现多个版本的备份
比如: 可以在最近的24小时内，每小时备份一次RDB文件，并且在每个月的每一天，也备份一个RDB文件。这样的话，即使遇上问题，也可以随时将数据集还原到指定的不同的版本。
RDB在大数据集时恢复的速度比AOF方式要快
RDB 模式缺点
不能实时保存数据，可能会丢失自上一次执行RDB备份到当前的内存数据
如果需要尽量避免在服务器故障时丢失数据，那么RDB并不适合。虽然Redis允许设置不同的保存点（save point）来控制保存RDB文件的频率，但是，因为RDB文件需要保存整个数据集的状态，所以它可能并不是一个非常快速的操作。因此一般会超过5分钟以上才保存一次RDB文件。在这种情况下，一旦发生故障停机，就可能会丢失较长时间的数据。
在数据集比较庞大时，fork()子进程可能会非常耗时，造成服务器在一定时间内停止处理客户端请求,如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒或更久。另外子进程完成生成RDB文件的时间也会花更长时间.
2-4-2、AOF
AOF 即 AppendOnlyFile，AOF 和 RDB 都采有COW机制，AOF可以指定不同的保存策略,默认为每秒钟执行一次 fsync,按照操作的顺序将变更命令追加至指定的AOF日志文件尾部
在第一次启用AOF功能时，会做一次完全备份，后续将执行增量性备份，相当于完全数据备份+增量变化
如果同时启用RDB和AOF,进行恢复时,默认AOF文件优先级高于RDB文件,即会使用AOF文件进行恢复
在第一次开启AOF功能时,会自动备份所有数据到AOF文件中,后续只会记录数据的更新指令
注意: AOF 模式默认是关闭的,第一次开启AOF后,并重启服务生效后,会因为AOF的优先级高于RDB,而AOF默认没有数据文件存在,从而导致所有数据丢失
2-4-2-1、AOF 相关配置
appendonly no #是否开启AOF日志记录，默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dump数据的间隔时间)，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。默认不启用此功能
appendfilename "appendonly.aof" #文本文件AOF的文件名，存放在dir指令指定的目录中
appendfsync everysec #aof持久化策略的配置
#no表示由操作系统保证数据同步到磁盘,Linux的默认fsync策略是30秒，最多会丢失30s的数据
#always表示每次写入都执行fsync，以保证数据同步到磁盘,安全性高,性能较差
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据,此为默认值,也生产建议值
dir /path
#rewrite相关
no-appendfsync-on-rewrite yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated ye
2-4-2-2、 AOF rewrite 重写
将一些重复的,可以合并的,过期的数据重新写入一个新的AOF文件,从而节约AOF备份占用的硬盘空间,也能加速恢复过程
可以手动执行bgrewriteaof 触发AOF,第一次开启AOF功能,或定义自动rewrite 策略
AOF rewrite 重写相关配置
#同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形,以下参数实现控制
no-appendfsync-on-rewrite no #在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘IO开支和请求阻塞时间。
#默认为no,表示"不暂缓",新的aof记录仍然会被立即同步到磁盘，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
#为yes,相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？Linux的默认fsync策略是30秒，最多会丢失30s的数据,但由于yes性能较好而且会避免出现阻塞因此比较推荐
#rewrite 即对aof文件进行整理,将空闲空间回收,从而可以减少恢复数据时间
auto-aof-rewrite-percentage 100 #当Aof log增长超过指定百分比例时，重写AOF文件，设置为0表示不自动重写Aof日志，重写是为了使aof体积保持最小，但是还可以确保保存最完整的数据
auto-aof-rewrite-min-size 64mb #触发aof rewrite的最小文件大小
aof-load-truncated yes #是否加载由于某些原因导致的末尾异常的AOF文件(主进程被kill/断电等)，建议yes
2-4-2-3、手动执行AOF重写 BGREWRITEAOF 命令
BGREWRITEAOF
时间复杂度： O(N)， N 为要追加到 AOF 文件中的数据数量。
执行一个 AOF文件 重写操作。重写会创建一个当前 AOF 文件的体积优化版本。
即使 BGREWRITEAOF 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 BGREWRITEAOF 成功之前不会被修改。
重写操作只会在没有其他持久化工作在后台执行时被触发，也就是说：
如果 Redis 的子进程正在执行快照的保存工作，那么 AOF 重写的操作会被预定(scheduled)，等到保存工作完成之后再执行 AOF 重写。在这种情况下， BGREWRITEAOF 的返回值仍然是 OK ，但还会加上一条额外的信息，说明 BGREWRITEAOF 要等到保存操作完成之后才能执行。在 Redis 2.6 或以上的版本，可以使用 INFO [section] 命令查看 BGREWRITEAOF 是否被预定。
如果已经有别的 AOF 文件重写在执行，那么 BGREWRITEAOF 返回一个错误，并且这个新的BGREWRITEAOF 请求也不会被预定到下次执行。
从 Redis 2.4 开始， AOF 重写由 Redis 自行触发， BGREWRITEAOF 仅仅用于手动触发重写操作。
2-4-2-4、AOF 模式优缺点
AOF 模式优点
数据安全性相对较高，根据所使用的fsync策略(fsync是同步内存中redis所有已经修改的文件到存储设备)，默认是appendfsync everysec，即每秒执行一次 fsync,在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据( fsync会在后台线程执行，所以主线程可以继续努力地处理命令请求)
由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中不需要seek, 即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，可以通过 redis-check-aof 工具来解决数据一致性的问题
Redis可以在 AOF文件体积变得过大时，自动地在后台对AOF进行重写,重写后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis在创建新 AOF文件的过程中，append模式不断的将修改数据追加到现有的 AOF文件里面，即使重写过程中发生停机，现有的 AOF文件也不会丢失。而一旦新AOF文件创建完毕，Redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作。
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，也可以通过该文件完成数据的重建
AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此 AOF文件的内容非常容易被人读懂，对文件进行分析(parse)也很轻松。导出（export)AOF文件也非常简单:举个例子，如果不小心执行了FLUSHALL.命令，但只要AOF文件未被重写，那么只要停止服务器，移除 AOF文件末尾的FLUSHAL命令，并重启Redis ,就可以将数据集恢复到FLUSHALL执行之前的状态。
AOF 模式缺点
即使有些操作是重复的也会全部记录，AOF 的文件大小一般要大于 RDB 格式的文件
AOF 在恢复大数据集时的速度比 RDB 的恢复速度要慢
如果 fsync 策略是appendfsync no, AOF保存到磁盘的速度甚至会可能会慢于RDB
bug 出现的可能性更多
2-4-3、RDB和AOF 的选择
如果主要充当缓存功能,或者可以承受较长时间,比如数分钟数据的丢失, 通常生产环境一般只需启用RDB即可,此也是默认值
如果一点数据都不能丢失,可以选择同时开启RDB和AOF
一般不建议只开启AOF
2-5、常用命令
2-5-1、INFO
显示当前节点redis运行状态信息
127.0.0.1:6379> info
# Server
redis_version:7.0.5
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:5fd25d3288e38b6
......
127.0.0.1:6379> info cluster
# Cluster
cluster_enabled:0
2-5-2、SELECT
切换数据库，相当于在MySQL的 USE DBNAME 指令
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> select 10
OK
127.0.0.1:6379[10]> select 0
OK
127.0.0.1:6379>
注意: 在Redis cluster 模式下**不支持多个数据库,**会出现下面错误
127.0.0.1:6379> info cluster
# Cluster
cluster_enabled:1
127.0.0.1:6379> select 0
OK
127.0.0.1:6379> select 1
(error) ERR SELECT is not allowed in cluster mode
2-5-3、KEYS
查看当前库下的所有key，此命令慎用！
2-5-4、BGSAVE
手动在后台执行RDB持久化操作
127.0.0.1:6379[1]> BGSAVE
Background saving started
2-5-5、DBSIZE
返回当前库下的所有key 数量
127.0.0.1:6379> dbsize
(integer) 100002
2-5-6、FLUSHDB
强制清空当前库中的所有key，此命令慎用！
127.0.0.1:6379> dbsize
(integer) 100002
127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> dbsize
(integer) 0
2-5-7、FLUSHALL
强制清空当前Redis服务器所有数据库中的所有key，即删除所有数据，此命令慎用！
#生产建议修改配置使用rename-command禁用此命令
[root@ubuntu2004 ~]#vim /apps/redis/etc/redis.conf
rename-command flushall "" #flushdb和flushall 配置和AOF功能冲突，需要设置 appendonly no
rename-command flushdb ""
[root@ubuntu2004 ~]#systemctl restart redis.service
[root@ubuntu2004 ~]#redis-cli
127.0.0.1:6379> flushall
(error) ERR unknown command 'flushall', with args beginning with:
2-5-8、SHUTDOWN
可用版本： >= 1.0.0
时间复杂度： O(N)，其中 N 为关机时需要保存的数据库键数量。
S
HUTDOWN 命令执行以下操作：
关闭Redis服务,停止所有客户端连接
如果有至少一个保存点在等待，执行 SAVE 命令
如果 AOF 选项被打开，更新 AOF 文件
关闭 redis 服务器(server)
如果持久化被打开的话， SHUTDOWN 命令会保证服务器正常关闭而不丢失任何数据。另一方面，假如只是单纯地执行 SAVE 命令，然后再执行 QUIT 命令，则没有这一保证 —— 因为在执行SAVE 之后、执行 QUIT 之前的这段时间中间，其他客户端可能正在和服务器进行通讯，这时如果执行 QUIT就会造成数据丢失。
#建议关闭此指令
[root@ubuntu2004 ~]#vim /apps/redis/etc/redis.conf
rename-command shutdown "
2-6、Redis 数据类型
2-6-1、 字符串 string
字符串是一种最基本的Redis值类型。Redis字符串是二进制安全的，这意味着一个Redis字符串能包含任意类型的数据，例如： 一张JPEG格式的图片或者一个序列化的Ruby对象。一个字符串类型的值最多能存储512M字节的内容。Redis 中所有 key 都是字符串类型的。此数据类型最为常用
SET key value [EX seconds] [PX milliseconds] [NX|XX]
时间复杂度： O(1)
将字符串值 value 关联到 key 。
如果 key 已经持有其他值， SET 就覆写旧值， 无视类型。
当 SET 命令对一个带有生存时间（TTL）的键进行设置之后， 该键原有的 TTL 将被清除。
从 Redis 2.6.12 版本开始， SET 命令的行为可以通过一系列参数来修改：
EX seconds ： 将键的过期时间设置为 seconds 秒。 执行 SET key value EX seconds 的效果等同于执行 SETEX key seconds value 。
PX milliseconds ： 将键的过期时间设置为 milliseconds 毫秒。 执行 SET key value PX
milliseconds 的效果等同于执行 PSETEX key milliseconds value 。
NX ： 只在键不存在时， 才对键进行设置操作。 执行 SET key value NX 的效果等同于执行 SETNX key value 。
XX ： 只在键已经存在时， 才对键进行设置操作。
2-6-1-1、创建一个key
#注意：Key大小写敏感
127.0.0.1:6379> set kk1 vv1
OK
127.0.0.1:6379> get kk1
"vv1"
127.0.0.1:6379> type kk1 #判断类型
string
127.0.0.1:6379> set kk2 vv2 ex 5 #设置自动过期时间3s
OK
127.0.0.1:6379> setnx tt cc #key不存在,才设置,相当于add
(integer) 1
127.0.0.1:6379> get tt
"cc"
2-6-1-2、查看key的值
127.0.0.1:6379> get tt
"dd"
2-6-1-3、删除key
127.0.0.1:6379> del tt
(integer) 1
2-6-1-4、批量设置多个key
127.0.0.1:6379> mset aa 11 bb 22 cc 33
OK
127.0.0.1:6379> get aa
"11"
127.0.0.1:6379> get bb
"22"
127.0.0.1:6379> get cc
"33"
2-6-1-5、批量获取多个key
127.0.0.1:6379> mget aa bb cc
1) "11"
2) "22"
3) "33"
2-6-1-6、追加key的数据
127.0.0.1:6379> append aa 12
(integer) 4
127.0.0.1:6379> get aa
"1112"
2-6-1-7、设置新值并返回旧值
127.0.0.1:6379> set name wang
OK
127.0.0.1:6379> getset name wange
"wang"
127.0.0.1:6379> get name
"wange"
2-6-1-8、返回字符串 key 对应值的字节数
127.0.0.1:6379> set name li
OK
127.0.0.1:6379> STRLEN name
(integer) 2
127.0.0.1:6379> append name eryou
(integer) 7
127.0.0.1:6379> strlen name
(integer) 7
127.0.0.1:6379> get name
"lieryou"
2-6-1-9、判断 key 是否存在
127.0.0.1:6379> set name wang ex 10 #10秒后自动过期
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> exists name
(integer) 1
127.0.0.1:6379> exists name #10秒后无法查询到
(integer) 0
127.0.0.1:6379> exists age
(integer) 1
2-6-1-10、获取 key 的过期时长
ttl key #查看key的剩余生存时间,如果key过期后,会自动删除
-1 #返回值表示永不过期，默认创建的key是永不过期，重新对key赋值，也会从有剩余生命周期变成永不过期
-2 #返回值表示没有此key
num #key的剩余有效期
127.0.0.1:6379> ttl age
(integer) -1
127.0.0.1:6379> set name wang ex 100
OK
127.0.0.1:6379> ttl name
(integer) 98
127.0.0.1:6379> ttl name
(integer) 96
2-6-1-11、重置key的过期时长
127.0.0.1:6379> expire name 100
(integer) 1
127.0.0.1:6379> ttl name
(integer) 96
2-6-1-12、取消key的期限
127.0.0.1:6379> persist name
(integer) 1
127.0.0.1:6379> ttl name
(integer) -1
2-6-1-13、数字递增
利用INCR命令簇（INCR, DECR, INCRBY,DECRBY)来把字符串当作原子计数器使用。
127.0.0.1:6379> set num 10 #设置初始值
OK
127.0.0.1:6379> incr num
(integer) 11
127.0.0.1:6379> incr num
(integer) 12
127.0.0.1:6379> incr num
(integer) 13
127.0.0.1:6379> incr num
(integer) 14
127.0.0.1:6379> get num
"14"
2-6-1-14、数字递减
127.0.0.1:6379> set num 10
OK
127.0.0.1:6379> decr num
(integer) 9
127.0.0.1:6379> decr num
(integer) 8
127.0.0.1:6379> decr num
(integer) 7
127.0.0.1:6379> get num
"7"
2-6-1-15、数字增加
将key对应的数字加decrement(可以是负数)。如果key不存在，操作之前，key就会被置为0。如果key的value类型错误或者是个不能表示成数字的字符串，就返回错误。这个操作最多支持64位有符号的正型数字。
127.0.0.1:6379> set mykey 10
OK
127.0.0.1:6379> incrby mykey 5
(integer) 15
127.0.0.1:6379> get mykey
"15"
127.0.0.1:6379> incrby mykey -6
(integer) 9
127.0.0.1:6379> get mykey
"9"
2-6-1-16、数字减少
decrby 可以减小数值(也可以增加)
127.0.0.1:6379> set mykey 10
OK
127.0.0.1:6379> decrby mykey 8
(integer) 2
127.0.0.1:6379> get mykey
"2"
127.0.0.1:6379> decrby mykey -20
(integer) 22
127.0.0.1:6379> get mykey
"22"
2-6-2、列表 list
Redis列表就是简单的字符串数组，按照插入顺序排序. 支持双向读写,可以添加一个元素到列表的头部（左边）或者尾部（右边），一个列表最多可以包含2^32-1=4294967295个元素，每个列表元素有下标来标识,下标 0 表示列表的第一个元素，以 1 表示列表的第二个元素，以此类推。 也可以使用负数下标，以 -1 表示列表的最后一个元素， -2 表示列表的倒数第二个元素，元素值可以重复，常用于存入日志等场景，此数据类型比较常用
列表特点
2-6-2-1、创建列表和数据
LPUSH和RPUSH都可以插入列表
LPUSH key value [value ...]
时间复杂度： O(1)
将一个或多个值 value 插入到列表 key 的表头
如果有多个 value 值，那么各个 value 值按从左到右的顺序依次插入到表头： 比如说，对空列表mylist 执行命令 LPUSH mylist a b c ，列表的值将是 c b a ，这等同于原子性地执行 LPUSH mylist a 、 LPUSH mylist b 和 LPUSH mylist c 三个命令。
如果 key 不存在，一个空列表会被创建并执行 LPUSH 操作。
当 key 存在但不是列表类型时，返回一个错误。
RPUSH key value [value ...]
时间复杂度： O(1)
将一个或多个值 value 插入到列表 key 的表尾(最右边)。
如果有多个 value 值，那么各个 value 值按从左到右的顺序依次插入到表尾：比如对一个空列表 mylist 执行 RPUSH mylist a b c ，得出的结果列表为 a b c ，等同于执行命令 RPUSH mylist a 、RPUSH mylist b 、 RPUSH mylist c 。
如果 key 不存在，一个空列表会被创建并执行 RPUSH 操作。
当 key 存在但不是列表类型时，返回一个错误。
#从左边添加数据，已添加的需向右移
127.0.0.1:6379> lpush name wang li he
(integer) 3
127.0.0.1:6379> type name
list
#从右边添加数据
127.0.0.1:6379> rpush course linux python go
(integer) 3
127.0.0.1:6379> type course
list
2-6-2-2、 列表追加新数据
127.0.0.1:6379> lpush list1 tom
(integer) 1
127.0.0.1:6379> rpush list1 jack
(integer) 2
2-6-2-3、获取列表长度(元素个数)
127.0.0.1:6379> llen list1
(integer) 2
2-6-2-4、 获取列表指定位置元素数据
127.0.0.1:6379> lpush list2 a b c
(integer) 3
127.0.0.1:6379> lindex list2 0
"c"
127.0.0.1:6379> lindex list2 1
"b"
127.0.0.1:6379> lindex list2 2
"a"
127.0.0.1:6379> lrange list2 0 2 #所有元素
1) "c"
2) "b"
3) "a"
127.0.0.1:6379> lrange list2 0 -1 #所有元素
1) "c"
2) "b"
3) "a"
127.0.0.1:6379> lrange list2 0 1 #指定范围
1) "c"
2) "b"
2-6-2-5、修改列表指定索引值
127.0.0.1:6379> rpush listkey a b c d e f
(integer) 6
127.0.0.1:6379> lrange listkey 0 -1
1) "a"
2) "b"
3) "c"
4) "d"
5) "e"
6) "f"
127.0.0.1:6379> lset listkey 2 linux
OK
127.0.0.1:6379> lrange listkey 0 -1
1) "a"
2) "b"
3) "linux"
4) "d"
5) "e"
6) "f"
2-6-2-6、 删除列表数据
127.0.0.1:6379> lpush list11 aa bb cc dd
(integer) 4
127.0.0.1:6379> lrange list11 0 -1
1) "dd"
2) "cc"
3) "bb"
4) "aa"
127.0.0.1:6379> lpop list11 #弹出左边第一个元素，即删除第一个
"dd"
127.0.0.1:6379> lrange list11 0 -1
1) "cc"
2) "bb"
3) "aa"
127.0.0.1:6379> rpop list11 #弹出右边第一个元素，即删除最后一个
"aa"
127.0.0.1:6379> lrange list11 0 -1
1) "cc"
2) "bb"
#LTRIM 对一个列表进行修剪(trim)，让列表只保留指定区间内的元素，不在指定区间之内的元素都将被删除
127.0.0.1:6379> rpush listall aa bb cc dd ee ff
(integer) 6
127.0.0.1:6379> lrange listall 0 -1
1) "aa"
2) "bb"
3) "cc"
4) "dd"
5) "ee"
6) "ff"
127.0.0.1:6379> ltrim listall 1 3 #只保留1，2号元素
OK
127.0.0.1:6379> llen listall
(integer) 3
127.0.0.1:6379> lrange listall 0 -1
1) "bb"
2) "cc"
3) "dd"
2-6-2-7、删除list
127.0.0.1:6379> del listall
(integer) 1
127.0.0.1:6379> exists listall
(integer) 0
2-6-3、集合 set
Set 是一个无序的字符串合集，同一个集合中的每个元素是唯一无重复的，支持在两个不同的集合中对数据进行逻辑处理，常用于取交集,并集,统计等场景,例如: 实现共同的朋友
集合特点
2-6-3-1、创建集合
127.0.0.1:6379> sadd set1 v1
(integer) 1
127.0.0.1:6379> sadd set2 v2 v4
(integer) 2
127.0.0.1:6379> type set1
set
127.0.0.1:6379> type set2
set
2-6-3-2、集合中追加数据
#追加时，只能追加不存在的数据，不能追加已经存在的数值
127.0.0.1:6379> sadd set1 v2 v3 v4
(integer) 3
127.0.0.1:6379> sadd set2 v2 #已存在的value,无法再次添加
(integer) 0
2-6-3-3、获取集合的所有数据
127.0.0.1:6379> smembers set2
1) "v4"
2) "v2"
127.0.0.1:6379> smembers set1
1) "v4"
2) "v1"
3) "v2"
4) "v3"
2-6-3-4、删除集合中的元素
127.0.0.1:6379> sadd hobby girl house car
(integer) 3
127.0.0.1:6379> srem hobby car
(integer) 1
127.0.0.1:6379> smembers hobby
1) "girl"
2) "house"
2-6-3-5、取集合的交集
交集：同时属于集合A且属于集合B的元素
可以实现共同的朋友
127.0.0.1:6379> sinter set1 set2
1) "v4"
2) "v2"
2-6-3-6、取集合的并集
并集：属于集合A或者属于集合B的元素
127.0.0.1:6379> sunion set1 set2
1) "v2"
2) "v3"
3) "v4"
4) "v1"
2-6-3-7、取集合的差集
差集：属于集合A但不属于集合B的元素
可以实现我的朋友的朋友
127.0.0.1:6379> sdiff set1 set2
1) "v1"
2) "v3"
2-6-4、有序集合 sorted set
Redis有序集合和Redis集合类似，是不包含相同字符串的合集。它们的差别是，每个有序集合的成员都关联着一个双精度浮点型的评分，这个评分用于把有序集合中的成员按最低分到最高分排序。有序集合的成员不能重复,但评分可以重复,一个有序集合中最多的成员数为 2^32 - 1=4294967295个，经常用于排行榜的场景
有序集合特点
- 有序
- 无重复元素
- 每个元素是由score和value组成
- score 可以重复
- value 不可以重复
2-6-4-1、创建有序集合
127.0.0.1:6379> zadd ww 1 v1 #分数为1，分数可重复，元素值不可以重复
(integer) 1
127.0.0.1:6379> zadd ww 2 v2
(integer) 1
127.0.0.1:6379> zadd ww 3 v3
(integer) 1
127.0.0.1:6379> zadd ww 4 v5
(integer) 1
127.0.0.1:6379> type ww
zset
127.0.0.1:6379> zadd wl 1 v1 2 v2 3 v3 4 v4 #一次生成多个数据
(integer) 4
127.0.0.1:6379> type wl
zset
2-6-4-2、实现排名
127.0.0.1:6379> zadd sala 300 jn 800 yt 1000 bj 6000 zjl 15000 pazg 22000 tsk
(integer) 6
127.0.0.1:6379> zrange sala 0 -1 #正序排序后显示集合内所有的key,按score从小到大显示
1) "jn"
2) "yt"
3) "bj"
4) "zjl"
5) "pazg"
6) "tsk"
127.0.0.1:6379> zrevrange sala 0 -1 #倒序排序后显示集合内所有的key,score从大到小显示
1) "tsk"
2) "pazg"
3) "zjl"
4) "bj"
5) "yt"
6) "jn"
127.0.0.1:6379> zrange sala 0 -1 withscores 正序显示指定集合内所有key和得分情况
1) "jn"
2) "300"
3) "yt"
4) "800"
5) "bj"
6) "1000"
7) "zjl"
8) "6000"
9) "pazg"
10) "15000"
11) "tsk"
12) "22000"
127.0.0.1:6379> zrevrange sala 0 -1 withscores #倒序显示指定集合内所有key和得分情况
1) "tsk"
2) "22000"
3) "pazg"
4) "15000"
5) "zjl"
6) "6000"
7) "bj"
8) "1000"
9) "yt"
10) "800"
11) "jn"
12) "300"
2-6-4-3、查看集合的成员个数
127.0.0.1:6379> zcard sala
(integer) 6
2-6-4-4、基于索引查找数据
127.0.0.1:6379> zrange sala 0 2
1) "jn"
2) "yt"
3) "bj"
127.0.0.1:6379> zrange sala 0 10
1) "jn"
2) "yt"
3) "bj"
4) "zjl"
5) "pazg"
6) "tsk"
127.0.0.1:6379> zrange sala 4 6
1) "pazg"
2) "tsk"
2-6-4-5、查询指定数据的排名
127.0.0.1:6379> zrank sala tsk
(integer) 5
127.0.0.1:6379> zrank sala pazg
(integer) 4
2-6-4-6、获取分数
127.0.0.1:6379> zscore sala tsk
"22000"
2-6-4-7、删除元素
127.0.0.1:6379> zrem sala pazg zjl
(integer) 2
127.0.0.1:6379> zrange sala 0 -1
1) "jn"
2) "yt"
3) "bj"
4) "tsk"
2-6-5、哈希 hash
hash 即字典, 用于保存字符串字段field和字符串值value之间的映射，即key/value做为数据部分,hash特别适合用于存储对象场景.
一个hash最多可以包含2^32-1 个key/value键值对
哈希特点
2-6-5-1、创建 hash
HSET hash field value
时间复杂度： O(1)
将哈希表 hash 中域 field 的值设置为 value 。
如果给定的哈希表并不存在， 那么一个新的哈希表将被创建并执行 HSET 操作。
如果域 field 已经存在于哈希表中， 那么它的旧值将被新值 value 覆盖。
127.0.0.1:6379> hset huaan serial 9527 gender man age 36
(integer) 3
127.0.0.1:6379> hgetall huaan #查看所有字段的值
1) "serial"
2) "9527"
3) "gender"
4) "man"
5) "age"
6) "36"
127.0.0.1:6379> hset huaan salary 22000 #增加字段
(integer) 1
127.0.0.1:6379> hgetall huaan
1) "serial"
2) "9527"
3) "gender"
4) "man"
5) "age"
6) "36"
7) "salary"
8) "22000"
2-6-5-2、查看hash的指定field的value
127.0.0.1:6379> hget huaan age
"36"
127.0.0.1:6379> hmget huaan serial salary #获取多个值
1) "9527"
2) "22000"
2-6-5-3、删除hash 的指定的 field/value
127.0.0.1:6379> hdel huaan serial
(integer) 1
127.0.0.1:6379> hgetall huaan
1) "gender"
2) "man"
3) "age"
4) "36"
5) "salary"
6) "22000"
2-6-5-4、批量设置hash key的多个field和value
127.0.0.1:6379> hmset huaan name xiaoshutong serial 9527 city zjk
OK
127.0.0.1:6379> hgetall huaan
1) "gender"
2) "man"
3) "age"
4) "36"
5) "salary"
6) "22000"
7) "name"
8) "xiaoshutong"
9) "serial"
10) "9527"
11) "city"
12) "zjk"
2-6-5-5、查看hash指定field的value
127.0.0.1:6379> hmget huaan name age
1) "xiaoshutong"
2) "36"
2-6-5-6、查看hash的所有field
127.0.0.1:6379> hkeys huaan
1) "gender"
2) "age"
3) "salary"
4) "name"
5) "serial"
6) "city"
2-6-5-7、查看hash 所有value
127.0.0.1:6379> hvals huaan
1) "man"
2) "36"
3) "22000"
4) "xiaoshutong"
5) "9527"
6) "zjk"
2-6-5-8、查看指定 hash的所有field及value
127.0.0.1:6379> hgetall huaan
1) "gender"
2) "man"
3) "age"
4) "36"
5) "salary"
6) "22000"
7) "name"
8) "xiaoshutong"
9) "serial"
10) "9527"
11) "city"
12) "zjk"
2-6-5-9、 删除 hash
127.0.0.1:6379> del huaan
(integer) 1
2-7、消息队列
消息队列: 把要传输的数据放在队列中,从而实现应用之间的数据交换
常用功能: 可以实现多个应用系统之间的解耦,异步,削峰/限流等
常用的消息队列应用: Kafka,RabbitMQ,Redis
消息队列分为两种
生产者/消费者模式: Producer/Consumer
发布者/订阅者模式: Publisher/Subscriber
2-7-1、生产者消费者模式
生产者消费者模式下，多个消费者同时监听一个频道(redis用队列实现)，但是生产者产生的一个消息只能被最先抢到消息的一个消费者消费一次,队列中的消息可以由多个生产者写入，也可以有不同的消费者取出进行消费处理.此模式应用广泛
2-7-1-1、生产者生成消息
127.0.0.1:6379> lpush chan message1 #从管道的左侧写入
(integer) 1
127.0.0.1:6379> lpush chan message2 messages3 messages4
(integer) 4
2-7-1-2、获取所有消息
127.0.0.1:6379> lrange chan 0 -1
1) "messages4"
2) "messages3"
3) "message2"
4) "message1"
2-7-1-3、消费者消费消息
127.0.0.1:6379> lpop chan 1
1) "messages4"
127.0.0.1:6379> lpop chan
"messages3"
127.0.0.1:6379> lpop chan
"message2"
127.0.0.1:6379> lpop chan
"message1"
2-7-1-4、验证队列消息消费完成
127.0.0.1:6379> lrange chan 0 -1
(empty array)
2-7-2、发布者订阅模式
在发布者订阅者Publisher/Subscriber模式下，发布者Publisher将消息发布到指定的频道channel，事先监听此channel的一个或多个订阅者Subscriber都会收到相同的消息。即一个消息可以由多个订阅者获取到. 对于社交应用中的群聊、群发、群公告等场景适用于此模式
2-7-2-1、订阅者订阅频道
127.0.0.1:6379> subscribe channel #订阅者事先订阅指定的频道，之后发布的消息才能收到
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel"
3) (integer) 1
2-7-2-2、发布者发布消息
127.0.0.1:6379> PUBLISH channel hello
(integer) 1
127.0.0.1:6379> PUBLISH channel 'my name is huaan'
(integer) 1
127.0.0.1:6379>
2-7-2-3、各个订阅者都能收到消息
127.0.0.1:6379> subscribe channel
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel"
3) (integer) 1
1) "message"
2) "channel"
3) "hello"
1) "message"
2) "channel"
3) "my name is huaan"
2-7-2-4、订阅多个频道
127.0.0.1:6379> SUBSCRIBE channel1 channel2 channel
2-7-2-5、订阅所有频道
127.0.0.1:6379> SUBSCRIBE * #支持通配符*
2-7-2-6、订阅匹配的频道
127.0.0.1:6379> SUBSCRIBE chen* #匹配订阅多个频道
2-7-2-7、取消订阅频道
127.0.0.1:6379> UNSUBSCRIBE chennel1
3、Redis 集群与高可用
Redis单机服务存在数据和服务的单点问题,而且单机性能也存在着上限,可以利用Redis的集群相关技术来解决这些问题.
3-1、Redis 主从复制
主从模式（master/slave），和MySQL的主从模式类似,可以实现Redis数据的跨主机的远程备份。
常见客户端连接主从的架构:
程序APP先连接到高可用性 LB 集群提供的虚拟IP，再由LB调度将用户的请求至后端Redis 服务器来真正提供服务
主从复制特点
- 一个master可以有多个slave
- 一个slave只能有一个master
- 数据流向是从master到slave单向的
- master 可读可写
- slave 只读
3-1-1、主从复制实现
当master出现故障后,可以会提升一个slave节点变成新的Mster,因此Redis Slave 需要设置和master相同的连接密码，此外当一个Slave提升为新的master 通过持久化实现数据的恢复
当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。否则的话，由于延迟等问题，部署的主节点Redis服务应该要避免自动启动。
注意：导致主从服务器数据全部丢失
1.假设节点A为主服务器，并且关闭了持久化。并且节点B和节点C从节点A复制数据
2.节点A崩溃，然后由自动拉起服务重启了节点A.由于节点A的持久化被关闭了，所以重启之后没有任何数据
3.节点B和节点C将从节点A复制数据，但是A的数据是空的，于是就把自身保存的数据副本删除。
在关闭主服务器上的持久化，并同时开启自动拉起进程的情况下，即便使用Sentinel来实现Redis的高可用性，也是非常危险的。因为主服务器可能拉起得非常快，以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启，然后还是会执行上面的数据丢失的流程。无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动启动。
3-1-1-1、启用主从同步
Redis Server 默认为 master节点，如果要配置为从节点,需要指定master服务器的IP,端口及连接密码
在从节点执行 REPLICAOF MASTER_IP PORT 指令可以启用主从同步复制功能,早期版本使用 SLAVEOF指令
127.0.0.1:6379> REPLICAOF MASTER_IP PORT #新版推荐使用
127.0.0.1:6379> SLAVEOF MasterIP Port #旧版使用，将被淘汰
127.0.0.1:6379> CONFIG SET masterauth <masterpass>
#redis-master（10.0.0.101）：
127.0.0.1:6379> keys *
1) "key3"
2) "key2"
3) "key1"
127.0.0.1:6379> get key1
"v1-master"
======================================================================
#redis-slave(10.0.0.18、10.0.0.28):
[root@rocky8 ~]#redis-cli
127.0.0.1:6379> info
NOAUTH Authentication required.
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> REPLICAOF 10.0.0.101 6379 #在slave上设置master的IP和端口，4.0版之前的指令为slaveof
OK
127.0.0.1:6379> CONFIG SET masterauth 123456 #在slave上设置master的密码，才可以同步
OK
127.0.0.1:6379> info replication
# Replication
role:slave ##角色变为slave
master_host:10.0.0.101
master_port:6379
master_link_status:up #注意，版本如果不一致，状态一直是down
......
127.0.0.1:6379> keys * ##查看已经同步成功
1) "key2"
2) "key1"
3) "key3"
127.0.0.1:6379> get key1
"v1-master"
127.0.0.1:6379> set key4 11111 #Slave节点为只读状态, 不支持写入
(error) READONLY You can't write against a read only replica.
======================================================================
#redis-master（10.0.0.101）：
127.0.0.1:6379> info replication ##在master上可以看到所有slave信息
# Replication
role:master
connected_slaves:2
slave0:ip=10.0.0.18,port=6379,state=online,offset=3809,lag=0
slave1:ip=10.0.0.28,port=6379,state=online,offset=3809,lag=0
......
# 修改slave节点配置文件
#redis-slave(10.0.0.18、10.0.0.28):
[root@rocky8 ~]#vim /apps/redis/etc/redis.conf
......
# replicaof <masterip> <masterport>
replicaof 10.0.0.101 6379
......
# masterauth <master-password>
masterauth 123456
......
3-1-1-2、删除主从同步
#redis-slave(10.0.0.18、10.0.0.28):
127.0.0.1:6379> REPLICAOF no one #取消复制,在slave上执行REPLICAOF NO ONE,会断开和master的连接不再主从复制, 但不会清除slave上已有的数据
OK
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
3-1-2、主从复制故障恢复
3-1-2-1、主从复制故障恢复过程介绍
当 slave 节点故障时，将Redis Client指向另一个 slave 节点即可,并及时修复故障从节点
当 master 节点故障时，需要提升slave为新的master
master故障后，只能手动提升一个slave为新master，不支持自动切换。
之后将其它的slave节点重新指定新的master为master节点
Master的切换会导致master_replid发生变化，slave之前的master_replid就和当前master不一致从而会引发所有 slave的全量同步。
3-1-2-2、主从复制故障恢复实现
#停止slave同步并提升为新的master
#将当前 slave 节点提升为 master 角色
127.0.0.1:6379> REPLICAOF no one
OK
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
......
127.0.0.1:6379> set key4 444 #测试能否写入数据
OK
#修改所有slave 指向新的master节点:
127.0.0.1:6379> SLAVEOF 10.0.0.18 6379 ##修改10.0.0.28节点指向新的master节点10.0.0.18
OK
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:10.0.0.18
master_port:6379
master_link_status:up
##在新master节点10.0.0.18上查看状态:
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=10.0.0.28,port=6379,state=online,offset=4984,lag=1
3-1-3、实现 Redis 的级联复制
master和slave1节点无需修改,只需要修改slave2及slave3指向slave1做为mater即可
#在slave2和slave3上执行下面指令
127.0.0.1:6379> REPLICAOF 10.0.0.28 6379
OK
127.0.0.1:6379> config set masterauth 123456
OK
127.0.0.1:6379> info replication
role:slave
master_host:10.0.0.28
master_port:6379
master_link_status:up
......
##在master新建key
127.0.0.1:6379> set key6 666
OK
127.0.0.1:6379> keys *
1) "key1"
2) "key6"
3) "key5"
4) "key4"
5) "key3"
6) "key2"
#在slave1和slave2验证key
127.0.0.1:6379> keys *
1) "key4"
2) "key3"
3) "key5"
4) "key2"
5) "key6"
6) "key1"
127.0.0.1:6379> get key6
"666"
#在中间那个slave1查看状态
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:10.0.0.18
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10 #最近一次与master通信已经过去多少秒。
master_sync_in_progress:0 #是否正在与master通信。
slave_read_repl_offset:7241
slave_repl_offset:7241 #当前同步的偏移量
slave_priority:100 #slave优先级，master故障后值越小越优先同步
slave_read_only:1
replica_announced:1
connected_slaves:2
slave0:ip=10.0.0.101,port=6379,state=online,offset=7241,lag=0 #slave的slave节点
slave1:ip=10.0.0.102,port=6379,state=online,offset=7241,lag=0
3-1-4、主从复制优化
Redis主从复制分为全量同步和增量同步
Redis 的主从同步是非阻塞的，即同步过程不会影响主服务器的正常访问.
3-1-4-1、全量复制过程
- 主从节点建立连接,验证身份后,从节点向主节点发送PSYNC(2.8版本之前是SYNC)命令
- 主节点向从节点发送FULLRESYNC命令,包括runID和offset
- 从节点保存主节点信息
- 主节点执行BGSAVE保存RDB文件,同时记录新的记录到buffer中
- 主节点发送RDB文件给从节点
- 主节点将新收到buffer中的记录发送至从节点
- 从节点删除本机的旧数据
- 从节点加载RDB
- 从节点同步主节点的buffer信息
3-1-4-2、增量复制过程
在主从复制首次完成全量同步之后再次需要同步时,从服务器只要发送当前的offset位置(类似于MySQL的binlog的位置)给主服务器，然后主服务器根据相应的位置将之后的数据(包括写在缓冲区的积压数据)发送给从服务器,再次将其保存到从节点内存即可。
即首次全量复制,之后的复制基本增量复制实现
3-1-4-3、主从同步完整过程
主从同步完整过程如下：
- slave发起连接master，验证通过后,发送PSYNC命令
- master接收到PSYNC命令后，执行BGSAVE命令将全部数据保存至RDB文件中,并将后续发生的写操作记录至buffer中
- master向所有slave发送RDB文件
- master向所有slave发送后续记录在buffer中写操作
- slave收到快照文件后丢弃所有旧数据
- slave加载收到的RDB到内存
- slave 执行来自master接收到的buffer写操作
- 当slave完成全量复制后,后续master只会先发送slave_repl_offset信息
- 以后slave比较自身和master的差异,只会进行增量复制的数据即可
复制缓冲区(环形队列)配置参数：
#master的写入数据缓冲区，用于记录自上一次同步后到下一次同步过程中间的写入命令，计算公式：repl-backlog-size = 允许从节点最大中断时长 * 主实例offset每秒写入量，比如:master每秒最大写入64mb，最大允许60秒，那么就要设置为64mb*60秒=3840MB(3.8G),建议此值是设置的足够大
repl-backlog-size 1mb
#如果一段时间后没有slave连接到master，则backlog size的内存将会被释放。如果值为0则表示永远不释放这部份内存。
repl-backlog-ttl 3600
3-1-5-4、避免全量复制
第一次全量复制不可避免,后续的全量复制可以利用小主节点(内存小),业务低峰时进行全量
节点运行ID不匹配:主节点重启会导致RUNID变化,可能会触发全量复制,可以利用故障转移，例如哨兵或集群,而从节点重启动,不会导致全量复制
复制积压缓冲区不足: 当主节点生成的新数据大于缓冲区大小,从节点恢复和主节点连接后,会导致全量复制.解决方法将repl-backlog-size 调大
3-1-5-5、避免复制风暴
- 单主节点复制风暴
- 当主节点重启，多从节点复制
- 解决方法:更换复制拓扑
- 单机器多实例复制风暴
机器宕机后，大量全量复制
解决方法:主节点分散多机器
3-1-5-6、主从同步优化配置
Redis在2.8版本之前没有提供增量部分复制的功能，当网络闪断或者slave Redis重启之后会导致主从之间的全量同步，即从2.8版本开始增加了部分复制的功能。
性能相关配置
repl-diskless-sync no # 是否使用无盘方式进行同步RDB文件，默认为no，no表示不使用无盘，需要将RDB文件保存到磁盘后再发送给slave，yes表示使用无盘，即RDB文件不需要保存至本地磁盘，而且直接通过网络发送给slave
repl-diskless-sync-delay 5 #无盘时复制的服务器等待的延迟时间
repl-ping-slave-period 10 #slave向master发送ping指令的时间间隔，默认为10s
repl-timeout 60 #指定ping连接超时时间,超过此值无法连接,master_link_status显示为down状态,并记录错误日志
repl-disable-tcp-nodelay no #是否启用TCP_NODELAY
#设置成yes，则redis会合并多个小的TCP包成一个大包再发送,此方式可以节省带宽，但会造成同步延迟时长的增加，导致master与slave数据短期内不一致
#设置成no，则master会立即同步数据
repl-backlog-size 1mb #master的写入数据缓冲区，用于记录自上一次同步后到下一次同步前期间的写入命令，计算公式：repl-backlog-size = 允许slave最大中断时长 * master节点offset每秒写入量，如:master每秒最大写入量为32MB，最长允许中断60秒，就要至少设置为32*60=1920MB,建议此值是设置的足够大,如果此值太小,会造成全量复制
repl-backlog-ttl 3600 #指定多长时间后如果没有slave连接到master，则backlog的内存数据将会过期。如果值为0表示永远不过期。
slave-priority 100 #slave参与选举新的master的优先级，此整数值越小则优先级越高。当master故障时将会按照优先级来选择slave端进行选举新的master，如果值设置为0，则表示该slave节点永远不会被选为master节点。
min-replicas-to-write 1 #指定master的可用slave不能少于个数，如果少于此值,master将无法执行写操作,默认为0,生产建议设为1,
min-slaves-max-lag 20 #指定至少有min-replicas-to-write数量的slave延迟时间都大于此秒数时，master将不能执行写操作
3-1-5、 常见主从复制故障
3-1-5-1、主从硬件和软件配置不一致
主从节点的maxmemory不一致,主节点内存大于从节点内存,主从复制可能丢失数据
rename-command 命令不一致,如在主节点启用flushdb,从节点禁用此命令,结果在master节点执行flushdb后,导致slave节点不同步
#在从节点定义rename-command flushall "",但是在主节点没有此配置,则当在主节点执行flushall时,会在从节点提示下面同步错误
10822:S 16 Oct 2020 20:03:45.291 # == CRITICAL == This replica is sending an error to its master: 'unknown command `flushall`, with args beginning with: 'after processing the command '<unknown>'
#master有一个rename-command flushdb "wang",而slave没有这个配置,则同步时从节点可以看到以下同步错误
3181:S 21 Oct 2020 17:34:50.581 # == CRITICAL == This replica is sending an error to its master: 'unknown command `wang`, with args beginning with: ' afterprocessing the command '<unknown>'
3-1-5-2、master密码错误
如果slave节点配置的master密码错误，导致验证不通过,自然将无法建立主从同步关系。
# tail -f /var/log/redis/redis.log
Unable to AUTH to MASTER: -ERR invalid password
3-1-5-3、Redis版本不一致
不同的redis 版本之间尤其是大版本间可能会存在兼容性问题，如：Redis 3,4,5,6之间
因此主从复制的所有节点应该使用相同的版本
3-1-5-4、 安全模式下无法远程连接
如果开启了安全模式，并且没有设置bind地址和密码,会导致无法远程连接
3-2、Redis 哨兵 Sentinel
主从架构和MySQL的主从复制一样,无法实现master和slave角色的自动切换，即当master出现故障时,不能实现自动的将一个slave 节点提升为新的master节点,即主从复制无法实现自动的故障转移功能,如果想实现转移,则需要手动修改配置,才能将 slave 服务器提升新的master节点.此外只有一个主节点支持写操作,所以业务量很大时会导致Redis服务性能达到瓶颈
需要解决的主从复制以下存在的问题：
- master和slave角色的自动切换，且不能影响业务
- 提升Redis服务整体性能，支持更高并发访问
专门的Sentinel 服务进程是用于监控redis集群中Master工作的状态，当Master主服务器发生故障的时候，可以实现Master和Slave的角色的自动切换，从而实现系统的高可用性
Sentinel是一个分布式系统,即需要在多个节点上各自同时运行一个sentinel进程，Sentienl 进程通过流言协议(gossip protocols)来接收关于Master是否下线状态，并使用投票协议(Agreement Protocols)来决定是否执行自动故障转移,并选择合适的Slave作为新的Master
每个Sentinel进程会向其它Sentinel、Master、Slave定时发送消息，来确认对方是否存活，如果发现某个节点在指定配置时间内未得到响应，则会认为此节点已离线，即为主观宕机Subjective Down，简称为 SDOWN
如果哨兵集群中的多数Sentinel进程认为Master存在SDOWN，共同利用 is-master-down-by-addr 命令互相通知后，则认为客观宕机Objectively Down， 简称 ODOWN
接下来利用投票算法，从所有slave节点中，选一台合适的slave将之提升为新Master节点，然后自动修改其它slave相关配置，指向新的master节点,最终实现故障转移failover
Redis Sentinel中的Sentinel节点个数应该为大于等于3且最好为奇数
客户端初始化时连接的是Sentinel节点集合，不再是具体的Redis节点，即 Sentinel只是配置中心不是代理。
Redis Sentinel 节点与普通 Redis 没有区别,要实现读写分离依赖于客户端程序
Sentinel 机制类似于MySQL中的MHA功能,只解决master和slave角色的自动故障转移问题，但单个Master 的性能瓶颈问题并没有解决
Redis 3.0 之前版本中,生产环境一般使用哨兵模式较多,Redis 3.0后推出Redis cluster功能,可以支持更大规模的高并发环境
3-2-1、Sentinel中的三个定时任务
每10 秒每个sentinel 对master和slave执行info
发现slave节点
确认主从关系
每2秒每个sentinel通过master节点的channel交换信息(pub/sub)
通过sentinel__:hello频道交互
交互对节点的“看法”和自身信息
每1秒每个sentinel对其他sentinel和redis执行ping
3-2-2、实现哨兵架构
哨兵的前提是已经实现了Redis的主从复制
注意: master 的配置文件中masterauth 和slave 都必须相同
3-2-2-1、环境准备
#所有slave节点：
[root@ubuntu2004 ~]#vim /apps/redis/etc/redis.conf
......
replicaof 10.0.0.18 6379
.....
masterauth 123456
......
[root@ubuntu2004 ~]#systemctl restart redis.service
3-2-2-2、master节点查看状态
[root@rocky8 ~]#redis-cli
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.0.0.28,port=6379,state=online,offset=9901,lag=0
slave1:ip=10.0.0.102,port=6379,state=online,offset=9901,lag=0
3-2-2-3、哨兵配置说明
# sentinel配置说明：
Sentinel实际上是一个特殊的redis服务器,有些redis指令支持,但很多指令并不支持.默认监听在26379/tcp端口.
哨兵服务可以和Redis服务器分开部署在不同主机，但为了节约成本一般会部署在一起
#所有redis节点使用相同的以下示例的配置文件
#如果是编译安装，在源码目录有sentinel.conf，复制到安装目录即可，
[root@rocky8 ~]#cp /usr/local/src/redis-7.0.5/sentinel.conf /apps/redis/etc/
bind 0.0.0.0
port 26379
daemonize yes
pidfile "redis-sentinel.pid"
logfile "sentinel_26379.log"
dir "/tmp" #工作目录
sentinel monitor mymaster 10.0.0.8 6379 2
#mymaster是集群的名称，此行指定当前mymaster集群中master服务器的地址和端口
#2为法定人数限制(quorum)，即有几个sentinel认为master down了就进行故障转移，一般此值是所有sentinel节点(一般总数是>=3的 奇数,如:3,5,7等)的一半以上的整数值，比如，总数是3，即3/2=1.5，取整为2,是master的ODOWN客观下线的依据
sentinel auth-pass mymaster 123456
#mymaster集群中master的密码，注意此行要在上面行的下面
sentinel down-after-milliseconds mymaster 30000
#判断mymaster集群中所有节点的主观下线(SDOWN)的时间，单位：毫秒，建议3000
sentinel parallel-syncs mymaster 1
#发生故障转移后，可以同时向新master同步数据的slave的数量，数字越小总同步时间越长，但可以减轻新master的负载压力
sentinel failover-timeout mymaster 180000
#所有slaves指向新的master所需的超时时间，单位：毫秒
sentinel deny-scripts-reconfig yes #禁止修改脚本
logfile /var/log/redis/sentinel.log
3-2-2-4、编辑哨兵配置
[root@rocky8 ~]#egrep -v "^#|^$" /apps/redis/etc/sentinel.conf
protected-mode no
port 26379
daemonize no
pidfile "/apps/redis/run/redis-sentinel.pid"
logfile "/apps/redis/log/redis-sentinel.log"
dir /tmp
sentinel monitor mymaster 10.0.0.18 6379 2
sentinel auth-pass mymaster 123456
sentinel down-after-milliseconds mymaster 3000
acllog-max-len 128
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes
SENTINEL resolve-hostnames no
SENTINEL announce-hostnames no
SENTINEL master-reboot-down-after-period mymaster 0
[root@rocky8 ~]#chown -R redis.redis /apps/redis/etc/sentinel.conf #注意目录权限,否则无法启动服务
[root@rocky8 ~]#chown -R redis.redis /apps/redis
#测试开启哨兵服务
[root@rocky8 ~]#/apps/redis/bin/redis-sentinel /apps/redis/etc/sentinel.conf
3-2-2-5、编辑哨兵service文件
[root@rocky8 ~]#vim /lib/systemd/system/redis-sentinel.service
[Unit]
Description=Redis Sentinel
After=network.target
[Service]
ExecStart=/apps/redis/bin/redis-sentinel /apps/redis/etc/sentinel.conf --supervised systemd
ExecStop=/bin/kill -s QUIT $MAINPID
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755
[Install]
WantedBy=multi-user.targe
[root@rocky8 ~]#systemctl daemon-reload
[root@rocky8 ~]#systemctl start sentinel.service
[root@rocky8 ~]#systemctl status redis-sentinel.service
[root@rocky8 ~]#ss -ntlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 0.0.0.0:26379 0.0.0.0:* users:(("redis-sentinel",pid=10117,fd=6))
3-2-2-6、验证哨兵服务
[root@rocky8 ~]#ss -ntlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 0.0.0.0:6379 0.0.0.0:* users:(("redis-server",pid=10741,fd=6))
LISTEN 0 511 0.0.0.0:26379 0.0.0.0:* users:(("redis-sentinel",pid=10736,fd=6))
[root@rocky8 ~]#tail -f /apps/redis/log/redis-sentinel.log
[root@rocky8 ~]#redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_tilt_since_seconds:-1
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=10.0.0.18:6379,slaves=3,sentinels=4 #3个slave,四个sentinel服务器,如果sentinels值不符合,检查myid可能冲突
3-2-2-7、停止Master 实现故障转移
#停止 Master 节点
[root@rocky8 ~]#killall redis-server
#故障转移时sentinel的信息
[root@rocky8 ~]#tail -f /apps/redis/log/redis-sentinel.log
10736:X 29 Oct 2022 22:54:57.069 * +slave-reconf-sent slave 10.0.0.102:6379 10.0.0.102 6379 @ mymaster 10.0.0.18 6379
10736:X 29 Oct 2022 22:54:57.783 * +slave-reconf-inprog slave 10.0.0.102:6379 10.0.0.102 6379 @ mymaster 10.0.0.18 6379
10736:X 29 Oct 2022 22:54:57.783 * +slave-reconf-done slave 10.0.0.102:6379 10.0.0.102 6379 @ mymaster 10.0.0.18 6379
10736:X 29 Oct 2022 22:54:57.855 # +failover-end master mymaster 10.0.0.18 6379
10736:X 29 Oct 2022 22:54:57.855 # +switch-master mymaster 10.0.0.18 6379 10.0.0.101 6379
10736:X 29 Oct 2022 22:54:57.855 * +slave slave 10.0.0.28:6379 10.0.0.28 6379 @ mymaster 10.0.0.101 6379
10736:X 29 Oct 2022 22:54:57.855 * +slave slave 10.0.0.102:6379 10.0.0.102 6379 @ mymaster 10.0.0.101 6379
10736:X 29 Oct 2022 22:54:57.855 * +slave slave 10.0.0.18:6379 10.0.0.18 6379 @ mymaster 10.0.0.101 6379
10736:X 29 Oct 2022 22:54:57.856 * Sentinel new configuration saved on disk
10736:X 29 Oct 2022 22:55:00.902 # +sdown slave 10.0.0.18:6379 10.0.0.18 6379 @ mymaster 10.0.0.101 6379
#查看各节点上哨兵信息
[root@rocky8 ~]#redis-cli -a 123456 -p 26379
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
AUTH failed: ERR AUTH <password> called without any password configured for the default user. Are you sure your configuration is correct?
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_tilt_since_seconds:-1
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=10.0.0.101:6379,slaves=3,sentinels=4
3-2-2-8、验证故障转移
#故障转移后redis.conf中的replicaof行的master IP会被修改
[root@rocky8 ~]#grep ^replicaof /apps/redis/etc/redis.conf
replicaof 10.0.0.101 6379
#哨兵配置文件的sentinel monitor IP 同样也会被修改
[root@rocky8 ~]#grep "sentinel monitor mymaster" /apps/redis/etc/sentinel.conf
sentinel monitor mymaster 10.0.0.101 6379 2
3-2-2-9、验证 Redis 各节点状态
#新的master 状态
127.0.0.1:6379> info replication
# Replication
role:master #提升为master
connected_slaves:2
slave0:ip=10.0.0.28,port=6379,state=online,offset=202307,lag=1
slave1:ip=10.0.0.102,port=6379,state=online,offset=202307,lag=0
#slave指向新的master
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:10.0.0.101 #指向新的master
3-2-2-10、其他-Sentinel 运维
手动让主节点下线
127.0.0.1:26379> sentinel failover <masterName>
3-3、Redis Cluster
使用哨兵sentinel 只能解决Redis高可用问题，实现Redis的自动故障转移,但仍然无法解决Redis Master单节点的性能瓶颈问题
为了解决单机性能的瓶颈，提高Redis 服务整体性能，可以使用分布式集群的解决方案
早期 Redis 分布式集群部署方案：
☆ 客户端分区：由客户端程序自己实现写入分配、高可用管理和故障转移等,对客户端的开发实现较为复杂
☆ 代理服务：客户端不直接连接Redis,而先连接到代理服务，由代理服务实现相应读写分配，当前代理服务都是第三方实现.此方案中客户端实现无需特殊开发,实现容易,但是代理服务节点仍存有单点故障和性能瓶颈问题。比如：Twitter开源Twemproxy,豌豆荚开发的 codis
Redis 3.0 版本之后推出无中心架构的 Redis Cluster ，支持多个master节点并行写入和故障的自动转移动能.
Redis cluster 需要至少 3个master节点才能实现,slave节点数量不限,当然一般每个master都至少对应的有一个slave节点
如果有三个主节点采用哈希槽 hash slot 的方式来分配16384个槽位 slot
此三个节点分别承担的slot 区间可以是如以下方式分配
节点M1 0－5460
节点M2 5461－10922
节点M3 10923－16383
3-3-1、数据分区
如果是单机存储的话，直接将数据存放在单机redis就行了。但是如果是集群存储，就需要考虑到数据分区了。
数据分区通常采取顺序分布和hash分布
分布方式
| 顺序分布
| 哈希分布
|
数据分散度
| 分布倾斜
| 分布散列
|
顺序访问
| 支持
| 不支持
|
顺序分布保障了数据的有序性，但是离散性低，可能导致某个分区的数据热度高，其他分区数据的热度低，分区访问不均衡。
哈希分布也分为多种分布方式，比如区域哈希分区，一致性哈希分区等。而redis cluster采用的是虚拟槽分区的方式。
3-3-1-1、虚拟槽分区
redis cluster设置有0~16383的槽，每个槽映射一个数据子集，通过hash函数，将数据存放在不同的槽位中，每个集群的节点保存一部分的槽。
每个key存储时，先经过哈希函数CRC16(key)得到一个整数，然后整数与16384取余，得到槽的数值，然后找到对应的节点，将数据存放入对应的槽中
3-3-1-2、集群通信
集群中节点之间的通信，保证了最多两次就能命中对应槽所在的节点。因为在每个节点中，都保存了其他节点的信息，知道哪个槽由哪个节点负责。这样即使第一次访问没有命中槽，但是会通知客户端，该槽在哪个节点，这样访问对应节点就能精准命中。
1、节点A对节点B发送一个meet操作，B返回后表示A和B之间能够进行沟通
2、 节点A对节点C发送meet操作，C返回后，A和C之间也能进行沟通。
3、然后B根据对A的了解，就能找到C，B和C之间也建立了联系。
4、直到所有节点都能建立联系
这样每个节点都能互相知道对方负责哪些槽
3-3-1-3、集群伸缩
集群并不是建立之后，节点数就固定不变的，也会有新的节点加入集群或者集群中的节点下线，这就是集群的扩容和缩容。但是由于集群节点和槽息息相关，所以集群的伸缩也对应了槽和数据的迁移
3-3-1-4、集群扩容
当有新的节点准备好加入集群时，这个新的节点还是孤立节点，加入有两种方式。一个是通过集群节点执行命令来和孤立节点握手，另一个则是使用脚本来添加节点。
- cluster_node_ip:port: cluster meet ip port new_node_ip:port
- redis-trib.rb add-node new_node_ip:port cluster_node_ip:port
通常这个新的节点有两种身份，要么作为主节点，要么作为从节点：
主节点：分摊槽和数据
从节点：作故障转移备份
3-3-1-5、集群缩容
下线节点的流程如下：
- 判断该节点是否持有槽，如果未持有槽就跳转到下一步，持有槽则先迁移槽到其他节点
- 通知其他节点（cluster forget）忘记该下线节点
- 关闭下线节点的服务
需要注意的是如果先下线主节点，再下线从节点，会进行故障转移，所以要先下线从节点。
3-3-1-6、故障转移
除了手动下线节点外，也会面对突发故障。下面提到的主要是主节点的故障，因为从节点的故障并不影响主节点工作，对应的主节点只会记住自己哪个从节点下线了，并将信息发送给其他节点。故障的从节点重连后，继续官复原职，复制主节点的数据。
只有主节点才需要进行故障转移。在主从复制时，需要使用redis sentinel来实现故障转移。而redis cluster则不需要redis sentinel，其自身就具备了故障转移功能。
根据前面了解到，节点之间是会进行通信的，节点之间通过ping/pong交互消息，所以借此就能发现故障。集群节点发现故障同样是有主观下线和客观下线的
主观下线
对于每个节点有一个故障列表，故障列表维护了当前节点接收到的其他所有节点的信息。当半数以上的持有槽的主节点都标记某个节点主观下线，就会尝试客观下线。
客观下线
故障转移
集群同样具备了自动转移故障的功能，和哨兵有些类似，在进行客观下线之后，就开始准备让故障节点的从节点“上任”了。
首先是进行资格检查，只有具备资格的从节点才能参加选举：
故障节点的所有从节点检查和故障主节点之间的断线时间
超过cluster-node-timeout * cluster-slave-validati-factor(默认10)则取消选举资格
然后是准备选举顺序，不同偏移量的节点，参与选举的顺位不同。offset最大的slave节点，选举顺位最高，最优先选举。而offset较低的slave节点，要延迟选举。
当有从节点参加选举后，主节点收到信息就开始投票。偏移量最大的节点，优先参与选举就更大可能获得最多的票数，称为主节点。
当从节点走马上任变成主节点之后，就要开始进行替换主节点：
1、让该slave节点执行slaveof no one变为master节点
2、将故障节点负责的槽分配给该节点
3、向集群中其他节点广播Pong消息，表明已完成故障转移
4、故障节点重启后，会成为new_master的slave节点
3-3-2、Redis Cluster 部署架构说明
注意: 建立Redis Cluster 的节点需要清空数据
测试环境：3台服务器，每台服务器启动6379和6380两个redis 服务实例，适用于测试环境
生产环境：6台服务器，分别是三组master/slave，适用于生产环境
#redis cluster 有多种部署方法
原生命令安装
理解Redis Cluster架构
生产环境不使用
官方工具安装
高效、准确
生产环境可以使用
自主研发
可以实现可视化的自动化部署
#redis cluster 相关命令
redis-cli --cluster help # 查看 --cluster 选项帮助
redis-cli CLUSTER HELP # 查看CLUSTER 指令的帮助
3-3-3、基于Redis 5 以上版本的 redis cluster 部署
3-3-3-1、环境准备
☆ 每个Redis 节点采用相同的相同的Redis版本、相同的密码、硬件配置
☆ 所有Redis服务器必须没有任何数据
#所有主从节点执行：
[root@ubuntu2004 ~]#bash install_redis.sh
#脚本参考：https://blog.51cto.com/dayu/5805274
3-3-3-2、启用 redis cluster 配置
#所有主从节点执行：
#每个节点修改redis配置，必须开启cluster功能的参数
[root@master-1 ~]#vim /apps/redis/etc/redis.conf
bind 0.0.0.0
masterauth 123456 #建议配置，否则后期的master和slave主从复制无法成功，还需再配置
requirepass 123456
cluster-enabled yes #取消此行注释,必须开启集群，开启后 redis 进程会有cluster标识
cluster-config-file nodes-6379.conf #取消此行注释,此为集群状态数据文件,记录主从关系及slot范围信息,由redis cluster 集群自动创建和维护
cluster-require-full-coverage no #默认值为yes,设为no可以防止一个节点不可用导致整个cluster不可用
#验证当前Redis服务状态：
[root@master-1 ~]#ss -ntl
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 511 0.0.0.0:6379 0.0.0.0:*
LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 511 0.0.0.0:16379 0.0.0.0:*
LISTEN 0 511 [::1]:6379 [::]:*
LISTEN 0 128 [::]:22 [::]:*
LISTEN 0 511 [::1]:16379 [::]:*
#开启了16379的cluster的端口,实际的端口=redis port + 10000
3-3-3-3、创建集群
#10.0.0.101:
[root@master-1 ~]#redis-cli -a 123456 --cluster create 10.0.0.101:6379 10.0.0.102:6379 10.0.0.103:6379 10.0.0.18:6379 10.0.0.28:6379 10.0.0.38:6379 --cluster-replicas 1
#命令redis-cli的选项 --cluster-replicas 1 表示每个master对应一个slave节点
3-3-3-4、验证集群
#查看主从状态
[root@master-1 ~]#redis-cli -a 123456 -c info replication
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
# Replication
role:master
connected_slaves:1
slave0:ip=10.0.0.28,port=6379,state=online,offset=602,lag=0
......
#查看对应关系
[root@master-1 ~]#redis-cli -a 123456 cluster nodes
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
c58b6d30550a3d6d682d2a4f7563efabf470bd82 10.0.0.38:6379@16379 slave 139317befd252551e1135b27d32ce557133ec71a 0 1667098745948 2 connected
......
#验证集群状态
[root@master-1 ~]#redis-cli -a 123456 cluster info
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
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 #三个集群
......
#查看任意节点的集群状态
[root@slave-1 ~]#redis-cli -a 123456 --cluster info 10.0.0.38:6379
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.0.0.102:6379 (139317be...) -> 0 keys | 5462 slots | 1 slaves.
10.0.0.101:6379 (98df8874...) -> 0 keys | 5461 slots | 1 slaves.
10.0.0.103:6379 (8d72bbb5...) -> 0 keys | 5461 slots | 1 slaves.
[OK] 0 keys in 3 masters.
0.00 keys per slot on average.
[root@slave-1 ~]#redis-cli -a 123456 --cluster check 10.0.0.38:6379
3-3-3-5、测试写入数据
[root@master-1 ~]#redis-cli -a 123456 -h 10.0.0.102 set k1 wang
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
(error) MOVED 12706 10.0.0.103:6379 #槽位不在当前node所以无法写入
[root@master-1 ~]#redis-cli -a 123456 -h 10.0.0.103 set k1 wang
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
OK
[root@slave-1 ~]#redis-cli -a 123456 -h 10.0.0.103 get k1
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
"wang"
[root@master-1 ~]#redis-cli -a 123456 -h 10.0.0.103 get k1
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
"wang"
#使用选项-c 以集群模式连接
[root@master-1 ~]#redis-cli -c -h 10.0.0.18 -a 123456 --no-auth-warning
10.0.0.18:6379> cluster keyslot test
(integer) 6918
10.0.0.18:6379> set test mylove
-> Redirected to slot [6918] located at 10.0.0.102:6379
OK
10.0.0.102:6379> get test
"mylove"
10.0.0.102:6379> exit
[root@master-1 ~]#redis-cli -h 10.0.0.102 -a 123456 --no-auth-warning get test
"mylove"
3-3-4、集群扩容
扩容适用场景：
当前客户量激增，现有的Redis cluster架构已经无法满足越来越高的并发访问请求，为解决此问题,新购置两台服务器，要求将其动态添加到现有集群，但不能影响业务的正常访问。
注意: 生产环境一般建议master节点为奇数个,比如:3,5,7,以防止脑裂现象
#添加节点语法说明：
add-node new_host:new_port existing_host:existing_port [--slave --master-id <arg>]
new_host:new_port #指定新添加的主机的IP和端口
existing_host:existing_port #指定已有的集群中任意节点的IP和端口
#例：
redis-cli -a 123456 --cluster add-node 10.0.0.68:6379 <当前任意集群节点>:6379
#重新分配槽位示例：
redis-cli -a 123456 --cluster reshard <当前任意集群节点>:6379
3-3-4-1、添加节点
增加Redis 新节点，需要与之前的Redis node版本和配置一致，然后分别再启动两台Redis node，应为一主一从。
#修改新节点配置
[root@rocky8 ~]# sed -i.bak -e '/masterauth/a masterauth 123456' -e '/# cluster-enabled yes/a cluster-enabled yes' -e '/# cluster-config-file nodes-6379.conf/a cluster-config-file nodes-6379.conf' -e '/cluster-require-full-coverage yes/c cluster-require-full-coverage no' /apps/redis/etc/redis.conf;systemctl restart redis
[root@rocky8 ~]# systemctl enable --now redis
#将一台新的主机10.0.0.104加入集群,以下示例中10.0.0.101可以是任意存在的集群节点
[root@node4 ~]#redis-cli -a 123456 --cluster add-node 10.0.0.104:6379 10.0.0.101:6379
......
[OK] All 16384 slots covered.
>>> Getting functions from cluster
>>> Send FUNCTION LIST to 10.0.0.104:6379 to verify there is no functions in it
>>> Send FUNCTION RESTORE to 10.0.0.104:6379
>>> Send CLUSTER MEET to node 10.0.0.104:6379 to make it join the cluster.
[OK] New node added correctly
#观察到该节点已经加入成功，但此节点上没有slot位,也无从节点，而且新的节点是master
[root@node4 ~]#redis-cli -a 123456 --cluster info 10.0.0.104:6379
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.0.0.104:6379 (c8322603...) -> 0 keys | 0 slots | 0 slaves.
10.0.0.103:6379 (5682effa...) -> 0 keys | 5461 slots | 1 slaves.
10.0.0.101:6379 (31535f72...) -> 0 keys | 5461 slots | 1 slaves.
10.0.0.102:6379 (d4832e6c...) -> 0 keys | 5462 slots | 1 slaves.
[OK] 0 keys in 4 masters.
0.00 keys per slot on average.
[root@node4 ~]#redis-cli -a 123456 --cluster check 10.0.0.104:6379
3-3-4-2、在新加入的节点上重新分配槽位
新的node节点加到集群之后,默认是master节点，但是没有slots，需要重新分配,否则没有槽位将无法访问
注意: 重新分配槽位需要清空数据,所以需要先备份数据,扩展后再恢复数据
......
How many slots do you want to move (from 1 to 16384)?4096 #新分配多少个槽位=16384/master个数
What is the receiving node ID? c8322603ab982f005c04652ebb55bab847717eca #新的master的ID
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1: all #输入all,将哪些源主机的槽位分配给新的节点，all是自动在所有的redisnode选择划分，如果是从redis cluster删除某个主机可以使用此方式将指定主机上的槽位全部移动到别的redis主机
......
Do you want to proceed with the proposed reshard plan (yes/no)? yes #确认分配
......
#确定slot分配成功
[root@node4 ~]#redis-cli -a 123456 --cluster check 10.0.0.104:6379
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.0.0.104:6379 (c8322603...) -> 0 keys | 4096 slots | 0 slaves.
10.0.0.103:6379 (5682effa...) -> 0 keys | 4096 slots | 1 slaves.
10.0.0.101:6379 (31535f72...) -> 0 keys | 4096 slots | 1 slaves.
10.0.0.102:6379 (d4832e6c...) -> 0 keys | 4096 slots | 1 slaves.
[OK] 0 keys in 4 masters.
0.00 keys per slot on average.
>>> Performing Cluster Check (using node 10.0.0.104:6379)
M: c8322603ab982f005c04652ebb55bab847717eca 10.0.0.104:6379
slots:[0-1364],[5461-6826],[10923-12287] (4096 slots) master
......
3-3-4-3、为新的master指定新的slave节点
当前Redis集群中新的master节点存单点问题,还需要给其添加一个对应slave节点，实现高可用功能有两种方式：
方法1：在新加节点到集群时，直接将之设置为slave
redis-cli -a 123456 --cluster add-node 10.0.0.48:6379 <任意集群节点>:6379 --cluster-slave --cluster-master-id c8322603ab982f005c04652ebb55bab847717eca
方法2：先将新节点加入集群，再修改为slave
#把10.0.0.48:6379添加到集群中
redis-cli -a 123456 --cluster add-node 10.0.0.48:6379 10.0.0.104:6379
redis-cli -h 10.0.0.48 -p 6379 -a 123456 #登录到新添加节点
10.0.0.48:6379> CLUSTER REPLICATE c8322603ab982f005c04652ebb55bab847717eca #将其设置slave，命令格式为cluster replicate MASTERID
#在新加节点到集群，直接将之设置为slave
[root@node4 ~]#redis-cli -a 123456 --cluster add-node 10.0.0.48:6379 10.0.0.101:6379 --cluster-slave --cluster-master-id c8322603ab982f005c04652ebb55bab847717eca
#验证是否成功
[root@node4 ~]#redis-cli -a 123456 -h 10.0.0.104 --no-auth-warning cluster info
[root@node4 ~]#redis-cli -a 123456 --cluster check 10.0.0.104:6379
3-3-5、集群缩容
缩容适用场景：
随着业务萎缩用户量下降明显,和领导商量决定将现有Redis集群的8台主机中下线两台主机挪做它用,缩容后性能仍能满足当前业务需求
删除节点过程：
扩容时是先添加node到集群，然后再分配槽位，而缩容时的操作相反，是先将被要删除的node上的槽位迁移到集群中的其他node上，然后 才能再将其从集群中删除，如果一个node上的槽位没有被完全迁移空，删除该node时也会提示有数据出错导致无法删除。
3-3-5-1、迁移要删除的master节点上面的槽位到其它master
注意: 被迁移Redis master源服务器必须保证没有数据，否则迁移报错并会被强制中断
[root@node4 ~]#redis-cli -a 123456 --cluster reshard 10.0.0.101:6379
......
How many slots do you want to move (from 1 to 16384)? 1365 #共4096/3分别给其它三个master节点
What is the receiving node ID? 31535f7273c00a2fd13ccee4e1a238b23d95c69b #master10.0.0.101
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1: c8322603ab982f005c04652ebb55bab847717eca #输入要删除节点10.0.0.104的ID
Source node #2: done
......
#以此类推
[root@node4 ~]#redis-cli -a 123456 --cluster reshard 10.0.0.101:6379
......
How many slots do you want to move (from 1 to 16384)? 1366
What is the receiving node ID? d4832e6c7fcc6ebdcc1297d091c754ae2785cbda
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1: c8322603ab982f005c04652ebb55bab847717eca
Source node #2: done
......
[root@node4 ~]#redis-cli -a 123456 --cluster reshard 10.0.0.101:6379
......
How many slots do you want to move (from 1 to 16384)? 1365
What is the receiving node ID? 5682effa3d74646a7310f1b25630a67448c6e15f
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1: c8322603ab982f005c04652ebb55bab847717eca
Source node #2: done
......
3-3-5-2、从集群中删除服务器
上面步骤完成后,槽位已经迁移走，但是节点仍然还属于集群成员，因此还需从集群删除该节点
注意: 删除服务器前,必须清除主机上面的槽位,否则会删除主机失败
#查看集群节点情况：
[root@node1 ~]#redis-cli -a 123456 --cluster check 10.0.0.101:6379
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.0.0.101:6379 (31535f72...) -> 0 keys | 5462 slots | 1 slaves.
10.0.0.103:6379 (5682effa...) -> 0 keys | 5460 slots | 2 slaves.
10.0.0.102:6379 (d4832e6c...) -> 0 keys | 5462 slots | 2 slaves.
[OK] 0 keys in 3 masters.
0.00 keys per slot on average.
>>> Performing Cluster Check (using node 10.0.0.101:6379)
M: 31535f7273c00a2fd13ccee4e1a238b23d95c69b 10.0.0.101:6379
slots:[0-5461] (5462 slots) master
1 additional replica(s)
S: c31ff3d3cd7d71103d9a2d74b4bf5a79b6f3642b 10.0.0.18:6379
slots: (0 slots) slave
replicates 5682effa3d74646a7310f1b25630a67448c6e15f
M: 5682effa3d74646a7310f1b25630a67448c6e15f 10.0.0.103:6379
slots:[10924-16383] (5460 slots) master
2 additional replica(s)
S: 4b68797b76a8fd58836142062ffa0799835498d4 10.0.0.28:6379
slots: (0 slots) slave
replicates 31535f7273c00a2fd13ccee4e1a238b23d95c69b
S: 1713bcee07ef49770d7dfaed2f329267983b1062 10.0.0.48:6379
slots: (0 slots) slave
replicates d4832e6c7fcc6ebdcc1297d091c754ae2785cbda
S: c8322603ab982f005c04652ebb55bab847717eca 10.0.0.104:6379
slots: (0 slots) slave
replicates 5682effa3d74646a7310f1b25630a67448c6e15f
M: d4832e6c7fcc6ebdcc1297d091c754ae2785cbda 10.0.0.102:6379
slots:[5462-10923] (5462 slots) master
2 additional replica(s)
S: e4a290c34efaa97ade35822710e5021214fcfa3f 10.0.0.38:6379
slots: (0 slots) slave
replicates d4832e6c7fcc6ebdcc1297d091c754ae2785cbda
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
[root@node1 ~]#redis-cli -a 123456 --cluster del-node 10.0.0.101:6379 1713bcee07ef49770d7dfaed2f329267983b1062 #删除10.0.0.48，id对应的是10.0.0.48
[root@node1 ~]#redis-cli -a 123456 --cluster del-node 10.0.0.101:6379 c8322603ab982f005c04652ebb55bab847717eca #删除10.0.0.104，id对应的是10.0.0.104
#查看集群节点情况，48和104已被删除：
[root@node1 ~]#redis-cli -a 123456 --cluster check 10.0.0.101:6379
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
10.0.0.101:6379 (31535f72...) -> 0 keys | 5462 slots | 1 slaves.
10.0.0.103:6379 (5682effa...) -> 0 keys | 5460 slots | 1 slaves.
10.0.0.102:6379 (d4832e6c...) -> 0 keys | 5462 slots | 1 slaves.
[OK] 0 keys in 3 masters.
0.00 keys per slot on average.
>>> Performing Cluster Check (using node 10.0.0.101:6379)
M: 31535f7273c00a2fd13ccee4e1a238b23d95c69b 10.0.0.101:6379
slots:[0-5461] (5462 slots) master
1 additional replica(s)
S: c31ff3d3cd7d71103d9a2d74b4bf5a79b6f3642b 10.0.0.18:6379
slots: (0 slots) slave
replicates 5682effa3d74646a7310f1b25630a67448c6e15f
M: 5682effa3d74646a7310f1b25630a67448c6e15f 10.0.0.103:6379
slots:[10924-16383] (5460 slots) master
1 additional replica(s)
S: 4b68797b76a8fd58836142062ffa0799835498d4 10.0.0.28:6379
slots: (0 slots) slave
replicates 31535f7273c00a2fd13ccee4e1a238b23d95c69b
M: d4832e6c7fcc6ebdcc1297d091c754ae2785cbda 10.0.0.102:6379
slots:[5462-10923] (5462 slots) master
1 additional replica(s)
S: e4a290c34efaa97ade35822710e5021214fcfa3f 10.0.0.38:6379
slots: (0 slots) slave
replicates d4832e6c7fcc6ebdcc1297d091c754ae2785cbda
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
#删除节点后,redis进程自动关闭
#删除节点信息
[root@node4 ~]#rm -f /var/lib/redis/nodes-6379.conf
3-3-6、导入现有Redis数据至集群
官方提供了迁移单个Redis节点数据到集群的工具,有些公司开发了离线迁移工具
官方工具: redis-cli --cluster import
第三方在线迁移工具: 模拟slave 节点实现, 比如: 唯品会 redis-migrate-tool , 豌豆荚 redis-por
导入适用场景：
业务数据初始是放在单一节点的主机上,随着业务量上升,建立了redis 集群,需要将之前旧数据导入到新建的Redis cluster中.
注意: 导入数据需要redis cluster不能与被导入的数据有重复的key名称，否则导入不成功或中断
导入数据是需要关闭安全模式
导入时不能指定验证密码,所以导入数据之前需要关闭所有Redis 节点的密码
3-3-6-1、导入数据前准备
#关闭安全模式：
[root@node4 ~]#sed -i '/protected-mode yes/c protected-mode no' /apps/redis/etc/redis.conf
[root@node4 ~]#systemctl restart redis
#在所有节点包括master和slave节点上关闭各Redis密码认证
[root@node4 ~]#redis-cli -a 123456 config set requirepass "" #临时取消密码
3-3-6-2、导入数据
[root@node4 ~]#redis-cli --cluster import 10.0.0.101:6379 --cluster-from 10.0.0.48:6379 --cluster-copy --cluster-replace #导入10.0.0.48的数据至10.0.0.101所在的集群
#注：
只使用cluster-copy，则要导入集群中的key不能存在
如果集群中已有同样的key，如果需要替换，可以cluster-copy和cluster-replace联用，这样集群中的key就会被替换为外部数据
3-3-6-3、验证数据
#验证数据
[root@node4 ~]#redis-cli -c
127.0.0.1:6379> get k1
-> Redirected to slot [12706] located at 10.0.0.103:6379
"v1"
10.0.0.103:6379> get k2
-> Redirected to slot [449] located at 10.0.0.101:6379
"v2"
10.0.0.101:6379> get k3
"v3"
