Redis集群概念及简单使用

最新推荐文章于 2024-05-03 14:34:16 发布

拨开乌云

最新推荐文章于 2024-05-03 14:34:16 发布

阅读量453

点赞数

分类专栏： redis 文章标签： redis java 数据库

本文链接：https://blog.csdn.net/m0_49556309/article/details/125327639

版权

redis 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

一、压力测试
二、bitmap
- 命令使用
三、事务
- 开启事务
- 放弃事务
四、雪崩和穿透、击穿及解决方法
五、Redis集群讲解

一、压力测试

redis-benchmark 是一个压力测试工具！下载redis自带。

二、bitmap

Bitmap 位图，数据结构！都是操作二进制位来进行记录，就只有0 和 1 两个状态，
可以用来记录周一到周五打卡

命令使用

setbit gt(key名称)  1(周一自定义)  0(未打卡)
getbit gt(key) 1(时间)
bitcount gt (获取总计打卡次数)

三、事务

开启事务

multi

命令入队

set key value1
set key value2
set key value3

执行事务

exec

放弃事务

开启事务

multi

命令入队

set key value

取消事务

discard

四、雪崩和穿透、击穿及解决方法

缓存穿透

先走redis（没有数据）再走mysql（没有数据），此时请求回去也没有数据null，则redis不会缓存，这就是缓存穿透。
解决方案
1）在redis中缓存空对象
2）使用redis布隆过滤器：它相当于是一个容器，通过hash函数对key进行hash运算得到一个整数索引值每个函数都会的到一个值，将其位置变为1，这表示这里存在这个数据，否则不存在。只要有一位是0就表示这个key不存在，但如果都是1，则不一定存在对应的key(因为算出来的hash有可能相同)
guava 工具实现布隆过滤器

package com.ys.rediscluster.bloomfilter;
 
import com.google.common.base.Charsets;
import com.google.common.hash.BloomFilter;
import com.google.common.hash.Funnel;
import com.google.common.hash.Funnels;
 
public class GuavaBloomFilter {
    public static void main(String[] args) {
        BloomFilter<String> bloomFilter = BloomFilter.create(Funnels.stringFunnel(Charsets.UTF_8),100000,0.01);
 
        bloomFilter.put("10086");
 
        System.out.println(bloomFilter.mightContain("123456"));
        System.out.println(bloomFilter.mightContain("10086"));
    }
}

缓存击穿

大量的请求先到redis但是刚到的时候就发现key过期了，这个大量的请求就全部达到了mysql，打在数据库很容易将其打崩。
解决方案：设置过期key的时候不要把时间都设置成相同的过期时间。避免这些key在同一时间过期。或者设置永不过期，再更新的时候也可以刷新过期时间等等。

缓存雪崩

在某一时刻缓存集中失效，或者缓存系统出现故障，所有的并发流量就会直接到达数据库。数据存储层的调用量就会暴增，用不了多长时间，数据库就会被大流量压垮，这种级联式的服务故障，就叫作缓存雪崩。
解决方案：设置集群高可用，做限流处理，预热方式将数据放到redis中并为其设置不同的过期时间

五、Redis集群讲解

主从同步/复制

概念：至少需要两个服务器一个主服务器master（写）一个从服务器salve（读）并且主服务器只能有一个，实现原理主要分为两步
1）同步（sync）由从服务器发送同步命令（sync）到主服务器，主服务器收到命令后就会生成rdb快照文件，发送给从服务器
2）命令传播（command propagate）当主服务器的数据被修改时，然后将这些命令存起来在发送给从服务器
为什么需要同步和命令传播
1）只有同步操作的时候从服务器会像主服务器发送同步命令，然后主服务器在生成rdb快照的时候，也可能会收到修改数据的请求，这样就会存在数据不一致的情况，然后就有了命令传播，在生成rdb快照文件的时候同时把后续来的修改请求指令存在缓存去最后在以命令传播的形式发送给从服务器。
综上
同步命令sync是由从服务器发起
命令传播command propagate是由主服务器发起
如图
执行流程
优缺点
1）优点：实现了读写分离，提高可用性，解决单机故障
2）缺点：master宕机后需要人为的去切换从服务器salve为主服务器（切换的时候可以通过域名切换，绑定ip解析到原来的域名上）并且也有可能出现数据不一致的情况，在宕机的过程中数据没有完全同步。

哨兵模式Sentinel

概念：哨兵模式是一种特殊的模式，redis内部提供了哨兵命令，哨兵是一个单独的进程，能够独立运行，通过发送指令等待redis的回应从而监控多个redis实例
模型如下：
在这里插入图片描述

工作原理
1）哨兵通过发送命令到各个redis实例，等待他们的响应，从而实现检测redis实例是否正常运行
2）当哨兵模式检测到主机master宕机后，可以自动切换slave为master完成从主切换，然后通过订阅模式通知其他服务器更改配置文件以及切换主机等操作。注意：这里可能会出现哨兵宕机问题，所有还有中情况就是多哨兵集群模式
多哨兵模式
在这里插入图片描述

1）哨兵与哨兵之间也存在监控
2）当一个哨兵检测到master服务器下线时不会立马诊断为下线状态而切换slave为master而是当其他的哨兵同时检测到master下线时并且达到一定量的时候就会切换从主，这就是客观下线。
总结：以上两点都存在在线扩容性不好（水平扩容：增加服务器数据不好同步，需要重新配置），而且哨兵模式的配置也及其麻烦（上面两种都不推荐使用）

Cluster集群

在这里插入图片描述

Cluster集群理论
1）Redis Cluster集群采取Hash Slot（哈西槽）进行数据分配
2）Redis Cluster共有16384个槽，初始化集群的时候平均划分给每个服务器（master）
3）存取数据的时候根据crc16算法算出一个值再放到（取出）与之对于的卡槽的服务上
4）如果某一个服务器且是master服务器挂掉了，并且他也没有从节点那么整个集群都将会是瘫痪状态，相反如果存在从节点那么就会有从节点来代替这个主节点
5）相比上面集中集群模式，好处在与方便扩容，如果出现几台master服务器就直接16384/master服务器个数=每个服务器上应该存在的卡槽数。
6）以上两个集群方式每个服务器存的都是全量数据，可用性降低了，而cluster是平均分布在每个服务器上，所以很多大厂都用的这套模式，比如：美团、阿里巴巴等等。