Redis进阶(持久化、复制、集群、多线程、缓存)

Redis进阶

  • 1.Redis持久化
    • 1.1 什么是Redis持久化？为什么需要持久化？
    • 1.2 Redis持久化方式——RDB(Redis DataBase)
      • 1.2.1 什么是RDB？
      • 1.2.2 备份文件位置
      • 1.2.3 触发RDB的方式
        • 1.2.3.1 自动触发
        • 1.2.3.2 手动触发
        • 1.2.3.3 其他触发方式
      • 1.2.4 RDB优缺点
    • 1.3 Redis持久化方式——AOF(Append Only File)
      • 1.3.1 什么是AOF
      • 1.3.2 备份的位置(Redis7)
      • 1.3.3 AOF工作原理
      • 1.3.4 AOF优缺点
    • 1.4 Redis持久化方式——RDB+AOF
  • 2. Redis主从复制(Replication)
    • 2.1 什么是主从复制？为什么要主从复制？
    • 2.2 主从复制配置
    • 2.3 主从复制过程
    • 2.4 主从复制的其他说明
  • 3. Redis哨兵(Sentinel)
    • 3.1 什么是哨兵
    • 3.2 哨兵集群配置和启动
    • 3.3 哨兵选举流程
    • 3.4 哨兵集群的优缺点
  • 4. 集群（Cluster）
    • 4.1 什么是集群
    • 4.2 集群算法——分片、槽位slot
    • 4.3 其他说明
  • 5.Redis单线程与多线程
    • 5.1 Redis是单线程还是多线程
    • 5.2 Redis为什么快
    • 5.3 主线程和IO多线程的协作流程
  • 6.布隆过滤器(BloomFilter)
    • 6.1 什么是布隆过滤器
    • 6.2 布隆过滤器原理
    • 6.3 优缺点和使用场景
  • 7. 缓存雪崩、穿透、击穿
    • 7.1 缓存雪崩
    • 7.2 缓存穿透
    • 7.3 缓存击穿

1.Redis持久化

1.1 什么是Redis持久化？为什么需要持久化？

什么是Redis持久化：将内存中的数据写到磁盘中。
为什么Redis需要持久化：Redis缓存是基于内存的，当服务器宕机或发生意外的时候，数据可能会丢失，所以需要将内存中的数据以一定的方式存储到磁盘中，方便数据恢复。

1.2 Redis持久化方式——RDB(Redis DataBase)

1.2.1 什么是RDB？

在一定的间隔时间内将内存中的数据写入到磁盘中，专业术语称之为snapshots(快照)。类似照相机每间隔一定时间拍摄一张照片。RDB是Redis默认的持久化方式。在redis.conf中可以找到关于间隔时间的说明：见1.2.3中自动触发部分。

1.2.2 备份文件位置

可以在Redis.conf文件中找到下列配置，dbfilename是备份文件名，dir是保存备份文件的文件夹。可以根据需求进行修改。
在这里插入图片描述
在这里插入图片描述

1.2.3 触发RDB的方式

1.2.3.1 自动触发

在Redis.conf中可以找到相关的配置说明。当达到条件的时候fork出子进程来进行备份，类似手动触发的bgsave。

# Unless specified otherwise, by default Redis will save the DB:
# After 3600 seconds (an hour) if at least 1 change was performed 
# After 300 seconds (5 minutes) if at least 100 changes were performed
# After 60 seconds if at least 10000 changes were performedsave 3600 1 300 100 60 10000
1.2.3.2 手动触发

例如某时某刻向Redis中写入了某数据，需要立即保存到磁盘，就可以手动触发保存命令。保存命令分为SAVE和BGSAVE，区别如下：

  • save ：同步生成快照，会造成Redis阻塞，一般不建议使用。
  • bgsave：异步生成快照。会fork出子进程来执行持久化，主进程可以继续执行任务。
redis> save
OKredis> bgsave
Background saving started
1.2.3.3 其他触发方式
  1. 执行shutdown 自动触发
  2. 主从复制时master 自定触发

1.2.4 RDB优缺点

  1. 优点：相比于AOF 更适合大规模数据更快的恢复。因为所有的数据都备份在磁盘，而AOF只是保存了执行的命令，恢复数据的时候要耗时加载。
  2. 缺点：(1)可能造成数据丢失：RDB是一定条件下才触发保存，当服务器意外宕机并且最近的一次数据并没有达到触发条件就会丢失最近的数据。 (2)fork子进程备份可能会耗时造成卡顿：虽然备份是fork子进程进行的，但是主进程fork子进程的时候会暂时阻塞，当要备份的数据很大的时候，fork可能会很耗时，造成卡顿。

1.3 Redis持久化方式——AOF(Append Only File)

1.3.1 什么是AOF

将服务器的的所有写操作记录进日志，数据恢复时根据所有写操作命令重建数据。AOF默认关闭，如果需要开启，可以在Redis.conf中开启：将appendonly 设置为yes。

1.3.2 备份的位置(Redis7)

备份的文件夹名称配置如下：
在这里插入图片描述
在这里插入图片描述
备份的文件名称配置如下：
在这里插入图片描述
即：有关AOF的所有备份文件都会保存在appendonlydir文件夹中，当配置保存文件的前缀是appendonly.aof时，会生成3种文件：base文件，increase文件，mainfest文件(跟踪管理这些文件。)

1.3.3 AOF工作原理

AOF工作流程如下：
在这里插入图片描述
缓冲区写回策略：AOF缓冲区命令写到磁盘的方式有3种

  • always：同步写回，有一个写一个。
  • everysec(默认)：每一秒将缓冲区写一次到磁盘。
  • no：操作系统自己调动。
    在这里插入图片描述
    AOF重写机制：随着AOF命令写的越来越多，导致AOF文件会变得越来越大，在一定条件下需要重写，简而言之对AOF文件瘦身。
    在这里插入图片描述
    当当前文件大于64mb，并且是上一次文件大小的1倍时触发重写。
    注意：比较大小是用百分比表示的。

1.3.4 AOF优缺点

  • 优点：相比于RDB，更不容易丢失数据，因为每个写操作都存入磁盘了。
  • 缺点：(1)相同数据集AOF文件大小大于RDB，恢复速度慢。(2)运行效率低于RDB(可能是同步策略导致效率低，因为每秒钟需要同步一次。)

1.4 Redis持久化方式——RDB+AOF

Redis支持RDB和AOF共同持久化，开启方式如下：

aof-use-rdb-preamble yes
  • 开启混合持化后：先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式。

注：当不开启AOF时，只产生RDB备份，开启AOF时会产生RDB和AOF文件，混合持化时，产生的是AOF文件，但是其内容是部分RDB+部分AOF文件。二者共存的时候只加载AOF，因为AOF文件保存的更完整。
在这里插入图片描述

  • RDB VS AOF
    在这里插入图片描述

2. Redis主从复制(Replication)

2.1 什么是主从复制？为什么要主从复制？

  • 主从复制：有多台服务器，分为master和slave服务器，一台master服务器可以挂载多台slave服务器，在master服务器中进行写操作，slave服务器进行读操作，减轻单台服务器带来的读写压力。当数据写入到master服务器中的时候，slave服务器同步master服务器数据的过程称之为主从复制。
  • 为什么要主从复制：(1)读写分离 (2)容灾恢复 (3)数据备份 (4)扩容支持高并发
    在这里插入图片描述

2.2 主从复制配置

info replication 查看节点之间的主从关系
replicaof masterip masterport 一般在配置文件中配置要连接的mater信息，也可以在命令行配置。配置文件中配置后重启后依然生效
slaveof masterip masterport 命令行配置要连接的master信息
slaveof no one 转为master不再挂载于任何master

假设3台主机， 1 master with 2 slaves。在master中写入了数据，在slaves中可以直接读写
在这里插入图片描述

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

2.3 主从复制过程

(1)首次连接全量复制

  • 当slave连接master的时候会发送sync命令。
  • master接收到sync后暂停当前所有的写操作，并将写操作缓存起来，并生成RDB快照。
  • master将RDB快照发送给slave，slave收到快照后，清空自己的数据库，将接受到的数据写入自己的内存。
  • master将刚才缓存的写操作发给slave，slave根据操作载入缓存。

(2)后续增量复制
master每执行一个写命令就会向slave服务器发送相同的写命令，slave服务器接收并执行收到的写命令。

(3)断点续传
master在内存缓冲区中给每个slave服务器都维护了一份同步备份日志backlog，同时master 和 slave都维护了一个复制偏移量（replication offset）和 master线程ID（master run id），每个slave服务器在跟master服务器进行同步时都会携带master run id 和 最后一次同步的复制偏移量offset，通过offset可以知道主从之间的数据不一致的情况。当连接断开时，slave服务器会重新连接上master服务器，然后请求继续复制。假如主从服务器的两个master run id相同，并且指定的偏移量offset在同步备份日志中还有效，复制就会从上次中断的点开始继续。

2.4 主从复制的其他说明

  • slave只能读而不能写。
  • master宕机后，slave只能等待而不能上位。
  • master 宕机后重启后仍然是master
  • 缺点：master宕机后没有slave上位，可能造成生产事故。

3. Redis哨兵(Sentinel)

3.1 什么是哨兵

俗称“无人值守运维”，当master宕机后，哨兵从slave中自动选举出新的master，避免master宕机后造成生产事故。
哨兵一般是集群，至少得3个哨兵，因为当master宕机后哨兵得投票选举出新的master。
哨兵一般只需要监视master，当master宕机后会选举出新master。当slave宕机后会通知哪个slave宕机了，需要手动恢复。
在这里插入图片描述

  • 哨兵的作用
    在这里插入图片描述

3.2 哨兵集群配置和启动

假设有服务器A B C ，可以在同一台服务器上或者不同的服务器上对sentinel.conf进行配置，
服务器可以是新的D服务器或者A B C服务器之一。
案例中设置3个哨兵，选择在3台服务器中分别配置sentinel.conf来监视master——192.168.178.128。（剩余的2台服务器ip分别是129、130）

  • 在sentinel.conf中进行相关配置
daemonize yes
protected-mode no#sentinel monitor <master-name> <ip> <redis-port> <quorum>
#master-name 自己起 
#quorm 集群中至少有quorm个哨兵认为master宕机了才客观认为master宕机了
sentinel monitor mymaster 192.168.178.128 6379 2#sentinel auth-pass <master-name> <password> 要监视的master 名称 和 密码
sentinel auth-pass mymaster 123456
  • 启动哨兵sentinel
redis-sentinel sentinel.conf --sentinel

因为哨兵配置在3台服务器中，所以需要再3台服务器中分别启动。

  • 模拟master宕机
    手动shutdown master服务器 之前 master和slaves info replication 如下：可以看到2台slave服务器都挂载在128的master服务器下，可以通过ip和replid看出来。
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    手动shutdown master服务器 之后，并在 稍后 重启之前的master，发现： 哨兵选举出新的master(129服务器)，并且原来的master重启后变成了slave。
    在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

3.3 哨兵选举流程

  • 先确定master是否客观下线
    主观下线：即单个sentinel主观认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。衡量指标是服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息。
#sentinel.conf
# default 30s
sentinel down-after-milliseconds <master-name> <milliseconds>

主观下线：单个哨兵得主观下线可能存在误判，例如只是网络不通畅就造成了ping不通。所以需要至少个哨兵认为master下线了才能认为master客观下线了。

#sentinel.conf
sentinel monitor <master-name> <ip> <redis-port> <quorum>

  • 各个哨兵选举领导者哨兵(Raft算法)
    在这里插入图片描述

  • 领导者哨兵进行故障转移
    通知调用的客户端master发生了变化
    通知其余的原slave节点，去复制Sentinel选举出来的新的master节点
    即使原来的master重启了，也沦为slave

3.4 哨兵集群的优缺点

  • 优点：对节点进行监控，来完成自动的故障发现与转移
  • 缺点：(1)在主从切换的瞬间存在访问瞬断的情况，等待时间比较长，客户端无法访问。(2)只有一个主节点对外提供服务，没法支持很高的并发。

4. 集群（Cluster）

4.1 什么是集群

简单来说，由多台服务器组成的集合。其中由多台master和多台slave，一台master可以挂载多台slave。客户端只需要连接其中一个节点服务器即可，实现了高并发和高可用。(相比于单纯的主从复制和哨兵模式，集群并发量更高，并且容灾性更好)
在这里插入图片描述

在这里插入图片描述

4.2 集群算法——分片、槽位slot

分片：即某台服务器
槽位：存在于某台服务器上的存储空间

集群算法：当要读取或者写入某个key的时候，将其经过CRC16(循环冗余校验码 16即校验结果占16bit)哈希函数的映射后，再与16384(2的14次方)取模后，得到0-16383之间的值。一般情况下，多个分片均分16384个槽位。则将key对应到某个分片下对应的槽位中。
在这里插入图片描述

4.3 其他说明

  • 哈希冲突：不难理解，只要key的确定的，得到的哈希映射结果是固定的，就会分配到固定的分片固定的槽位。不同的key也可能被分配到相同的分片下的相同槽位，这就属于哈希冲突，这是无法避免的，一种解决方案是：创建一个链表结构来存储多个键值对。
  • 集群方便扩容和缩容：当扩容的时候，分片增加，重新分配槽位。比如扩容前有3个分片，槽位分别是0-5460、5461-10922、10923-16383，扩容后有4个分片，槽位分别是0-4095、4096-8191、8192-12287、12288-16383。扩容后会根据新的槽位分配迁移部分数据。也就是1的部分迁移到2，2的部分迁移到3…3的部分迁移到4。这并不影响key的查找和写入，因为具体的key映射结果是固定的，区别只是存储在那个分片。
  • 集群有多个master，每个master有多个slave。当某个master宕机后，内部的故障转移机制会选举出新的master，并不会重新分配槽位。
  • 槽位数是16384的原因：(1)正常的心跳包会携带一个节点的完整配置，它会以幂等的方式更新旧的配置，这意味着心跳包会附带当前节点的负责的哈希槽的信息。假设哈希槽采用 16384 ,则占空间 2kb(16384/8)。假设哈希槽采用 65536， 则占空间 8k(65536/8)，这是令人难以接受的内存占用。(2)Redis Cluster 不太可能扩展到超过 1000 个主节点。
    也就是说，65536 个固然可以确保每个主节点有足够的哈希槽，但其占用的空间太大。而且，Redis Cluster 的主节点通常不会扩展太多，16384 个哈希槽完全足够用。
  • 集群在扩容和缩容期间如何保证提供服务：Redis Cluster 提供了重定向机制，两种不同的类型： (1)ASK 重定向 ：可以看做是临时重定向，后续查询仍然发送到旧节点。(2) MOVED 重定向 ：可以看做是永久重定向，后续查询发送到新节点。

5.Redis单线程与多线程

5.1 Redis是单线程还是多线程

这个问题不能简单的一概而论需要分Redis版本和操作类型来讨论：
Redis6之前：都是单线程，对数据的读写和IO多路复用都是单线程。
Redis6之后：引入了IO多线程(默认关闭)。之前是单线程IO多路复用同时处理多个客户端的请求。后来请过分析发现限制Redis性能的原因有：CPU、内存、IO。其中前两者一般管够，所以瓶颈就在IO，因此在Redis6引入了IO多线程，叠加多路复用，简直是快上加快。但是对数据的读写都是单线程，因此不会涉及到线程不安全的问题，也不会涉及到加锁的问题。

5.2 Redis为什么快

  • 基于内存操作：运算相比于在磁盘速度更快。
  • 高效数据结构：例如哈希结构对查找和插入很友好，时间复杂度只有O(1)。
  • 单线程：避免了多线程切换上下文和资源竞争激烈。
  • IO多路复用：多路复用能同时监听处理多个客户端的请求，尤其引入多线程IO后快上加快。

5.3 主线程和IO多线程的协作流程

在这里插入图片描述

6.布隆过滤器(BloomFilter)

6.1 什么是布隆过滤器

布隆过滤器由初始值为0的bit数组和多个哈希函数构成，一般用于查询某个key是否存在于集合中。

6.2 布隆过滤器原理

  • 添加key
    初始化bit数组为0，将要存储的key经过多个哈希函数映射，对数组长度取模得到数组下标，多个哈希函数得到多个函数下标，将这些下标置1即完成了添加。
    在这里插入图片描述

  • 查询key
    注意：查询的前提是数据已经存在了bit数组中了。
    将要查询的key经过多个哈希函数的映射取模后得到下标，当下标处有0的时候，肯定不存在。当下标全是1的时候，可能存在误判。
    **误判原因：哈希冲突。**不同的key经过哈希映射取模后可能得到的是同样的下标。例如bit数组中存储的是康师傅，但是要查询的是康帅傅，二者经过哈希函数映射和取模后下标一样，这时就出现了误判。

6.3 优缺点和使用场景

  • 优点：高效查询和插入。
  • 缺点：不能删除，因为哈希冲突会存在误判。
  • 应用场景：缓存穿透。垃圾邮件识别等

7. 缓存雪崩、穿透、击穿

7.1 缓存雪崩

  • 什么是缓存雪崩
    缓存雪崩一方面指服务器宕机，另一方面指在短时间内大量的缓存过期，大量请求短时间内落到数据库上，犹如雪崩。
  • 如何解决或避免
    (1)集群缓存：cluster或者主从复制+哨兵
    (2)限流：对客户端的访问限制
    (3)多级缓存：本地缓存+redis缓存
    (4)设置缓存永不过期

7.2 缓存穿透

  • 什么是缓存穿透
    redis缓存中和数据库中都没有数据，大量的请求不断的打到数据库上造成压力。
  • 如何解决或避免
    (1)缓存无效的key：如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间
    (2)布隆过滤器
    在这里插入图片描述

7.3 缓存击穿

  • 什么是缓存击穿
    大量热key过期，此时缓存并不存在但是数据库中存在，大量的请求会落到数据库上。
  • 如何解决或避免
    (1)对热key失效时间差异化。比如秒杀场景下设置数据过期时间晚于秒杀结束时间。
    (2)加锁策略：对多个用户请求同一个key，第一个用户请求后加锁，防止其他用户再请求。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/762021.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

【GPT概念04】仅解码器（only decode）模型的解码策略

【GPT概念04】仅解码器（only decode）模型的解码策略

一、说明 在我之前的博客中&#xff0c;我们研究了关于生成式预训练转换器的整个概述&#xff0c;以及一篇关于生成式预训练转换器&#xff08;GPT&#xff09;的博客——预训练、微调和不同的用例应用。现在让我们看看所有仅解码器模型的解码策略是什么。 二、解码策略 在之前…
阅读更多...
【Linux】多线程编程基础

【Linux】多线程编程基础

&#x1f4bb;文章目录 &#x1f4c4;前言&#x1f33a;linux线程基础线程的概念线程的优缺点线程与进程的区别 线程的创建 &#x1f33b;linux线程冲突概念互斥锁函数介绍加锁的缺点 &#x1f4d3;总结 &#x1f4c4;前言 无论你是否为程序员&#xff0c;相信多线程这个词汇应…
阅读更多...
量子计算机

量子计算机

近日&#xff0c;在AWS re&#xff1a;Invent全球大会上&#xff0c;亚马逊官宣AWS三箭齐发量子计算组合拳&#xff1a;Braket、AWS量子计算中心和量子解决方案实验室。 随着亚马逊的强势入局&#xff0c;加上此前鼓吹量子霸权的谷歌、起步最早的IBM、暗自发力的微软&#xff…
阅读更多...
react-jsx

react-jsx

react04 jsx语法 - 01 基础知识&#xff1a; jsx javascript xml(html) 把js和heml标签混合到一起 react视图编写及构建的简要流程 &#xff1a; 如何在react中使vs code支持格式化和快捷键提示&#xff1a;1, 2,修改文件后缀为jsx&#xff0c;因为webpack的打包规则中可以…
阅读更多...
如何通过idea搭建一个SpringBoot的Web项目（最基础版）

如何通过idea搭建一个SpringBoot的Web项目（最基础版）

通过idea搭建一个SpringBoot的Web项目 文章目录 通过idea搭建一个SpringBoot的Web项目一、打开idea&#xff0c;找到 create new project二、创建方式三、配置项目依赖四、新建项目模块五、总结 一、打开idea&#xff0c;找到 create new project 方式1 方式2 二、创建方式 新…
阅读更多...
马斯克开源Grok-1

马斯克开源Grok-1

Grok-1是由马斯克AI创企xAI发布的第一代大语言模型&#xff0c;它以其巨大的参数量——高达3140亿&#xff0c;引起了全球范围内的广泛关注。这一参数量远超其他知名模型&#xff0c;如OpenAI的GPT-3.5&#xff0c;后者仅有1750亿参数。在2024年3月17日&#xff0c;马斯克宣布将…
阅读更多...
【jvm】jinfo使用

【jvm】jinfo使用

jinfo介绍 jinfo 是一个命令行工具&#xff0c;用于查看和修改 Java 虚拟机&#xff08;JVM&#xff09;的配置参数。它通常用于调试和性能调优。 使用 jinfo 命令&#xff0c;你可以查看当前 JVM 的配置参数&#xff0c;包括堆大小、线程数、垃圾回收器类型等。此外&#xf…
阅读更多...
天翼云防火墙配置端口转换案例

天翼云防火墙配置端口转换案例

环境： 天翼云 云墙 问题描述： 天翼云防火墙配置端口转换案例 云主机192.168.10.9:2231 解决方案： 1.先登入云墙 可以从控制中心登入不用再输入密码 2.新建对象和端口 192.168.10.9:2231 3.到弹性IP这选个公网IP 记住弹性IP和后面虚拟IP 4.新建 目的NAT，按原有复制…
阅读更多...
【Arxml专题】-29-使用Cantools将CAN Matrix Arxml自动生成C语言代码

【Arxml专题】-29-使用Cantools将CAN Matrix Arxml自动生成C语言代码

目录 1 安装Python和Cantools 1.1 查看Python已安装的Package包 1.2 在Python中安装Cantools插件包 1.3 获取更多Cantools工具的更新动态 2 CAN Matrix Arxml自动生成C语言代码 2.1 批处理文件CAN_Matrix_Arxml_To_C.bat内容说明 2.2 CAN Matrix Arxml文件要求 2.3 如何…
阅读更多...
20232831 2023-2024-2 《网络攻防实践》第3次作业

20232831 2023-2024-2 《网络攻防实践》第3次作业

目录 20232831 2023-2024-2 《网络攻防实践》第3次作业1.实验内容2.实验过程&#xff08;1&#xff09;动手实践tcpdump&#xff08;2&#xff09;动手实践Wireshark&#xff08;3&#xff09;取证分析实践&#xff0c;解码网络扫描器&#xff08;listen.cap&#xff09; 3.学习…
阅读更多...
react拖拽react-beautiful-dnd，一维数组，二维数组

react拖拽react-beautiful-dnd，一维数组，二维数组

写在前边&#xff0c;二维数组可以拖拽&#xff0c;但是不可以编辑拖拽&#xff0c;如果想要实现编辑拖拽&#xff0c;还是需要转换成一维数组。原因是因为插件的官方规定&#xff0c;在拖拽过程中不可以编辑Droppable层的Props。 相关地址&#xff1a; 中文文档地址 react-be…
阅读更多...
VUE中添加视频播放功能

VUE中添加视频播放功能

转载https://www.cnblogs.com/gg-qq/p/10782848.html 常见错误 vue-video-player下载后‘vue-video-player/src/custom-theme.css‘找不到 解决方法 卸载原来的video-play版本 降低原来的版本 方法一 npm install vue-video-player5.0.1 --save 方法二 或者是在pack.json中直…
阅读更多...
OpenGL学习笔记【4】——创建窗口

OpenGL学习笔记【4】——创建窗口

一、前三章节的前情回顾 章节一&#xff1a;上下文(Context) OpenGL学习笔记【1】——简介-CSDN博客 章节一讲述了OpenGL在渲染的时候需要一个Context来记录了OpenGL渲染需要的所有信息和状态&#xff0c;可以把上下文理解成一个大的结构体&#xff0c;它里面记录了当前绘制使…
阅读更多...
JVM垃圾回收之内存分配，死亡对象判断方法

JVM垃圾回收之内存分配，死亡对象判断方法

Java 堆是垃圾收集器管理的主要区域&#xff0c;因此也被称作 GC 堆。 堆划分为新生代 老生代 永久代。 下图所示的 Eden 区、两个 Survivor 区 S0 和 S1 都属于新生代&#xff0c;中间一层属于老年代&#xff0c;最下面一层属于永久代。 内存分配原则 对象优先在Eden区域分…
阅读更多...
基于PID控制器的四旋翼无人机控制系统的simulink建模与仿真,并输出虚拟现实动画

基于PID控制器的四旋翼无人机控制系统的simulink建模与仿真,并输出虚拟现实动画

目录 1.课题概述 2.系统仿真结果 3.核心程序与模型 4.系统原理简介 4.1四旋翼无人机的动力学模型 4.2 PID控制器设计 4.3 姿态控制实现 4.4 VR虚拟现实动画展示 5.完整工程文件 1.课题概述 基于PID控制器的四旋翼无人机控制系统的simulink建模与仿真,并输出vr虚拟现实…
阅读更多...
Chronicles 是什么数据库

Chronicles 是什么数据库

可以理解的是 Chronicles 是 EPIC 公司根据 IRIS 进行魔改后的一个 DBMS。 简单的来说 Chronicles 就是一个数据库管理系统&#xff0c;但这个数据库管理系统不是我们常说的关系数据库的管理系统。 数据库结构 只要对数据库有所了解的都知道数据库通常就是 2 个部分&#xf…
阅读更多...
10W字解析 SpringBoot技术内幕文档，实战+原理齐飞，spring事务实现原理面试

10W字解析 SpringBoot技术内幕文档，实战+原理齐飞，spring事务实现原理面试

第3章&#xff0c;Spring Boot构造流程源码分析&#xff0c;Spring Boot的启动非常简单&#xff0c;只需执行一个简单的main方法即可&#xff0c;但在整个main方法中&#xff0c;Spring Boot都做了些什么呢&#xff1f;本章会为大家详细讲解Spring Boot启动过程中所涉及的源代码…
阅读更多...
会声会影2023新版本特点以及会声会影2023序列号注册机keygen下载

会声会影2023新版本特点以及会声会影2023序列号注册机keygen下载

会声会影简介 虽然现在已经是2024年了&#xff0c;但是大家对会声会影2024的热爱一直不减&#xff0c;很多人后台问我&#xff0c;有没有会声会影2023序列号和注册机&#xff0c;这不&#xff0c;今天这篇文章它来了。 会声会影2023新版特性 1.全新的进入/中场/退出标题动态功…
阅读更多...
【Godot 4.2】常见几何图形、网格、刻度线点求取函数及原理总结

【Godot 4.2】常见几何图形、网格、刻度线点求取函数及原理总结

概述 本篇为ShapePoints静态函数库的补充和辅助文档。ShapePoints函数库是一个用于生成常见几何图形顶点数据&#xff08;PackedVector2Array&#xff09;的静态函数库。生成的数据可用于_draw和Line2D、Polygon2D等进行绘制和显示。因为不断地持续扩展&#xff0c;ShapePoint…
阅读更多...
基于Springboot的在线投稿系统+数据库+免费远程调试

基于Springboot的在线投稿系统+数据库+免费远程调试

项目介绍: Javaee项目&#xff0c;springboot项目。采用M&#xff08;model&#xff09;V&#xff08;view&#xff09;C&#xff08;controller&#xff09;三层体系结构&#xff0c;通过Spring SpringBoot Mybatis VueMavenLayui来实现。MySQL数据库作为系统数据储存平台&a…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023