侧边栏壁纸
博主头像
水工雨田 博主等级

  • 累计撰写 1 篇文章
  • 累计创建 1 个标签
  • 累计收到 0 条评论

目 录CONTENT

文章目录
NoSQL

Redis6

Administrator
Administrator
2025-05-13 / 0 评论 / 2 点赞 / 123 阅读 / 0 字

Redis6

NoSQL简介

NoSQL概述

  • NoSQL(Not only SQL) ,意味非仅仅是SQL,泛指非关系型数据库

  • NoSQL不依赖业务逻辑方式存储,而以简单的key-value模式存储,因此大大增强了数据库的扩展能力

    • 不遵循SQL标准

    • 不支持ACID

    • 远超与SQL性能

NoSQL适用场景

  • 对于数据高并发的读写

  • 海量数据的读写

  • 对数据高可扩展的

NoSQL不适用的场景

  • 需要事务的支持

  • 基于SQL的结构化查询存储,处理复杂的关系,即需要及时查询

  • 用不着SQL和用了SQL也不行的情况,请考虑适用NoSQL

Redis安装

Redis的五大数据类型

String字符串类型

  • String是Redis最基本的类型,一个key对应一个value

  • String类型是二进制安全的,意味着Redis的String可以包含任何数据,比如jpg图片或者序列化的对象

  • String类型是Redis最基本的数据类型,一个Redis中字符串中value最多可以使512M

常用命令

  • set key value 在数据库中添加元素

  • get <key>查询对应键值

  • append <key><value>将给定的<value> 追加到原值的末尾

  • strlen <key>获得值的长度

  • setnx <key><value>只有在 key 不存在时 设置 key 的值

  • incr <key>

    • 将 key 中储存的数字值增1

    • 只能对数字值操作，如果为空，新增值为1

  • decr <key>

    • 将 key 中储存的数字值减1

    • 只能对数字值操作，如果为空，新增值为-1

  • incrby / decrby <key><步长>将 key 中储存的数字值增减。自定义步长。

incr 是原子操作:

所谓原子操作是指不会被线程调度机制打断的操作；

这种操作一旦开始，就一直运行到结束，中间不会有任何 context switch （切换到另一个线程）。

（1）在单线程中， 能够在单条指令中完成的操作都可以认为是"原子操作"，因为中断只能发生于指令之间。

（2）在多线程中，不能被其它进程（线程）打断的操作就叫原子操作。

Redis单命令的原子性主要得益于Redis的单线程。

  • mset <key1><value1><key2><value2> ..... 同时设置一个或多个 key-value对

  • mget <key1><key2><key3> ..... 同时获取一个或多个 value

  • msetnx <key1><value1><key2><value2> ..... 同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。,有一个key存在时设置会失败,(原子性，有一个失败则都失败)

  • getrange <key><起始位置><结束位置> 获得值的范围，类似java中的substring，前包，后包

  • setrange <key><起始位置><value> 用 <value> 覆写<key>所储存的字符串值，从<起始位置>开始(索引从0开始),在指定索引位置插入元素

  • setex <key><过期时间><value>设置键值的同时，设置过期时间，单位秒。

  • getset <key><value> 以新换旧，设置了新值同时获得旧值。

数据结构

String 的数据结构为简单动态字符串(Simple Dynamic String ,简称SDS)是可以修改的字符串,内部结构实现上类似于Java的ArrayList ,采用预分配冗余空间的方式来减少内存的频繁分配,实际分配的字符串长度一般要高于实际的字符串长度,当字符串长度小于1M时,扩容都是加倍现有的空间,如果超过1M,扩容一次只会只会多扩1M的空间,需要注意的是字符串最大长度为512M

list列表

简述

  • 单键多值

  • Redis列表是简单的字符串列表,按照插入顺序排序,可以添加一个元素到列表的头部(左边)或者尾部(右边)

  • 它的底层实际是个双向链表,对两端的操作性能很高,通过索引下标的操作中间节点的性能会较差

常用命令

  • lpush/rpush <key><value1><value2><value3> .... 从左边/右边插入一个或多个值。

  • lpop/rpop <key>从左边/右边吐出一个值。值在键在，值光键亡。

  • rpoplpush <key1><key2>从<key1>列表右边吐出一个值，插到<key2>列表左边。

  • lrange <key><start><stop> 按照索引下标获得元素(从左到右)

    • lrange mylist 0 -1 0左边第一个，-1右边第一个，（0-1表示获取所有）

  • lindex <key><index>按照索引下标获得元素(从左到右)

  • linsert <key> before <value><newvalue>在<value>的后面插入<newvalue>插入值(可以before 也可以after)

  • lrem <key><n><value>从左边删除n个value(从左到右)

  • lset<key><index><value>将列表key下标为index的值替换成value

数据结构

List的数据结构为快速链表quickList,首先在列表元素较少的情况下会使用一块连续的内存存储,这个结构是ziplist,即是压缩列表

他将所有的元素紧挨着一起存储,分配的是一块连续的内存,当数据量比较多的时候才会改成quicklist,因为普通链表需要的附加指针空间太大,会比较浪费空间,Redis将链表和ziplist结合起来组成了quicklist.也就是将ziplist使用双向指针穿起来使用,这样既满足了快速插入删除性能,又不会出现太大空间冗余

Set集合

简介

set是与list类似的一个列表功能,特殊之处在于set是可以自动排重的,set提供了判断某个成员是否在一个set集合内的重要接口,list没有

Redis的set是sting类型的无序集合,它底层是一个value为null的哈希表,所以添加,删除,查找的复杂度都是O(1)

常用命令

  • sadd <key><value1><value2> ..... 将一个或多个 member 元素加入到集合 key 中，已经存在的 member 元素将被忽略

  • smembers <key>取出该集合的所有值。

  • sismember <key><value>判断集合<key>是否为含有该<value>值，有1，没有0

  • scard<key>返回该集合的元素个数。

  • srem <key><value1><value2> .... 删除集合中的某个元素。

  • spop <key>随机从该集合中吐出一个值。

  • srandmember <key><n>随机从该集合中取出n个值。不会从集合中删除 。

  • smove <source><destination>value把集合中一个值从一个集合移动到另一个集合

  • sinter <key1><key2>返回两个集合的交集元素。

  • sunion <key1><key2>返回两个集合的并集元素。

  • sdiff <key1><key2>返回两个集合的差集元素(key1中的，不包含key2中的)

数据结构

Set数据结构是dict字典，字典是用哈希表实现的。

Java中HashSet的内部实现使用的是HashMap，只不过所有的value都指向同一个对象。Redis的set结构也是一样，它的内部也使用hash结构，所有的value都指向同一个内部值。

哈希

简介

Redis Hash是一个键值对集合

Redis Hash是一个String 类型的field和value的映射表,Hash特别适合用于存储对象,类似java中的Map<String,Object>

常用命令

  • hset <key><field><value>给<key>集合中的 <field>键赋值<value>

  • hget <key1><field>从<key1>集合<field>取出 value

  • hmset <key1><field1><value1><field2><value2>... 批量设置hash的值

  • hexists<key1><field>查看哈希表 key 中，给定域 field 是否存在。

  • hkeys <key>列出该hash集合的所有field

  • hvals <key>列出该hash集合的所有value

  • hincrby <key><field><increment>为哈希表 key 中的域 field 的值加上增量 1 -1

  • hsetnx <key><field><value>将哈希表 key 中的域 field 的值设置为 value ，当且仅当域 field 不存在 .

数据结构

Hash类型对应的数据结构是两种：ziplist（压缩列表），hashtable（哈希表）。当field-value长度较短且个数较少时，使用ziplist，否则使用hashtable。

有序集合zset

简介

Redis有序集合zset与普通集合set非常相似，是一个没有重复元素的字符串集合。

不同之处是有序集合的每个成员都关联了一个评分（score）,这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分可以是重复了 。

因为元素是有序的, 所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。

访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。

常用命令

  • zadd <key><score1><value1><score2><value2>… 将一个或多个 member 元素及其 score 值加入到有序集 key 当中。

  • zrange <key><start><stop> [WITHSCORES] 返回有序集 key 中，下标在<start><stop>之间的元素 带WITHSCORES，可以让分数一起和值返回到结果集。

  • zrangebyscore key minmax [withscores] [limit offset count] 返回有序集 key 中，所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。有序集成员按 score 值递增(从小到大)次序排列。

  • zrevrangebyscore key maxmin [withscores] [limit offset count] 同上，改为从大到小排列。

  • zincrby <key><increment><value> 为元素的score加上增量

  • zrem <key><value>删除该集合下，指定值的元素

  • zcount <key><min><max>统计该集合，分数区间内的元素个数

  • zrank <key><value>返回该值在集合中的排名，从0开始。

数据结构

SortedSet(zset)是Redis提供的一个非常特别的数据结构，一方面它等价于Java的数据结构Map<String, Double>，可以给每一个元素value赋予一个权重score，另一方面它又类似于TreeSet，内部的元素会按照权重score进行排序，可以得到每个元素的名次，还可以通过score的范围来获取元素的列表。

zset底层使用了两个数据结构

（1）hash，hash的作用就是关联元素value和权重score，保障元素value的唯一性，可以通过元素value找到相应的score值。

（2）跳跃表，跳跃表的目的在于给元素value排序，根据score的范围获取元素列表。

发布和订阅

简介

  • 是一种消息的通信模式:发送者(pub)发送消息,订阅者(sub)接收消息

  • Redis客户端可以订阅任意数量的频道

Redis6的新数据类型

Bitmaps

简介

  • Redis提供了Bitmaps这个数据类型可以实现对位的操作

    • Bitmaps本身不是一种数据类型,实际上他就是字符串(key-value),但是他可以对字符串的位进行操作

    • Bitmaps单独提供了一套命令,所以在Redis中使用Bitmaps和使用字符串的方法不太相同.可以把Bitmaps想象成一个以位为单位的数组,每个单位之存储0和1,数组的下标在Bitmaps中叫做偏移量

使用基本命令

  • setbit

    • 格式:setbit<key><offset><value>设置Bitmaps中某个偏移量的值（0或1） ,偏移量从0开始

      setbit users:20210101 11 1

    • 在第一次初始化Bitmaps时， 假如偏移量非常大， 那么整个初始化过程执行会比较慢， 可能会造成Redis的阻塞。

  • getbit

    • 格式:getbit<key><offset>获取Bitmaps中某个偏移量的值,获取键的第offset位的值（从0开始算）

      getbit users:20210101 19

  • bitcount

    • 统计字符串被设置为1的bit数。一般情况下，给定的整个字符串都会被进行计数，通过指定额外的 start 或 end 参数，可以让计数只在特定的位上进行。start 和 end 参数的设置，都可以使用负数值：比如 -1 表示最后一个位，而 -2 表示倒数第二个位，start、end 是指bit组的字节的下标数，二者皆包含。

  • bitop and(or/not/xor) <destkey> [key…] bitop是一个复合操作， 它可以做多个Bitmaps的and（交集） 、 or（并集） 、 not（非） 、 xor（异或） 操作并将结果保存在destkey中。

Bitmaps与set对比

HyperLogLog

简介

Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且是很小的。

在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

基本操作

  • pfadd pfadd <key>< element> [element ...] 添加指定元素到 HyperLogLog 中 将所有元素添加到指定HyperLogLog数据结构中。如果执行命令后HLL估计的近似基数发生变化，则返回1，否则返回0。

  • pfcount pfcount<key> [key ...] 计算HLL的近似基数，可以计算多个HLL

  • pfmerge pfmerge<destkey><sourcekey> [sourcekey ...] 将一个或多个HLL合并后的结果存储在另一个HLL中

Geospatial

简介

Redis 3.2 中增加了对GEO类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。

命令

  • geoadd geoadd<key>< longitude><latitude><member> [longitude latitude member...] 添加地理位置（经度，纬度，名称）

    两极无法直接添加，一般会下载城市数据，直接通过 Java 程序一次性导入。

    有效的经度从 -180 度到 180 度。有效的纬度从 -85.05112878 度到 85.05112878 度。

    当坐标位置超出指定范围时，该命令将会返回一个错误。

    已经添加的数据，是无法再次往里面添加的。

  • geopos <key><member> [member...] 获得指定地区的坐标值

  • geodist geodist<key><member1><member2> [m|km|ft|mi ] 获取两个位置之间的直线距离

    单位：

    m 表示单位为米[默认值]。

    km 表示单位为千米。

    mi 表示单位为英里。

    ft 表示单位为英尺。

    如果用户没有显式地指定单位参数， 那么 GEODIST 默认使用米作为单位

  • georadius<key>< longitude><latitude>radius m|km|ft|mi 以给定的经纬度为中心，找出某一半径内的元素

Jedis

SpringBoot整合Redis

  1. 配置文件

    #Redis服务器地址
spring.redis.host=192.168.150.101
#Redis服务器连接端口
spring.redis.port=6379
#Redis数据库索引（默认为0）
spring.redis.database= 0
#连接超时时间（毫秒）
spring.redis.timeout=1800000
#连接池最大连接数（使用负值表示没有限制）
spring.redis.lettuce.pool.max-active=20
#最大阻塞等待时间(负数表示没限制)
spring.redis.lettuce.pool.max-wait=-1
#连接池中的最大空闲连接
spring.redis.lettuce.pool.max-idle=5
#连接池中的最小空闲连接
spring.redis.lettuce.pool.min-idle=0

  2. 配置类

    import com.fasterxml.jackson.annotation.JsonAutoDetect;
import com.fasterxml.jackson.annotation.PropertyAccessor;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.springframework.cache.CacheManager;
import org.springframework.cache.annotation.CachingConfigurerSupport;
import org.springframework.cache.annotation.EnableCaching;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.cache.RedisCacheConfiguration;
import org.springframework.data.redis.cache.RedisCacheManager;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.serializer.Jackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.RedisSerializationContext;
import org.springframework.data.redis.serializer.RedisSerializer;
import org.springframework.data.redis.serializer.StringRedisSerializer;
​
import java.time.Duration;
​
@EnableCaching
@Configuration
public class RedisConfig extends CachingConfigurerSupport {
​
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        RedisSerializer<String> redisSerializer = new StringRedisSerializer();
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(om);
        template.setConnectionFactory(factory);
        //key序列化方式
        template.setKeySerializer(redisSerializer);
        //value序列化
        template.setValueSerializer(jackson2JsonRedisSerializer);
        //value hashmap序列化
        template.setHashValueSerializer(jackson2JsonRedisSerializer);
        return template;
    }
​
    @Bean
    public CacheManager cacheManager(RedisConnectionFactory factory) {
        RedisSerializer<String> redisSerializer = new StringRedisSerializer();
        Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
        //解决查询缓存转换异常的问题
        ObjectMapper om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        jackson2JsonRedisSerializer.setObjectMapper(om);
        // 配置序列化（解决乱码的问题）,过期时间600秒
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofSeconds(600))
                .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(redisSerializer))
                .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(jackson2JsonRedisSerializer))
                .disableCachingNullValues();
        RedisCacheManager cacheManager = RedisCacheManager.builder(factory)
                .cacheDefaults(config)
                .build();
        return cacheManager;
    }
}
​

  3. 测试

    @RequestMapping("/redisTest")
public class RedisTestController {
​
    @Autowired
    private RedisTemplate redisTemplate;
​
    @GetMapping
    public String testRedis(){
        //设置值到Redis中
        redisTemplate.opsForValue().set("name","lucy");
        //从redis中获取
        String name = (String)redisTemplate.opsForValue().get("name");
        return name;
    }
}

Redis的事务操作

  • Redis的事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序的执行.事务在执行过程中,不会被其他客户端发来的请求所打断

  • Redis事务的主要作用就是串联多个命令防止别的命令插队

Multi、Exec、discard

  • 从输入Multi命令开始,输入的命令都会依次进入命令队列中,但是不会执行,直到输入Exec后,Redis会将之前的命令队列中的命令依次执行

  • 组队的过程中可以通过discard来放弃组队

  • 组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

事务冲突的问题

悲观锁

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

乐观锁

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

  • WATCH key [key ...]

    • 在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

  • unwatch

    • 取消 WATCH 命令对所有 key 的监视。

      如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。

Redis事务的三特性

  • 单独的隔离操作

    • 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

  • 没有隔离级别的概念

    • 队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行

  • 不保证原子性

    • 事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

持久化之RDB

是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

如何执行的

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失。

FORK

  • Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

  • 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”

  • 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

RDB相关的配置

  • 配置临时文件的名称

  • 快照文件的生成路径

  • 压缩、检查完整性、无法写入磁盘时,关闭redis,检查完整性时会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭该功能

  • save命令 格式:save 秒钟 写操作次数(默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。), 禁用时:不设置save指令，或者给save传入空字符串

REB的备份

  • 先通过config get dir 查询rdb文件的目录

  • 将*.rdb的文件拷贝到别的地方

  • rdb的恢复

    • 关闭Redis

    • 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb

    • 启动Redis, 备份数据会直接加载

RDB的优势

  • 适合大规模的数据恢复

  • 对数据完整性和一致性要求不高更适合使用

  • 节省磁盘空间

  • 恢复速度快

RDB的劣势

  • Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

  • 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

  • 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

持久化之AOF

AOF是什么

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF的持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

AOF补充

  • AOF默认不开启

  • 可以在redis.conf中配置文件名称,默认为appendonly.aof

  • AOF的文件保存路径与RDB的路径一致

  • AOF和RDB同时开启,系统默认取AOF的数据(数据不会存在丢失)

AOF启动/修复/恢复

  • AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

  • 正常恢复

    • 修改默认的appendonly no，改为yes

    • 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)

    • 恢复：重启redis然后重新加载

  • 异常恢复

    • 修改默认的appendonly no，改为yes

    • 如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复

    • 备份被写坏的AOF文件

  • 恢复：重启redis，然后重新加载

同步频率设置

  • appendfsync always 始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

  • appendfsync everysec 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

  • appendfsync no redis不主动进行同步，把同步时机交给操作系统。

优势

  • 备份机制更稳健，丢失数据概率更低。

  • 可读的日志文本，通过操作AOF稳健，可以处理误操作。

劣势

  • 比起RDB占用更多的磁盘空间。

  • 恢复备份速度要慢。

  • 每次读写都同步的话，有一定的性能压力。

  • 存在个别Bug，造成恢复不能。

与RDB比较

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

主从复制

  • 主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制,Master以写为主，Slave以读为主(一主多从)

作用

  • 读写分离，性能扩展

  • 容灾快速恢复

模拟

  1. 创建/myredis文件夹

  2. 赋值redis.conf配置文件到文件夹中

  3. 配置一主两从配置文件

    1. redis6379.conf

    2. redis6380.conf

    3. redis6381.conf

  4. 在三个配置文件中写入内容

Redis在应用过程中的问题

缓存穿透

现象

  1. 应用服务器压力突然变大

  2. redis命中率降低

  3. 一直查询数据库

原因

  1. redis查询不到数据

  2. 出现很多非正常url访问(恶意攻击)

解决方案

（1） 对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟

（2） 设置可访问的名单（白名单）：

使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。

（3） 采用布隆过滤器：(布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）。

布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。)

将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被 这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。

（4） 进行实时监控：当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

缓存击穿

现象

  1. 数据库访问压力瞬时增加

  2. redis里面没有出现大量key过期

  3. redis正常运行

原因

  1. redis中某个key过期了,大量访问使用这个key

解决方案

  1. 预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长

  2. 实时调整：现场监控哪些数据热门，实时调整key的过期时长

  3. 使用锁：

（1） 就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。

（2） 先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key

（3） 当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；

（4） 当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。

缓存雪崩

现象

  1. 数据库压力变大,服务器崩溃

原因

  1. 在极少的时间段,查询大量的key的集中过期情况

解决方案

（1） 构建多级缓存架构：nginx缓存 + redis缓存 +其他缓存（ehcache等）

（2） 使用锁或队列：

用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况

（3） 设置过期标志更新缓存：

记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。

（4） 将缓存失效时间分散开：

比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

分布式锁

随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

解决

  • setnx 上锁,通过del释放锁

  • 设置过期时间,自动释放

  • 上锁之后突然出现异常,无法设置过期时间

    • 上锁时同时设置过期时间 set key 10 nx ex 12

EX second ：设置键的过期时间为 second 秒。 SET key value EX second 效果等同于 SETEX key second value 。

PX millisecond ：设置键的过期时间为 millisecond 毫秒。 SET key value PX millisecond 效果等同于 PSETEX key millisecond value 。

NX ：只在键不存在时，才对键进行设置操作。 SET key value NX 效果等同于 SETNX key value 。

XX ：只在键已经存在时，才对键进行设置操作。

2
版权归属： Administrator
本文链接： https://wsgyt.cn/archives/redis6
许可协议： 本文使用《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》协议授权

评论区