分布式中间件之Redis
下载Redis
windows版本：https://github.com/MicrosoftArchive/redis/tags （官网没有，只能去github下载，也只有3.2版本以下的）
linux版本： https://download.redis.io/releases/
RDB（快照）
redis是内存数据库，一旦断电或者宕机，内存中的数据将全部丢失，redis为了解决这个问题，提供了rdb和aof两种方式来持久化数据。
默认情况下redis会把内存里面的数据保存在一个叫做 dump.rdb 二进制的文件里面
rdb也就时把内存中的数据写入到磁盘里面，恢复的时候将rdb二进制快照文件里面的内容加载到内存中。
在redis.conf配置文件里面有个三个save配置属性，意思就是多少秒以内有多少个改动的话就把内存里面的数据写到一个 dump.rdb 文件里面，关闭rdb也只需要注释掉下面三个配置项即可 。
save 900 1 # 900秒有一个改动
save 300 10 # 300秒有10个改动
save 60 10000 # 60秒有10000改动
文件名：dbfilename dump.rdb
文件路径：dir ./
save：在执行的过程中，会阻塞redis服务器，直到rdb文件创建完成，并且会覆盖掉原来的rdb文件。同步操作。
bgsave：redis借助操作系统写时的复制技术，copy-on-write思想，在生成快照的同时，依然可以正常处理其他命令，
仅在生成子进程调用fork函数的时候会有短暂的阻塞。bgsave子进程是由主线程fork出来的，他可以共享主线程的所有数据。
bgsave子进程开启后，会读取主线程的数据，并把它们写入到rdb。异步操作。
rdb的问题：一般来说不可能配置每秒钟有改动就重新写入rdb文件里面，是比较耗费性能的，所有在内存的缓存有改动的时候，
有可能还没有写入rdb文件。
AOF
为了解决rdb的问题，从1.1版本开始，appendonly yes 来开启aof功能，默认是关闭的
触发aof有三个选项可配置
appendfsync always # 每次有新的命令就写入到aof文件里面，处理的最慢的也是最安全的
appendfsync everysec # 每秒钟写入一次，最多丢失一秒钟的数据，也是redis官方推荐的
appendfsync no # 交给操作系统去处理，写的比较快但是也是最不安全的
aof文件里面只记录修改文件的命令，get命令不会记录
*号表示执行的命令有几个关键字或者参数，比如set access_token 123456，这条命令一共就是3个
$表示每个关键字或者参数的长度，set就是3，access_token就是12，123456就是6
aof重写
aof是通过文件追加的方式实现的，为了避免文件越来越大重写耗费性能，新增了重写机制。
- 自动重写
auto-aof-rewrite-min-size 64mb # aof文件至少达到64兆才会自动重写，文件太小恢复本来就很快。
auto-aof-rewrite-percentage 100 # aof文件自上一次重写增长了100%再进行重写
重写之后，如果之前有多条命令操作一个key之类的或者原子操作incr key 会最终变成一条记录，
比如 incr readcount了六次，重写之后的appendonly.aof里面之后只有一个set readcount 6的命令。
相比于重写之前，如果要恢复数据的话要执行6次的命令，而现在只需要执行1次即可。一条命令的操作肯定比6次效率高。
-
手动重写
-
通过
bgrewriteaof命令进行手动重写
aof重写也会fork出一个子进程去做(类型与bgsave)，先写临时文件最后在rename，所以不会对redis正常命令有太多影响。
此时如果不开启redis4.0的功能混合持久化，这个appendonly.aof文件还是能看懂，不是二进制开启混合持久
化就是类似于rdb文件的二进制文件，下面会讲混合持久化。
生产环境建议rdb和aof都启用
rdb文件较小，因为他是二进制文件，恢复快，但是安全性低，可能存在数据丢失的问题。优先级低。aof文件体积大，恢复慢，但是安全性高，最多只会丢失一秒钟的数据。优先级高。
redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，redis恢复数据采用的是aof方式，为什么rdb恢复速度快不采用？因为rdb文件可能没有aof的数据安全。
Redis4.0混合持久化
在redis4.0版本中，可以开启两种方式的持久化策略，在 redis.conf 配置文件里面可以通过
aof-use-rdb-preamble yes 来开启或关闭，这种方式一定是要先开启aof才可以。
如果开启了混合持久化，aof重写会以rdb方式的二进制重写到appendonly.aof文件里面。
重写之后的appendonly.aof文件是二进制，重写之后有新的命令进来且没有触发到aof的重写机制，后面的命令就是
以aof格式存储到appendonly.aof文件里面的。恢复数据自然是二进制方式的比较快，这样就能达到了安全又恢复快文件又小的效果。
Redis数据恢复
redis宕机重启的时候是通过dump.rdb文件和appendonly.aof文件来恢复数据的，所以只需要定期对这两个文件做备份即可。
在linux中可以通过写crontab定时调度脚本去实现。
Redis主从架构搭建
pidfile /var/run/redis_6380.pid # 把pid进程号写入pidfile配置的文件
logfile "6380.log"
dir /usr/local/redis‐5.0.3/data/6380 # 指定数据存放目录
# 需要注释掉bind
# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通
过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）
3、配置主从复制
# 从ip为192.168.1.1的机器的端口号为6379的redis实例复制数据，Redis 5.0之前使用slaveof
replicaof 192.168.1.1 6379
replica‐read‐only yes # 配置从节点只读，默认是开启的
4、启动从节点
redis‐server redis.conf
5、连接从节点
redis‐cli ‐p 6380
6、测试在6379实例上写数据，6380实例是否能及时同步新修改数据
7、可以自己再配置一个6381的从节点
Redis主从复制原理
如果你为master配置了一个slave，不管这个slave是否是第一次连接上Master，它都会发送一个PSYNC命令给
master请求复制数据。
master收到PSYNC命令后，会在后台进行数据持久化通过bgsave生成最新的rdb快照文件，持久化期间，master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，然后再加载到内存中。然后，master再将之前缓存在内存中的命令发送给slave。
当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送给多个并发连接的slave。
全量复制
部分复制
主从复制风暴
Redis管道操作与Lua脚本
客户端可以一次性发送多个命令，从而节省网络开销，管道执行多条命令的操作实际上相当于只执行了一条命令。
管道操作并不具备原子性，比如管道三条命令，第二条报错了，不会影响第三条的正常操作。
redis2.6版本支持lua脚本。
public static void main(String[] args) {
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxTotal(20);
config.setMaxIdle(10);
config.setMinIdle(5);
String host = "127.0.0.1";
Integer port = 6370;
JedisPool jedisPool = new JedisPool(config, host, port, 3000, null);
Jedis jedis = jedisPool.getResource();
// System.out.println(jedis.set("address", "beijingshi"));
// System.out.println(jedis.get("address"));
// 管道实例
/* Pipeline pipeline = jedis.pipelined();
for (int i = 0; i < 2; i++) {
jedis.incr("pipelineKey");
jedis.set("test" + i, "111");
// 模拟管道报错
// jedis.setbit("tqz", -1, true);
}
List
// redis2.6新增lua脚本功能，lua脚本保证原子操作
String luaKey = "product_stock_10016";
//初始化商品10016的库存
jedis.set(luaKey, "15");
String script = " local count = redis.call('get', KEYS[1]) " +
" local a = tonumber(count) " +
" local b = tonumber(ARGV[1]) " +
" if a >= b then " +
" redis.call('set', KEYS[1], a-b) " +
// 模拟报错，进行回滚保证原子性
// " bb == 0 " +
" return 1 " +
" end " +
" return 0 ";
Object obj = jedis.eval(script, Arrays.asList(luaKey), Arrays.asList("10"));
System.out.println(obj);
}
不要在lua脚本里面进行循环或者耗时的运算，否则会阻塞其他命令的操作。
Redis Sentinel哨兵高可用架构
主从架构下，主节点宕机的情况下，需要运维人员重新配置 replicaof ip port ，redis2.8版本sentinel哨兵机制解决了这种问题。
当主节点宕机的时候，sentinel会从slave里面重新选举一个master。再重新选主的时候整个redis服务是不可用的。
sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。
哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)
复制一份 sentinel.conf 配置文件
cp sentinel.conf sentinel‐26379.conf
port 26379
daemonize yes
pidfile "/var/run/redis‐sentinel‐26379.pid"
logfile "26379.log"
dir "/usr/local/redis‐5.0.3/data"
# 主要配置这个
# sentinel monitor <master‐redis‐name> <master‐redis‐ip> <master‐redis‐port> <quorum>
# quorum是一个数字，指明当有多少个sentinel认为一个master失效时(值一般为：sentinel总数/2 +1)，master才算真正失效
# mymaster这个名字随便取，客户端访问时会用到
sentinel monitor mymaster 外网ip 6379 2
# 是否受保护的，yes的话需要设置bind ip 或者设置访问密码
protected-mode no
# 启动sentinel哨兵
./redis‐sentinel sentinel‐26379.conf
# 查看sentinel的info信息
./redis‐cli ‐p 26379
127.0.0.1:26370> info
可以到已经识别到了集群节点的信息
进入到redis server的端口里面，可以看到role：master
./redis-cli -p 6370
./redis-server redis.conf &
./redis-sentinel sentinel.conf &
./redis-cli -p 26370
sentinel集群都启动完毕后，会将哨兵集群的元数据信息写入所有sentinel的配置文件里去(追加在文件的
最下面)，我们查看下如下配置文件sentinel-26379.conf，如下所示：
sentinel known‐replica mymaster 192.168.0.60 6380 #代表redis主节点的从节点信息
sentinel known‐replica mymaster 192.168.0.60 6381 #代表redis主节点的从节点信息
sentinel known‐sentinel mymaster 192.168.0.60 26380 52d0a5d70c1f90475b4fc03b6ce7c3c569
35760f #代表感知到的其它哨兵节点
sentinel known‐sentinel mymaster 192.168.0.60 26381 e9f530d3882f8043f76ebb8e1686438ba8
bd5ca6 #代表感知到的其它哨兵节点
当redis主节点如果挂了，哨兵集群会重新选举出新的redis主节点，同时会修改所有sentinel节点配置文件
的集群元数据信息，比如6379的redis如果挂了，假设选举出的新主节点是6380，则sentinel文件里的集
群元数据信息会变成如下所示：
sentinel known‐replica mymaster 192.168.0.60 6379 #代表主节点的从节点信息
sentinel known‐replica mymaster 192.168.0.60 6381 #代表主节点的从节点信息
sentinel known‐sentinel mymaster 192.168.0.60 26380 52d0a5d70c1f90475b4fc03b6ce7c3c569
35760f #代表感知到的其它哨兵节点
sentinel known‐sentinel mymaster 192.168.0.60 26381 e9f530d3882f8043f76ebb8e1686438ba8
bd5ca6 #代表感知到的其它哨兵节点
同时还会修改sentinel文件里之前配置的mymaster对应的6379端口，改为6380
sentinel monitor mymaster 192.168.0.60 6380 2
原生api方式连接
/**
* 使用jedis连接redis的sentinel哨兵架构
*
* @autoor tianqingzhao
* @since 2021/10/14 17:20
*/
public class JedisSentinelTest {
public static void main(String[] args) {
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxTotal(20);
config.setMaxIdle(10);
config.setMinIdle(5);
// 与sentinel.conf配置文件里面的节点保持一致
String masterName = "mymaster";
Set<String> sentinels = new HashSet<>();
sentinels.add(new HostAndPort("127.0.0.1", 26370).toString());
sentinels.add(new HostAndPort("127.0.0.1", 26371).toString());
sentinels.add(new HostAndPort("127.0.0.1", 26372).toString());
JedisSentinelPool sentinelPool = new JedisSentinelPool(masterName, sentinels, config, 3000, null);
Jedis jedis = sentinelPool.getResource();
String key = "tqz";
System.out.println(jedis.set(key, "888"));
System.out.println(jedis.get(key));
}
}
Spring Boot 方式连接sentinel架构
添加依赖
<parent>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-parentartifactId>
<version>2.4.1version>
<relativePath/>
parent>
<properties>
<maven.compiler.source>8maven.compiler.source>
<maven.compiler.target>8maven.compiler.target>
properties>
<dependencies>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-webartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-data-redisartifactId>
dependency>
dependencies>
application.properties
spring.redis.database=0
spring.redis.timeout=3000
spring.redis.sentinel.master=mymaster
spring.redis.sentinel.nodes=ip:26370,ip:26371,ip:26372
#spring.redis.sentinel.password=
spring.redis.lettuce.pool.max-idle=50
spring.redis.lettuce.pool.min-idle=10
spring.redis.lettuce.pool.max-active=100
spring.redis.lettuce.pool.max-wait=1000
java代码
@RestController
public class SentinelController {
private static final Logger logger = LoggerFactory.getLogger(SentinelController.class);
@Autowired
private StringRedisTemplate stringRedisTemplate;
@RequestMapping("sentinel")
public String sentinel() {
int i = 1;
String prefixKey = "tianqingzhao";
while (true) {
try {
stringRedisTemplate.opsForValue().set(prefixKey + i, i + "");
System.out.println("设置key：" + prefixKey + i);
i++;
Thread.sleep(2000);
} catch (Exception e) {
logger.error("错误：", e);
}
}
}
}
Redis集群架构
Redis3.0版本推出了Redis Cluster集群架构，不需要借助sentinel哨兵机制也能做故障转移。
Redis官方文档支持横向扩展1万个主从架构的节点，但是推荐不要超过1千个。
redis集群至少需要3个主节点。
redis集群之间采用gossip协议进行通信，每个节点的gossip的端口号会在对外开放的端口号上面加10000，比如某个节点对外开放的端口号为6379，那么该节点的gossip端口号为16379。
Redis集群架构图
单机搭建伪集群
# 创建一个集群的文件夹
mkdir ‐p /usr/local/redis‐cluster
mkdir 6390 6391 6392 6393 6394 6395
第一步：把之前的redis.conf配置文件copy到6390下，修改如下内容：
（1）daemonize yes
（2）port 6390（分别对每个机器的端口号进行设置）
（3）pidfile /var/run/redis_6390.pid # 把pid进程号写入pidfile配置的文件
（4）dir /usr/local/redis‐cluster/6390/（指定数据文件存放位置，必须要指定不同的目录位置，不然会
丢失数据）
（5）cluster‐enabled yes（启动集群模式）
（6）cluster‐config‐file nodes‐6390.conf（集群节点信息文件，这里639x最好和port对应上）
（7）cluster‐node‐timeout 10000
（8）# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通
过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可） 一般改为 bind 0.0.0.0，
客户端需要操作的话改为外网的ip。
（9）protected‐mode no （关闭保护模式）
（10）appendonly yes
如果要设置密码需要增加如下配置：
（11）requirepass 123456 (设置redis访问密码)
（12）masterauth 123456 (设置集群节点间访问密码，跟上面一致)
第三步：把修改后的配置文件，copy到其他节点，修改第2、3、4、6项里的端口号，可以用批量替换：
:%s/源字符串/目的字符串/g
第四步：分别启动6个redis实例，然后检查是否启动成功
（1）/usr/local/redis‐5.0.3/src/redis‐server /usr/local/redis‐cluster/639*/redis.conf
（2）ps ‐ef | grep redis 查看是否启动成功
第五步：用redis‐cli创建整个redis集群(redis5以前的版本集群是依靠ruby脚本redis‐trib.rb实现)
# 下面命令里的1代表为每个创建的主服务器节点创建一个从服务器节点
# 执行这条命令需要确认三台机器之间的redis实例要能相互访问，可以先简单把所有机器防火墙关掉，如果不
# 关闭防火墙则需要打开redis服务端口和集群节点gossip通信端口16379(默认是在redis端口号上加1W)
# 关闭防火墙
# systemctl stop firewalld # 临时关闭防火墙
# systemctl disable firewalld # 禁止开机启动
# 注意：下面这条创建集群的命令大家不要直接复制，里面的空格编码可能有问题导致创建集群不成功
# -a 表示密码
（1）/usr/local/redis‐5.0.3/src/redis‐cli ‐a 123456 ‐‐cluster create ‐‐cluster‐replicas 1 ip:6390 ip2:6391 ip:6392 ip:6393 ip:6394 ip:6395
第七步：验证集群
（1）连接任意一个客户端即可：./redis‐cli ‐c ‐h ‐p (‐a访问服务端密码，‐c表示集群模式，指定ip地址
和端口号）
如：/usr/local/redis‐5.0.3/src/redis‐cli ‐a 123456 ‐c ‐h ip ‐p 639*
（2）进行验证： cluster info（查看集群信息）、cluster nodes（查看节点列表）
（3）进行数据操作验证
（4）关闭集群则需要逐个进行关闭，使用命令：
/usr/local/redis‐5.0.3/src/redis‐cli ‐a 123456 ‐c ‐h ip ‐p 639* shutdown
# 集群停止之后，千万不能使用 --cluster create --cluster-replicas 的命令了，这是创建集群的。只需要依次启动每台机器就可以。
jedis操作redis集群
/**
* 使用jedis操作redis的集群架构
*
* @author tianqingzhao
* @since 2021/10/21 20:08
*/
public class JedisClusterTest {
public static void main(String[] args) {
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxTotal(50);
config.setMaxIdle(10);
config.setMinIdle(5);
Set<HostAndPort> cluster = new HashSet<>();
cluster.add(new HostAndPort("ip", 6390));
cluster.add(new HostAndPort("ip", 6391));
cluster.add(new HostAndPort("ip", 6392));
cluster.add(new HostAndPort("ip", 6393));
cluster.add(new HostAndPort("ip", 6394));
cluster.add(new HostAndPort("ip", 6395));
JedisCluster jedisCluster = null;
try {
// 客户端在初始化的时候会去找到集群中的某一台节点，然后缓存在客户端
jedisCluster = new JedisCluster(cluster, 6000, 5000, 10, "tqz123456789.", config);
String key = "cluster-key";
// 根据key通过crc16算法进行hash取模，最终落在某一个slot上面。
System.out.println(jedisCluster.set(key, "test"));
System.out.println(jedisCluster.get(key));
} finally {
if (jedisCluster != null) {
jedisCluster.close();
}
}
}
}
Redis集群原理分析
Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。
槽位定位算法
Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。
HASH_SLOT = CRC16(key) mod 16384
跳转重定位
当客户端向一个错误的节点发出了指令，该节点会发现指令的 key 所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。客户端收到指令后除了跳转到正确的节点上去操作，还会同步更新纠正本地的槽位映射表缓存，后续所有 key 将使用新的槽位映射表。
Redis集群节点间的通信机制
redis cluster节点间采取gossip协议进行通信，维护集群的元数据(集群节点信息，主从角色，节点数量，各节点共享的数据等)有两种方式：集中式和gossip。
-
集中式：
优点在于元数据的更新和读取，时效性非常好，一旦元数据出现变更立即就会更新到集中式的存储中，其他节
点读取的时候立即就可以立即感知到；不足在于所有的元数据的更新压力全部集中在一个地方，可能导致元数
据的存储压力。 很多中间件都会借助zookeeper集中式存储元数据。 -
gossip：gossip协议包含多种消息，包括ping，pong，meet，fail等等。
-
meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信；
-
ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据(类似自己感知到的集群节点增加和移除，hash slot信息等)；
-
pong: 对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新；
-
fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。
gossip协议的优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力；缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后。
gossip通信的10000端口
每个节点都有一个专门用于节点间gossip通信的端口，就是自己提供服务的端口号+10000，比如7001，那么
用于节点间通信的就是17001端口。 每个节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几
点接收到ping消息之后返回pong消息。
-
网络抖动
真实世界的机房网络往往并不是风平浪静的，它们经常会发生各种各样的小问题。比如网络抖动就是非常常见的一种现象，突然之间部分连接变得不可访问，然后很快又恢复正常。为解决这种问题，Redis Cluster 提供了一种选项clusternodetimeout，表示当某个节点持续 timeout的时间失联时，才可以认定该节点出现故障，需要进行主从切换。如果没有这个选项，网络抖动会导致主从频繁切换 (数据的重新复制)。
集群选举原理
1.slave发现当前自己的master变为fail。
2.将自己的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST信息。
3.其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个
epoch只发送一次ack。
4.尝试failover的slave收集master返回的FAILOVER_AUTH_ACK。
5.slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点，如果只有两
个，当其中一个挂了，只剩一个主节点是不能选举成功的)。
6.slave广播Pong消息通知其他集群节点。
从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟，一定的延迟确保我们等待
FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票
-
延迟计算公式：DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms
-
SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方
式下，持有最新数据的slave将会首先发起选举（理论上）。
集群脑裂数据丢失问题
redis集群没有过半机制会有脑裂问题，网络分区导致脑裂后多个主节点对外提供写服务，一旦网络分区恢复，会将其中一个主节点变为从节点，这时会有大量数据丢失。规避方法可以在redis配置里加上参数(这种方法不可能百分百避免数据丢失，参考集群leader选举机制)：
min‐replicas‐to‐write 1 #写数据成功最少同步的slave数量，这个数量可以模仿大于半数机制配置，比如集群总共三个节点可以配置1，加上leader就是2，超过了半数
注意：这个配置在一定程度上会影响集群的可用性，比如slave要是少于1个，这个集群就算leader正常也不能提供服务了，需要具体场景权衡选择。
集群是否完整才能对外提供服务
当redis.conf的配置cluster-require-full-coverage为no时，表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时，集群仍然可用，如果为yes则集群不可用。
Redis集群为什么至少需要三个master节点，并且推荐节点数为奇数？
因为新master的选举需要大于半数的集群master节点同意才能选举成功，如果只有两个master节点，当其中一个挂了，是达不到选举新master的条件的。奇数个master节点可以在满足选举该条件的基础上节省一个节点，比如三个master节点和四个master节点的集群相比，大家如果都挂了一个master节点都能选举新master节点，如果都挂了两个master节点都没法选举新master节点了，所以奇数的master节点更多的是从节省机器资源角度出发说的。
Redis集群对批量操作命令的支持
对于类似mset，mget这样的多个key的原生批量操作命令，redis集群只支持所有key落在同一slot的情况，如果有多个key一定要用mset命令在redis集群上操作，则可以在key的前面加上{XX}，这样参数数据分片hash计算的只会是大括号里的值，这样能确保不同的key能落到同一slot里去，示例如下：
mset {user1}:1:name tqz {user1}:1:age 18
假设name和age计算的hash slot值不一样，但是这条命令在集群下执行，redis只会用大括号里的 user1 做hash slot计算，所以算出来的slot值肯定相同，最后都能落在同一slot。
哨兵leader选举流程
当一个master服务器被某sentinel视为下线状态后，该sentinel会与其他sentinel协商选出sentinel的leader进行故障转移工作。每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的leader，选举是先到先得。同时每个sentinel每次选举都会自增配置纪元(选举周期)，每个纪元中只会选择一个sentinel的leader。如果所有超过一半的sentinel选举某sentinel作为leader。之后该sentinel进行故障转移操作，从存活的slave中选举出新的master，这个选举过程跟集群的master选举很类似。哨兵集群只有一个哨兵节点，redis的主从也能正常运行以及选举master，如果master挂了，那唯一的那个哨兵节点就是哨兵leader了，可以正常选举新master。
不过为了高可用一般都推荐至少部署三个哨兵节点。为什么推荐奇数个哨兵节点原理跟集群奇数个master节点类似。
缓存双写、读写并发不一致
针对这两种情况带来的问题最简单也是最实用的解决方案：分布式锁
Redisson实现分布式锁
读的时候不能写，在lua脚本里面通过mode字段进行表示是read还是write，如果互斥，另一方会进行等待，写的时候也不能读，同样会进行等待。
redisson依赖：
<dependency>
<groupId>org.redissongroupId>
<artifactId>redissonartifactId>
<version>3.6.5version>
dependency>
向容器中注入一个 Redisson 对象
@Configuration
public class RedissonConfig {
@Bean
public Redisson redisson() {
Config config = new Config();
// 单机模式
config.useSingleServer().setAddress("redis://ip:6371").setDatabase(0);
// 集群模式
/* config.useClusterServers()
.addNodeAddress("redis://ip:6390")
.addNodeAddress("redis://ip:6391")
.addNodeAddress("redis://ip:6392")
.addNodeAddress("redis://ip:6393")
.addNodeAddress("redis://ip:6394")
.addNodeAddress("redis://ip:6395");*/
return (Redisson) Redisson.create(config);
}
}
然后在业务层或控制层直接引用 Redisson 对象
/**
*
*
* @autoor tianqingzhao
* @since 2021/10/14 20:14
*/
@RestController
public class RedissonController {
@Autowired
private Redisson redisson;
@RequestMapping("lock")
public String lock() {
String lockKey = "product_1";
RLock lock = redisson.getLock(lockKey);
try {
// 底层自动通过一个定时任务实现了锁续命的功能，比如当前线程没有处理完，
// 就把锁的时间延长，其他线程一直while(true)自旋等待获取锁
lock.lock();
// 可重入锁，上面加锁了之后，执行了一段业务逻辑，这里还可以加锁
// lock.lock();
// TODO 执行业务逻辑
} finally {
lock.unlock();
}
return "result";
}
@RequestMapping("readLock")
public String readLock() {
String lockKey = "product_001";
RReadWriteLock readWriteLock = redisson.getReadWriteLock(lockKey);
// 读的时候不能写，在lua脚本里面通过mode字段进行表示是read还是write，
// 如果互斥，另一方会进行等待，写的时候也不能读，同样会进行等待。
RLock lock = readWriteLock.readLock();
try {
lock.lock();
// TODO 执行业务逻辑
} finally {
lock.unlock();
}
return "result";
}
@RequestMapping("writeLock")
public String writeLock() {
String writeLock = "product_0001";
RReadWriteLock readWriteLock = redisson.getReadWriteLock(writeLock);
RLock lock = readWriteLock.writeLock();
try {
lock.unlock();
// TODO 执行业务逻辑
} finally {
lock.unlock();
}
return "result";
}
}
redisson看门狗机制
布隆过滤器
针对高并发查询redis的业务场景，可通过布隆过滤器计算该key是否存在。如果不存在，就没必要再去redis查询。
根据key通过md5/crc16/crc32等加密算法进行hash之后，然后对布隆过滤器的数组长度进行取模，最终散落到某一个位上面。
当布隆过滤器说某个key存在时，它可能不存在在，某个key不存在时，它一定不存在。
Java代码操作布隆过滤器：
/**
*
*
* @autoor tianqingzhao
* @since 2021/10/15 16:21
*/
public class BloomFilterTest {
public static void main(String[] args) {
Config config = new Config();
// 单机模式
config.useSingleServer().setAddress("redis://127.0.0.1:6371").setDatabase(0);
RedissonClient redisson = Redisson.create(config);
RBloomFilter<String> bloomFilter = redisson.getBloomFilter("myBloomFilter");
// 初始化布隆过滤器的长度和误差率(hash碰撞的概率)
bloomFilter.tryInit(100000000L, 0.03);
String key = "product_0001";
bloomFilter.add(key);
System.out.println(bloomFilter.contains(key));
System.out.println(bloomFilter.contains("product_002"));
System.out.println(bloomFilter.contains("product_003"));
}
}
布隆过滤器不能删除数据，如果要删除得重新初始化。