【Redis】学习笔记

最新推荐文章于 2024-08-16 11:46:49 发布
最新推荐文章于 2024-08-16 11:46:49 发布
阅读量77 收藏
点赞数
分类专栏： 后端技术栈 java 文章标签： redis 数据库 java linux 分布式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/danggang0317/article/details/112989214
版权

Redis学习笔记

基本概述

Redis 全称REmote DIctionary Server，是一个由Salvatore Sanfilippo写的key-value存储系统。

Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

它通常被称为数据结构服务器，因为值（value）可以是 字符串(String), 哈希(Hash), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。

特点

  • Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
  • Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
  • Redis支持数据的备份，即master-slave模式的数据备份。

优势

  • 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
  • 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。

安装

安装教程

数据类型

基本数据类型

  • String 字符串
  • List 列表
  • Set 集合
  • ZSet 有序集合
  • Hash 字典

特殊数据类型

  • GEO 地理位置
  • HyperLogLog 基数
  • BitMap 位

具体命令见官网

数据类型使用场景

类型简介特性场景
String(字符串)二进制安全可以包含任何数据,比如jpg图片或者序列化的对象,一个键最大能存储512M—
Hash(字典)键值对集合,即编程语言中的Map类型适合存储对象,并且可以像数据库中update一个属性一样只修改某一项属性值(Memcached中需要取出整个字符串反序列化成对象修改完再序列化存回去)存储、读取、修改用户属性
List(列表)链表(双向链表)增删快,提供了操作某一段元素的API1,最新消息排行等功能(比如朋友圈的时间线) 2,消息队列
Set(集合)哈希表实现,元素不重复1、添加、删除,查找的复杂度都是O(1) 2、为集合提供了求交集、并集、差集等操作1、共同好友 2、利用唯一性,统计访问网站的所有独立ip 3、好友推荐时,根据tag求交集,大于某个阈值就可以推荐
Sorted Set(有序集合)将Set中的元素增加一个权重参数score,元素按score有序排列数据插入集合时,已经进行天然排序1、排行榜 2、带权重的消息队列
GEO主要用于存储地理位置信息，并对存储的信息进行操作—1、附近的人 2、直线距离
HyperLogLog用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定 的、并且是很小的。—用来统计此数（不重复）

基本事物操作

Redis事物不具备原子性，当有运行是异常时其他行会执行；编译异常时都不会执行。

MULTI开始事物
EXEC执行事物

redis 127.0.0.1:6379> MULTI
OK

redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
QUEUED

redis 127.0.0.1:6379> GET book-name
QUEUED

redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"
QUEUED

redis 127.0.0.1:6379> SMEMBERS tag
QUEUED

redis 127.0.0.1:6379> EXEC
1) OK
2) "Mastering C++ in 21 days"
3) (integer) 3
4) 1) "Mastering Series"
   2) "C++"
   3) "Programming"

Redis可以实现乐观锁，使用watch

java使用redis

  • jedis
  • RedisTemplate

Redis 持久化

redis是一个内存数据库，数据保存在内存中，但是我们都知道内存的数据变化是很快的，也容易发生丢失。幸好Redis还为我们提供了持久化的机制，分别是RDB(Redis> DataBase)和AOF(Append Only File)。

RDB

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

在我们安装了redis之后，所有的配置都是在redis.conf文件中，里面保存了RDB和AOF两种持久化机制的各种配置。

RDB的三种触发机制

  • save触发方式：该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。
  • bgsave触发方式：执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。
  • 自动触发：自动触发是由我们的配置文件来完成的。详解

RDB 的优势和劣势

1. 优势：

  • RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
  • 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
  • RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2. 劣势：

RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。

AOF

全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。

AOF的三种触发机制
（1）每修改同步always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好

（2）每秒同步everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失

（3）不同no：从不同步

命令alwayseverysecno
优点不丢失数据每秒一次fsync丢一秒数据不用管
缺点IO开销较大，一般的SATA盘只有几百TPS丢1秒数据不可控

AOF的优缺点

优点：

（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。

（2）AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。

（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。

（4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

缺点：

（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大

（2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的

（3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。

RDB和AOF对比

命令RDBAOF
启动优先级低高
体积小大
恢复速度快慢
数据安全性丢数据根据策略决定
轻量重轻

Redis发布订阅

在这里插入图片描述
在这里插入图片描述

## 订阅者 
redis 127.0.0.1:6379> SUBSCRIBE runoobChat

Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1

## 发布消息
redis 127.0.0.1:6379> PUBLISH runoobChat "Redis PUBLISH test"

(integer) 1

redis 127.0.0.1:6379> PUBLISH runoobChat "Learn redis by runoob.com"

(integer) 1


# 订阅者的客户端会显示如下消息
 1) "message"
2) "runoobChat"
3) "Redis PUBLISH test"
 1) "message"
2) "runoobChat"
3) "Learn redis by runoob.com"

订阅原理

说明：每个 Redis 服务器进程都维持着一个表示服务器状态的 redis.h/redisServer 结构， 结构的pubsub_channels 属性是一个字典， 这个字典就用于保存订阅频道的信息，其中，字典的键为正在被订阅的频道，而字典的值则是一个链表， 链表中保存了所有订阅这个频道的客户端。

例子示意图：在下图展示的这个 pubsub_channels 示例中， client2 、 client5 和 client1 就订阅了channel1 ， 而其他频道也分别被别的客户端所订阅。

在这里插入图片描述

操作：当客户端调用 SUBSCRIBE 命令时， 程序就将客户端和要订阅的频道在 pubsub_channels 字典中关联起来。

示意图：如果客户端 client10086 执行命令 SUBSCRIBE channel1 channel2 channel3
，那么前面展示的 pubsub_channels 将变成下面这个样子，通过遍历所有输入频道。

在这里插入图片描述

发布信息原理

原理说明：当调用 PUBLISH channel message 命令， 程序首先根据 channel 定位到字典的键，然后将信息发送给字典值链表中的所有客户端。

例子示意图：对于以下这个 pubsub_channels 实例， 如果某个客户端执行命令 PUBLISH channel1 “hello moto” ，那么 client2 、 client5 和 client1 三个客户端都将接收到 “hello moto”
信息，通过遍历订阅频道的所有客户端。

在这里插入图片描述

Redis主从复制

和Mysql主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。下图为级联结构。

在这里插入图片描述
主从链接(slave链接master)

方式一：客户端发送命令

slaveof< masterip>< masterport>

方式二：启动服务器参数

redis-server -slaveof < masterip>< masterport>

方式三：服务器配置

slaveof < masterip>< masterport>

主从断开链接

客户端发送命令

slaveof no one

全量同步
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：

  • 从服务器连接主服务器，发送SYNC命令；
  • 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
  • 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
  • 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
  • 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
  • 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

增量同步
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

Redis主从同步策略
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

更多详解

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。

哨兵模式

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
在这里插入图片描述
哨兵有两个作用

  • 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。

  • 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

在这里插入图片描述

用文字描述一下故障转移（failover）的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。

如果主机回来了，只能在现在的主机下当做从机。

首先配置Redis的主从服务器，修改redis.conf文件如下

# 使得Redis服务器可以跨网络访问
bind 0.0.0.0
# 设置密码
requirepass "123456"
# 指定主服务器，注意：有关slaveof的配置只是配置从服务器，主服务器不需要配置
slaveof 192.168.11.128 6379
# 主服务器密码，注意：有关slaveof的配置只是配置从服务器，主服务器不需要配置
masterauth 123456

上述内容主要是配置Redis服务器，从服务器比主服务器多一个slaveof的配置和密码。

配置3个哨兵，每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinel.conf文件，copy一份进行修改

# 禁止保护模式
protected-mode no
# 配置监听的主服务器，这里sentinel monitor代表监控，mymaster代表服务器的名称，可以自定义，192.168.11.128代表监控的主服务器，6379代表端口，2代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。
sentinel monitor mymaster 192.168.11.128 6379 2
# sentinel author-pass定义服务的密码，mymaster是服务名称，123456是Redis服务器密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

上述关闭了保护模式，便于测试。

有了上述的修改，我们可以进入Redis的安装目录的src目录，通过下面的命令启动服务器和哨兵

# 启动Redis服务器进程
./redis-server ../redis.conf
# 启动哨兵进程
./redis-sentinel ../sentinel.conf

注意启动的顺序。首先是主机（192.168.11.128）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。

哨兵模式

优点：

  1. 哨兵集群，基于主从复制模式，所有的主从复制优点，他都有。
  2. 主从可以切换，故障可以转移，系统的可用性就会更好。
  3. 哨兵模式就是主从模式的升级，从手动到自动，更加健壮！
    缺点：
  4. Redis不好在线扩容，当集群达到一定规模，再扩容就十分麻烦！
  5. 实现哨兵配置实际上是很麻烦的，里面的选择有很多！

哨兵模式的其他配置

配置项参数类型作用
port整数启动哨兵进程端口
dir文件夹目录哨兵进程服务临时文件夹，默认为/tmp，要保证有可写入的权限
sentinel down-after-milliseconds<服务名称><毫秒数（整数）>指定哨兵在监控Redis服务时，当Redis服务在一个默认毫秒数内都无法回答时，单个哨兵认为的主观下线时间，默认为30000（30秒）
sentinel parallel-syncs<服务名称><服务器数（整数）>指定可以有多少个Redis服务同步新的主机，一般而言，这个数字越小同步时间越长，而越大，则对网络资源要求越高
sentinel failover-timeout<服务名称><毫秒数（整数）>指定故障切换允许的毫秒数，超过这个时间，就认为故障切换失败，默认为3分钟
sentinel notification-script<服务名称><脚本路径>指定sentinel检测到该监控的redis实例指向的实例异常时，调用的报警脚本。该配置项可选，比较常用

sentinel down-after-milliseconds配置项只是一个哨兵在超过规定时间依旧没有得到响应后，会自己认为主机不可用。对于其他哨兵而言，并不是这样认为。哨兵会记录这个消息，当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover，此时哨兵会重写Redis的哨兵配置文件，以适应新场景的需要。

Java中使用哨兵模式

/**
 * 测试Redis哨兵模式
 * @author liu
 */
public class TestSentinels {
    @SuppressWarnings("resource")
    @Test
    public void testSentinel() {
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        jedisPoolConfig.setMaxTotal(10);
        jedisPoolConfig.setMaxIdle(5);
        jedisPoolConfig.setMinIdle(5);
        // 哨兵信息
        Set<String> sentinels = new HashSet<>(Arrays.asList("192.168.11.128:26379",
                "192.168.11.129:26379","192.168.11.130:26379"));
        // 创建连接池
        JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels,jedisPoolConfig,"123456");
        // 获取客户端
        Jedis jedis = pool.getResource();
        // 执行两个命令
        jedis.set("mykey", "myvalue");
        String value = jedis.get("mykey");
        System.out.println(value);
    }
}

上面是通过Jedis进行使用的，同样也可以使用Spring进行配置RedisTemplate使用。

<bean id = "poolConfig" class="redis.clients.jedis.JedisPoolConfig">
    <!-- 最大空闲数 -->
    <property name="maxIdle" value="50"></property>
    <!-- 最大连接数 -->
    <property name="maxTotal" value="100"></property>
    <!-- 最大等待时间 -->
    <property name="maxWaitMillis" value="20000"></property>
</bean>

<bean id="connectionFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory">
    <constructor-arg name="poolConfig" ref="poolConfig"></constructor-arg>
    <constructor-arg name="sentinelConfig" ref="sentinelConfig"></constructor-arg>
    <property name="password" value="123456"></property>
</bean>

<!-- JDK序列化器 -->
<bean id="jdkSerializationRedisSerializer" class="org.springframework.data.redis.serializer.JdkSerializationRedisSerializer"></bean>

<!-- String序列化器 -->
<bean id="stringRedisSerializer" class="org.springframework.data.redis.serializer.StringRedisSerializer"></bean>

<bean id="redisTemplate" class="org.springframework.data.redis.core.RedisTemplate">
    <property name="connectionFactory" ref="connectionFactory"></property>
    <property name="keySerializer" ref="stringRedisSerializer"></property>
    <property name="defaultSerializer" ref="stringRedisSerializer"></property>
    <property name="valueSerializer" ref="jdkSerializationRedisSerializer"></property>
</bean>

<!-- 哨兵配置 -->
<bean id="sentinelConfig" class="org.springframework.data.redis.connection.RedisSentinelConfiguration">
    <!-- 服务名称 -->
    <property name="master">
        <bean class="org.springframework.data.redis.connection.RedisNode">
            <property name="name" value="mymaster"></property>
        </bean>
    </property>
    <!-- 哨兵服务IP和端口 -->
    <property name="sentinels">
        <set>
            <bean class="org.springframework.data.redis.connection.RedisNode">
                <constructor-arg name="host" value="192.168.11.128"></constructor-arg>
                <constructor-arg name="port" value="26379"></constructor-arg>
            </bean>
            <bean class="org.springframework.data.redis.connection.RedisNode">
                <constructor-arg name="host" value="192.168.11.129"></constructor-arg>
                <constructor-arg name="port" value="26379"></constructor-arg>
            </bean>
            <bean class="org.springframework.data.redis.connection.RedisNode">
                <constructor-arg name="host" value="192.168.11.130"></constructor-arg>
                <constructor-arg name="port" value="26379"></constructor-arg>
            </bean>
        </set>
    </property>
</bean>

Redis缓存穿透和雪崩【面试高频，工作常用】

服务器的高可用问题！

缓存穿透（查不到）

概念

缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中，于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。

这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

解决方案

  1. 布隆过滤器
    那这个布隆过滤器是如何解决redis中的缓存穿透呢？很简单首先也是对所有可能查询的参数以hash形式存储，当用户想要查询的时候，使用布隆过滤器发现不在集合中，就直接丢弃，不再对持久层查询。
    在这里插入图片描述
    2.、缓存空对象
    当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源；
    在这里插入图片描述

但是这种方法会存在两个问题：

（1）如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键；
（2）即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

缓存击穿（量太大）

概念

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案

（1）设置永不过期
（2）使用互斥锁(mutex key)，保证只有一个线程去访问数据库

缓存雪崩（缓存失效）

概念

缓存雪崩是指，缓存层出现了错误，不能正常工作了。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。
在这里插入图片描述

解决方案

（1）redis高可用

这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。

（2）限流降级

这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

（3）数据预热

数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

qianbw-Blog
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
redis学习笔记
05-04
### Redis 学习笔记知识点概览 #### 一、Redis 简介及特性 - **Redis**（Remote Dictionary Server）是一种开源的、基于内存的数据结构存储系统，它支持多种数据结构，如字符串（strings）、散列（hashes）、列表...
Redis学习笔记整理
11-14
二、 redis学习笔记之数据类型 3 三、 redis学习笔记之排序 11 四、 redis学习笔记之事务 16 五、 redis学习笔记之pipeline 20 六、 redis学习笔记之发布订阅 23 七、 redis学习笔记之持久化 28 八、 redis学习笔记...
Redis学习笔记
weixin_51053555的博客
07-14 776
Redis（ Remote Dictionary Server ），远程字典服务，支持网络，可基于内存亦可基于持久化的日志型、NoSQL开源内存数据库，提供多种语言的API。Redis 之所以称之为字典服务，是因为 Redis 是一个 key-value 存储系统。支持存储的 value 类型很多，包括 String(字符串)、List(链表)、Set(集合)、Zset(sorted set --有序集合)和 Hash（哈希类型）等。
redis 学习笔记
weixin_47291060的博客
05-11 1713
redis 6 学习笔记
尚硅谷 Redis 学习笔记
weixin_56042518的博客
01-14 1144
RDB 持久化 能够在指定时间间隔对数据进行快照存储AOF 持久化 记录每次服务器的写操作，当服务器重启时会重新执行 AOF 文件中的写命令来恢复原始数据AOF 命令 以 Redis 协议追加保存每次写操作到文件末尾Redis 还能对 AOF 文件进行后台重写，使得 AOF 文件的体积不至于过大如果你希望你的数据在服务器运行的时候存在，也可以不使用任何持久化方式 — 只做缓存同时开启两种持久化方式。
Redis 学习笔记
杨群的博客
09-03 713
Redis 是一个开源的、使用C语言编写的、支持网络交互的、可基于内存也可持久化的Key-Value数据库。
Redis学习笔记(超详细，看完必会)
qq_44860722的博客
07-15 2552
当系统的并发量比较高的时候，请求会直接落在Mysql上，在中间插入了缓存Redis，所有的请求先到Redis中查，如果查到了直接返回，请求就不会落在Mysql上，减轻了Mysql的压力。一个恶意的请求，假如有3000万个请求，要查询数据id=-1的，Redis缓存中查不到数据，然后去Mysql中查，Mysql中也查不到，那么3000万个请求全落在Mysql，永远起不来服务（恶意请求，永远查不到数据）。在Redis中查不到，就去查Mysql，查Mysql结果为空，也将他添加到Redis缓存中，添加空值。...
Redis学习笔记.zip
06-06
简单来说 redis 就是一个数据库，不过与传统数据库不同的是 redis 的数据是存在内存中的，所以存写速度非常快，因此 redis 被广泛应用于缓存方向。另外，redis 也经常用来做分布式锁。redis 提供了多种数据类型来...
本地访问不到公网redis的解决方法
qq_46896305的博客
08-13 431
连接redis失败
【redis】redis集群数据节点修改
zerotoall的博客
08-13 652
一、redis集群节点修改 　　 1.添加节点 　　 2.删除节点 #删除没有数据的主节点 [root@db01 ~]# redis-trib.rb del-node 172.16.1.52:6381 a298dbd22c10b8492d9ff4295504c50666f4fb2e >>> Removing node a298dbd22c10b8492d9ff4295504c50666f4fb2e from cluster 172.16.1.52:6381 >>> Sending CLUSTER
redis事件机制
笑笑布丁的博客
08-16 568
aeApiAddEvent、aeApiDelEvent：增加或删除一个监听对象。aeEventLoop：redis事件循环器，负责管理事件。aeFileEvent：存储一个文件描述符已注册的文件事件。aeApiPoll：阻塞进程，等待事件就绪或给定事件到期。aeApiCreate：初始化I/O复用机制上下文环境。aeTimeEvent：存储一个时间事件的信息。
Redis 为什么读写性能高？
heromps的博客
08-09 575
Redis 作为一种开源的、基于内存的数据结构存储系统，以其卓越的读写性能而闻名。它被广泛应用于缓存、消息队列、实时数据处理等场景。那么，是什么使得 Redis 拥有如此高的读写性能呢？本文将从以下几个方面进行探讨。
【Redis】Redis 初探：特性、应用场景与高并发架构演进之路
Hsusan的博客
08-13 930
在进⾏技术学习过程中，由于⼤部分读者没有经历过⼀些中⼤型系统的实际经验，导致⽆法从全局理解⼀些概念，所以本⽂以⼀个 “电⼦商务” 应⽤为例，介绍从⼀百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让⼤家对架构的演进有⼀个整体的认知，⽅便⼤家对后续知识做深⼊学习时有⼀定的整体视野。
redis I/O复用机制
最新发布
笑笑布丁的博客
08-16 720
epoll是linux提供的I/O复用API，是一种事件驱动的I/O模型，它可以用于高效地处理大量的并发连接。其中，'e’代表"event"（事件），意味着epoll可以监测并响应特定的事件，如文件描述符上的读写事件、错误事件等。用一个进程监听大量连接，当某个连接可读/可写的时候，系统就发送事件通知进程处理该连接的数据。串行化处理，就是要等，假如进行到accept操作，cpu需要等待客户端发送的数据到tcp接收缓冲区才能进行read操作，而在此期间cpu不能执行任何操作。
redisssion分布式锁
2201_75600005的博客
08-14 889
Redis主从的一致性问题：由于主从同步存在延迟，当线程在主节点获取锁后，从节点可能未同步锁信息。问题：利用WatchDog（看门狗）机制，获取锁成功时开启一个定时任务，在锁到期前自动续期，避免超时释放。第一个问题就是锁误删问题，目前释放锁的操作是基于DEL，但是在极端情况下会出现问题。lock.unlock() 虽然看起来简单，但是底层释放的是当前锁，不会释放其他的锁。锁的重入问题：同一个线程多次获取锁的场景，目前不支持，可能会导致死锁。，获取锁时重入次数+1，释放锁是重入次数-1，次数为0则锁删除。
用命令行敲命令的方式学会redis stream
servepeople的博客
08-13 831
通过这些命令，你已经了解了 Redis Stream 的基础操作，包括如何添加消息、读取消息、创建和管理消费者组、确认消息、处理挂起消息以及自动修剪 Stream 的长度。你可以根据需要组合这些命令来构建更加复杂的消息处理系统。a.你可以进一步学习如何处理消费者故障场景，例如使用XCLAIM重新分配未确认的消息。b.你可以尝试在真实的应用场景中使用 Redis Stream，比如构建一个简单的分布式日志系统。
【Redis】主从复制
qq_55119554的博客
08-14 640
Redis主从复制
尚硅谷redis学习笔记
09-08
通过这些引用内容，我们可以得出结论，尚硅谷的Redis学习笔记涵盖了关于Redis的配置和使用的内容，并提供了一些相关的命令和操作示例。<span class="em">1</span><span class="em">2</span><span class="em">3 #### ...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值