Redis 持久化 总结

在这里插入图片描述

前言


 相关系列

  • 《Redis & 目录》(持续更新)
  • 《Redis & 持久化 & 源码》(学习过程/多有漏误/仅作参考/不再更新)
  • 《Redis & 持久化 & 总结》(学习总结/最新最准/持续更新)
  • 《Redis & 持久化 & 问题》(学习解答/持续更新)
     

 参考文献

  • 《Redis的持久化详解》
     
     

概述


    Redis持久化机制用于避免/减少内存数据的丢失。Redis是完全基于内存实现的非关系型数据库,其数据会被统一保存至内存中。因此一旦其遭遇了宕机/停电/关机/重启等情况的发生,则其内存数据就将全部丢失。这对某些需求/开发者来说是无法被接受的,因为其可能会在Redis中预存某些确保系统正常运行的重要数据。内存数据的丢失不但会导致系统的全量崩盘,并且也会提升修复的难度,因为数据的预存往往并不便利。对此Redis提供了持久化机制用于在遭遇上述情况时避免/减少内存数据的丢失,该机制的本质是将内存数据以某些特定的规则写入磁盘中。由于磁盘数据理论上会被永久保存,因此Redis就可以在启动时加载这些数据至内存以恢复/还原异常情况前的内存数据。

    Redis存在RDB/AOF两种持久化机制。RDB/AOF分别基于快照/日志的思想实现,这其中RDB的性能更佳,但可能会丢失较多的数据;而AOF虽然性能较差,但数据完整性却可以达到基本不丢失的程度…这些知识点都会在下文详述。
 
 

RDB @ Redis Database @ Redis数据库


 快照/COW/恢复

    RDB会在磁盘中生成/保存Redis数据快照。所谓数据快照本质是Redis在某个时间点的数据备份,例如如果我们将Redis在T1时间点的数据以某种形式完整的备份下来,那么该数据备份就是Redis在T1时间点的数据快照,同理我们也可以得到Redis在T2/T3乃至任意时间点上的数据快照。而通过在磁盘中生成/保存快照文件的方式,Redis便可以在内存数据在因为宕机/停电/关机/重启等原因而丢失时将之恢复至最新数据快照的程度。

    RDB支持“自动/手动”执行。关于RDB自动/手动执行的必要指令/配置具体如下:

  • SAVE:执行阻塞式RDB,不推荐使用。
  • BGSAVE:执行非阻塞式RDB,推荐使用。
  • FLUSHALL:清空所有Redis数据,并会生成空dump.rdb文件,于持久化而言没有意义。
  • LASTSAVE:获取最后一次RDB的时间。

名称:save
作用:设置RDB是否开启,并同时设置自动触发规则。
默认:无配置
示例:
---- 无配置 & 关闭RDB;
---- save “” & 开启RDB,但不支持自动触发,只能通过指令手动触发;
---- save 3600 1 & 开启RDB,且30分钟内写入1次时触发;
---- save 300 100 & 开启RDB,且5分钟内写入100次时触发;
---- save 60 10000 & 开启RDB,且1分钟内写入10000次时触发。

在这里插入图片描述

名称:dbfilename
作用:设置RDB快照文件名称。
默认:dump.rdb

在这里插入图片描述

名称:dir
作用:设置Redis的工作目录,其同时也是RDB快照文件的生成地址所在。
默认:./,即Redis根目录

在这里插入图片描述

    RDB由子“进程”异步执行。对于“单进程单线程”的Redis而言,RDB会造成两大负面影响:一是磁盘I/O会大幅拉低其整体的读/写性能,因为磁盘I/O的速度必然远低于内存I/O;二是其执行必须阻塞内存读/写的执行,因为内存数据需要在持久化期间固定不变以保证数据快照的一致性,因此Redis不可以在中途接收/执行由客户端发送而来的请求,即不可以暂时停止快照生成去执行事务/指令。很显然这两大负面影响都会对Redis的性能造成严重负担,因此该持久化机制实际上被设计交由Redis主进程fork出来的子进程负责异步执行。该设计不但可以将磁盘I/O与内存I/O分离以保证整体/内存的读/写性能,更可以借助进程的底层机制来快速避免RDB执行对内存读/写所造成的阻塞,这也正是Redis会fork进程而不是线程的原因。而当RDB快照文件生成后,子进程会原子地重命名该RDB快照文件并删除可能存在的旧RDB快照文件,从而完成新RDB快照文件对旧RDB快照文件的替换。

    RDB通过进程资源的独立性来保证数据快照的一致性并避免内/存读写的阻塞。对于本该资源独立的进程来说,如果进程A需要访问进程B的资源,那么操作系统就应该提供相应的机制来保证进程B资源的独立性不被破坏。例如进程B可以直接拒绝访问,这样其资源就必然是独立的;又例如进程B可以将相应资源全量拷贝至进程A中,这样进程A本质上就是在访问私有资源,那么进程B的资源就必然也是独立的。相关机制在各类操作系统中数量繁多,但其中最著名的必然当属Linux系统提供的COW @ 写时拷贝,因为其在确保资源独立性的同时还实现了内存开销的最小化。

    COW允许多进程共享资源。所谓共享资源是指进程A被允许直接访问进程B的资源,目的是避免进程B资源的全量拷贝以实现内存开销的最小化。我们可以发现该行为似乎并未保证资源的独立性,这是因为COW认为资源独立性的核心在于确保资源的安全性,因此只要保证访问安全,那么将私有资源适当外放也并无不可。此外该共享虽然直观表现为进程A在非法访问进程B的资源,但本质却是进程A对私有资源的合法访问。因为资源共享时其本质便已不再是进程B的私有资源了,而是进程B资源与进程A资源拷贝的“暂时合并”。由于这两份资源初始时必然完全相同,故而该行为可显著减少内存开销,也因此COW本质上依然完整保证了进程资源的独立性。

    COW不允许访问进程写入资源。无论资源的本质为何,其在内存上都已直接对外暴露。因此为了保证资源访问的安全性COW规定只有资源直接所在/所属的进程才允许写入资源,即只有进程B可以写入资源,而访问进程/进程A则只允许读取资源。此外由于资源共享时对所有进程都持有独立性,因此在进程B写入资源期间进程A的读取要保证不变,即不会读取到进程B新写入的内容,否则就会被破坏进程A资源的独立性。因此COW会通过写时拷贝来实现这一点,这是该机制名称的具体由来,这里我们就使用Redis内存数据的RDB持久化过程来举例讲解这一点。

    在执行RDB的子进程被主进程fork出来的初始阶段,两者会共享主进程中的内存数据。此时子进程会遍历内存数据并在磁盘中生成RDB快照文件,而主进程则会继续进行本职的指令执行工作,从而避免RDB执行对内存读/写造成的阻塞。而当主进程试图写入内存数据时,由于必须保证子进程的资源独立性不被破坏,因此主进程不会直接对内存数据进行写入,而是会先“增量”拷贝所要写入的部分内存数据,随后再于拷贝中完成写入并用于后续读取,直至子进程完成RDB后再原子性覆盖原内存数据…具体图示如下:

在这里插入图片描述

    增量拷贝同样是COW实现内存开销最小化的核心手段,因为绝大多数内存数据在RDB执行期间都不会被写入,因此这种拷贝方式往往只需耗费极少量的内存资源,并且上限也不会大于整体内存数据的大小。此外子进程完成RDB后会通知主进程,目的是令其执行记录时间/覆盖数据/释放资源等后续操作。

    Redis会在启动时异步加载RDB快照文件以恢复内存数据。当Redis启动时,其会在工作目录(即“redis.conf”文件中“dir”配置项所指定的目录,其同时也是RDB快照文件的生成目录,默认为Redis的根目录)存在RDB快照文件的情况下fork子进程来执行加载以恢复内存数据,因此开发者需确保工作地址/RDB快照文件的正确性/存在来保证内存数据的正常恢复。Redis异步加载RDB快照文件是出于性能方面的考量,因为这有助于提升Redis初始化的整体效率。可虽说是异步加载,但该行为实际上依然可能导致主进程陷入阻塞。因为主进程虽然也会在此期间并发执行初始化操作,但其对内存数据的读/写却需要在原数据完全恢复后再执行才能保证安全性,因此主进程依然可能进入阻塞状态以确保子进程完成对RDB快照文件的整体加载。
 

 优缺

  • 适合大规模数据恢复;
  • RDB快照文件相对较小,比较节省磁盘空间;
  • RDB快照文件基于二进制存储的,数据恢复速度较快。
        
  • 主进程会为fork出来的子进程拷贝内存数据,这部分内存开销会因为操作系统的差异而动态变化,但最大可达2倍膨胀,需要注意;
  • 虽然Redis在fork的时候使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能;
  • 如果Redis出现宕机/停电/关机/重启等情况,那么最后一次RDB后写入的新数据将会丢失/无法恢复。
     
     

AOF @ Append Only File @ 只追加文件


 日志/恢复

    AOF会在磁盘中记录Redis写指令。在AOF开启的情况下,Redis会在“写指令”正式执行后将之写入日志文件。而由于日志文件顺序记录了Redis自启动以来执行的所有写指令,因此Redis便可以在内存数据在因为宕机/停电/关机/重启等原因而丢失时通过“重放”日志的方式将之恢复…开启AOF的基础配置如下:

名称:appendonly
作用:设置AOF是否开启。
默认:no

在这里插入图片描述

名称:appendfilename
作用:设置AOF日志文件名。
默认:appendonly.aof

在这里插入图片描述

名称:dir
作用:设置Redis的工作目录,其同时也是AOF日志文件的生成地址所在。
默认:./,即Redis根目录

在这里插入图片描述

    指令的写入分为缓冲/日志两步。指令写入日志属于标准的磁盘I/O,出于性能上的考量,Redis不可能允许主进程执行该类操作来拖慢高效的内存I/O,因此指令的写入实际上分为缓冲/日志两个步骤。这其中主进程负责将指令同步写入aof_buf @ AOF缓冲区中,而缓冲指令写入日志则由操作系统异步负责。如果要问主进程是否在缓冲指令写入日志的过程中有所参与,那么只能说操作系统对缓冲指令的正式写入是由主进程触发的,即调用fsync函数以告知操作系统将缓冲指令写入至磁盘日志的行为会由主进程负责。

    AOF存在always/everysec/no三种写回机制。所谓写回机制是指控制缓冲指令何时写入日志的机制,我们可以从上文内容中料想到的是:既然指令会先写入缓存后再写入日志,那么如果Redis突然宕机,则缓冲指令就会因未能及时写入日志而丢失。事实上也确实如此,因此Redis引入了写回机制的概念并提供了三种具体实现来处理该项问题,其目的是为了令开发者可以在安全/性能之间实现自我选择…具体配置/机制如下:

名称:appendfsync
作用:设置AOF的写回机制。
默认:everysec

在这里插入图片描述

  • aleays:主进程每向缓存中写入一个指令便调用一次FSYNC函数。该写回机制理论上(磁盘实际的写入效率是不可控的)可保证最多只丢失一个指令,因此其安全性是最高的。但由于该写回机制下主进程会与操作系统进行频繁交互,因此虽然其并不参与具体的文件写入,但其性能也是最差的,故而只推荐在安全性要求极高的业务中使用。
  • everysec:主进程每秒调用一次FSYNC函数。该写回机制理论上可保证最多只丢失一秒内的指令,因此其安全/性能都较为可观,是最为推荐/常用的AOF写回机制;
  • no:主进程不调用FSYNC函数,而是由操作系统自身决定何时将缓冲指令写入日志。该写回机制的性能虽然是最高的,但基本没有安全性可言,因此也是最不推荐使用的AOF写回机制。

    Redis会在启动时自动读取AOF日志文件以恢复内存数据。虽然持久化方式并不相同,但AOF的数据恢复方式与RDB是相同的。当工作目录(即“redis.conf”文件中“dir”配置项所指定的目录,其同时也是AOF日志文件的生成目录,默认为Redis的根目录)中存在AOF日志文件时,Redis会在启动时自动读取并恢复内存数据,因此开发者需确保工作地址/AOF日志文件的正确性/存在来保证内存数据的正常恢复。
 

 重写

    AOF支持重写日志文件。由于AOF日志文件会记录Redis执行的所有写指令,因此其必然会随着程序的不断运行而愈加庞大。庞大的AOF日志文件一方面会占用大量的磁盘空间;另一方面还会增加Redis内存数据的恢复时长。因此出于开销/性能的两方面考量Redis支持对AOF日志文件进行“瘦身”,即通过重写指令的方式来达到减少指令数量/日志大小的效果…AOF重写的手动执行指令/自动执行配置如下:

  • BGREWRITEAOF:重写AOF日志文件。

名称:auto-aof-rewrite-min-size
作用:设置自动触发AOF重写的最小日志文件大小。{auto-aof-rewrite-percentage}配置项会与{auto-aof-rewrite-min-size}配置项相互影响,即如果两者都存在,那么只有同时满足两个配置时才能自动触发AOF重写。例如某初始AOF日志文件的大小为64mb,则当其满足{auto-aof-rewrite-min-size}配置项而自动触发AOF重写后,如果新AOF日志文件为54mb,那么再次自动触发AOF重写的日志文件大小即为108mb,因为当AOF日志文件大小再次到达64mb时其不满足增长率 >= 100%的要求。
默认:64mb

在这里插入图片描述

名称:auto-aof-rewrite-percentage
作用:设置自动触发AOF重写的日志文件大小增长率,即AOF日志文件大小增长率大于该值时将自动触发AOF重写。{auto-aof-rewrite-percentage}配置项会与{auto-aof-rewrite-min-size}配置项相互影响,即如果两者都存在,那么只有同时满足两个配置时才能自动触发AOF重写。例如某初始AOF日志文件的大小为64mb,则当其满足{auto-aof-rewrite-min-size}配置项而自动触发AOF重写后,如果新AOF日志文件为54mb,那么再次自动触发AOF重写的日志文件大小即为108mb,因为当AOF日志文件大小再次到达64mb时其不满足增长率 >= 100%的要求。
默认:100(mb)

在这里插入图片描述

    AOF重写由子进程异步执行。AOF重写指令时需要访问内存数据,因此主进程会fork子进程来执行AOF重写,目的是避免内存读/写的阻塞,并借助进程资源的独立性来保证内存数据在指令重写时的保持不变。子进程遍历内存数据的目的是为生成相应的指令,并将这些指令存入新AOF日志文件中。这里可能存在的疑惑是:既然指令重写的目的是为了对AOF日志文件进行瘦身,那么子进程不是应该读取AOF日志文件中的指令再执行合并/删除等手段吗?怎么会去遍历内存数据呢?事实上该方案理论上应该也是可行的,但现实情况是AOF日志文件往往过于臃肿且存在大量类似于“前指令值被后指令值覆盖/数据过期”的无效指令。同时又因为磁盘I/O的速度还远低于内存I/O,故而其工作量/重写效率都远大/低于直接从内存中读取最新数据,也因此子进程并不基于AOF日志文件来重写指令。

在这里插入图片描述

    主进程会将指令同步写入aof_rewrite_buf @ AOF重写缓冲区。AOF重写缓冲区类似于AOF缓冲区,用于在子进程重写指令时暂存最新请求的写指令,也因此在此期间主进程会将写指令写入上述两个缓冲区中。

在这里插入图片描述

    主进程负责将重写缓冲指令写入新AOF日志文件,并令新AOF日志文件取代旧AOF日志文件。当子进程完成对指令的重写后,其会向主进程发送信号并消亡。而得知指令重写已结束的主进程会先将重写缓冲指令全部写入新AOF日志文件中以确保指令完整性,随后再原子地重命名新AOF日志文件并删除可能存在的旧AOF日志文件,从而完成新AOF日志文件对旧AOF日志文件的取代以达成“瘦身”效果。这里可能产生的疑惑是:“重写缓存指令写入新AOF日志文件/新AOF日志文件取代旧AOF日志文件”属于标准的磁盘I/O操作,那这种操作怎么会被交由主进程来执行呢?实际上这是为了功能实现所做出的必要取舍,因为如果在上述磁盘I/O操作执行时没有阻塞内存的读/写,即磁盘I/O操作继续由子进程执行,那么AOF重写缓冲区的持续/并发写入将导致重写缓冲指令难以/无法被全量写入新AOF日志文件中,并且新AOF日志文件也难以/无法安全的替换旧AOF日志文件。因此将上述磁盘I/O操作交由主进程执行实际上也是为了快速/简单实现所做出的选择,因为主进程执行可以自然达到阻塞内存读/写的效果而无需任何附加行为。并且由于AOF重写本身也不是高频操作,因此主进程少许的几次磁盘I/O并不会对整体性能造成太大影响。
 

 优缺

  • 丢失的指令较少,因此数据恢复率更高;
  • AOF日志文件的可读性更强,对自定义操作的支持度更高。
     
  • AOF日志文件占用的磁盘空间更多;
  • 内存数据恢复速度相对较慢;
  • 在写回机制为Always的情况下,对整体性能会造成严重影响。
     
     

损坏


    RDB快照/AOF日志文件可能损坏。无论是RDB还是AOF,其生成磁盘文件都存在损坏可能,而导致其损坏的具体原因包含但不限于以下几种:

  • 硬件故障:磁盘损坏等硬件问题可能导致RDB快照/AOF日志文件在生成/写入过程中发生错误并损坏;
  • 系统异常:宕机/断电等系统问题可能导致RDB快照/AOF日志文件在生成/写入过程中发生错误并损坏;
  • 软件BUG:Redis软件及其依赖的库可能存在BUG,从而导致RDB快照/AOF日志文件在生成/写入过程中发生错误并损坏;
  • 人为操作:不恰当的人为操作可能导致RDB快照/AOF日志文件被直接损坏,例如直接/错误的编辑RDB快照/AOF日志文件内容。

    AOF日志文件的损坏概率大于RDB快照文件。虽说都是磁盘I/O操作,但AOF日志文件的损坏概率实际上远高于RDB快照文件。这是因为RDB快照文件会在一次生成后固定不变,而AOF日志文件却会在后续不断地追加指令,因此其磁盘I/O操作的总量/频率远高于RDB快照文件,故而其在过程中遭遇上述问题并损坏的概率自然也远高于RDB快照文件。

  • REDIS-CHECK-RDB :检查RDB快照文件是否损坏,是则报告错误,并“可能”提供具体的错误信息。
        ------------------------- 入参 -------------------------
        rdb-file-path @ RDB文件路径:RDB快照文件地址。
  • REDIS-CHECK-AOF [–fix]:检查AOF日志文件是否损坏,是则报告错误,并“可能”提供具体的错误信息。该指令执行时建议关闭Redis,避免日志文件的持续追加对检查的结果造成影响。
        ------------------------- 入参 -------------------------
        aof-file-path @ AOF文件路径:AOF日志文件地址。
        ------------------------- 选项 -------------------------
        –fix:设置此次检查会尝试修复AOF日志文件文件,并返回修复结果。成功修复的日志文件可能(大概率)会丢失指令,因此在修复前应先备份。

    Redis支持检查RDB快照/AOF日志文件是否损坏,并可以尝试修复AOF日志文件。Redis提供了相关指令用于检查/修复RDB快照/AOF日志文件,具体内容可在上文各自的指令中查询。AOF日志文件之所以支持修复是因为其损坏往往源于最后指令的写入中断,因此Redis只需将AOF日志文件从最后完整指令处截断便可以还原内容的合法性,但同理该行为也会加剧AOF日志文件的完整性丢失,即从原本的指令残缺加剧为指令丢失,因此在正式修复AOF日志文件前最好先进行备份。此外Redis还支持对AOF日志文件的其它损坏进行修复,例如某些语法/格式错误等,前提是其能够推演出原本的正确内容。这当然不是必定能做到的,也因此AOF日志文件的修复并不保证成功。那为什么Redis不支持对RDB快照文件进行修复呢?这是因为其更倾向于直接生成新的RDB快照文件,这具体有以下两点原因:

  • 实现难度高:RDB快照文件有特定的存储格式,并且会被压缩以节省空间,而在这种情况下修复的难度极高并很容易出现新的错误;
  • 数据不完整:RDB快照文件要求有绝对的一致性/完整性,而损坏会破坏这些特性,并且修复还会加剧这种情况。

    为了尽可能避免RDB快照/AOF日志文件损坏及损坏后数据难以/无法恢复的情况发生,建议选择性的对Redis执行以下行为:

  • 写回机制:配置合适的写回机制以降低AOF日志文件追加写入的频率,从而同步降低损坏的概率;
  • 定期备份:定期备份对AOF日志文件进行备份,从而在AOF日志文件损坏时使用最新备份还原内存数据,即使这会导致最新数据的丢失/错误;
  • 混合搭配:配合RDB一同使用,从而在AOF日志文件损坏时使用RDB快照文件还原内存数据,即使这会导致最新数据的丢失/错误;
  • 实时监控:实时监控RDB快照/AOF日志文件的正确性并及时处理损坏问题。
     
     

使用/建议


 混合持久化

    混合持久化会令RDB/AOF协调执行。除了做备份/数据完整性要求不高的情况外,我们通常不会单独使用RDB来执行持久化,因为这样会导致最新数据丢失/错误。而虽说AOF的数据完整度更高,但相对而言其缺点也很明显,即数据的恢复速度要远低于RDB,故而当AOF日志文件较大时其文件加载/数据恢复的时间会相当长,也因此Redis在4.0版本中针对该情况推出了新的持久化方案 —— 混合持久化。该方案结合了RDB/AOF的优点,使得持久化可以同时达到数据完整度高/数据恢复快的效果。

    混合持久化在5.0版本后默认开启。设置混合持久化的配置如下:

名称:aof-use-rdb-preamble
作用:设置是否开启混合持久化。
默认:yes

在这里插入图片描述

    混合持久化的实现核心在于将AOF重写的指令生成替换为快照生成。在上文中我们说过:Redis会在AOF日志文件同时满足指定大小/比率的情况下对之进行AOF重写以实现瘦身。而在此期间主进程会fork子进程去遍历内存数据,目的是基于最新内存数据来生成指令并写入新AOF日志文件。但在开启混合持久化后,该行为便会由指令生成变更为快照生成,即子进程会遍历最新内存数据来生成快照,从而使得新AOF日志文件的内容从原本的“全指令”变更为“前快照&后指令”的状态…具体流程如下:

在这里插入图片描述

    快照加速了AOF日志文件对内存数据的还原/恢复。由于二进制快照替换了本该数量庞大的旧内存数据指令,因此当Redis基于该AOF日志文件对内存数据进行恢复时其速度将获得大幅提升。而又因为新指令会持续向该AOF日志文件中增量追加,从而就使得持久化同时达到了数据完整度高/数据恢复快的效果。但话虽如此,混合持久化也同样具有两面性,其带来的负面影响包含但不限于以下几点:

  • AOF日志文件添加了二进制快照数据后其可读性/可操作性会变差;
  • AOF日志文件添加了二进制快照数据后其兼容性会变差,因为其无法用于4.0版本之前的Redis。
     

 建议

  • 如果希望内存数据会随着Redis的关闭而消失,那么不推荐使用任何持久化机制,而RDB/AOF默认也都是关闭的;
  • 在对内存数据完整性要求不高的情况下,推荐只开启RDB,这样对性能更加友好,因为AOF对磁盘的压力较大且重写是会阻塞主进程;
  • 即使在对内存数据完整度要求较高的情况也不推荐只开启AOF,因为其日志文件的损坏率很高,建议搭配RDB一同使用,以便在AOF日志文件损坏时使用RDB快照文件来保底还原内存数据;
  • 建议将触发AOF重写的最小文件大小由默认的64MB调整至5G(可以根据磁盘大小动态选择)以上,从而降低AOF重写的执行频率以提升性能;
  • Redis集群部署时,建议将主节点的RDB/AOF同时开启,以便在确保完整性的同时保障安全性;
  • Redis集群部署时,不建议为从节点开启持久化机制。但如果有防止主节点不可用的需要,那建议只开启RDB,并且自动触发频率设置为15分钟即可;
  • 在版本 > = 4.0的情况下,所有需要同时开启RDB/AOF的场景都建议开启混合持久化。

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

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

相关文章

python进阶集锦

一、迭代器和生成器 区别 关于迭代器和生成器 迭代器与生成器的区别 迭代器(Iterator)和生成器(Generator)是Python中处理序列数据的两种不同概念。迭代器是遵循迭代协议的对象,而生成器是一种特殊类型的迭代器&am…

Vue学习笔记(八)

透传attribute "透传attribute"指的是传递给一个组件,却没有被改组件声明为props或emits的attribute或者v-on事件监听器。最常见的例子就是class、style和id。 当一个组件以单个元素为根作渲染时,透传的attribute会自动被添加到根元素上。 …

4个提取音频办法,轻松实现视频转音频!

在信息爆炸的时代,视频内容以其直观、生动的特点占据了互联网的大半江山。然而,在某些场景下,我们可能更倾向于只听取音频部分,无论是驾驶途中听讲座、跑步时享受音乐视频中的纯音乐的场景,还是为了节省流量和存储空间…

C++ 类与对象入门:基础知识与定义

引言: 本来打算用一篇介绍清楚C中的类与对象,再三考虑后觉得不妥:第一,知识点实在太多;第二,对于从刚学完C并打算过渡到C的朋友来说,学的太深较有难度… 总而言之,我打算用三到四篇文…

一篇文章总结 SQL 基础知识点

1. 官方文档 MySQL:https://dev.mysql.com/doc/refman/8.4/en/ SQL Server:What is SQL Server? - SQL Server | Microsoft Learn Oracle:https://docs.oracle.com/en/database/oracle/oracle-database/23/lnpls/loe.html 2. 术语 SQL S…

电脑程序变化监控怎么设置?实时监控电脑程序变化的五大方法,手把手教会你!

​在现代办公和信息安全领域,实时监控电脑程序变化是一项至关重要的任务。 无论是企业内网安全、员工行为审计,还是个人电脑的隐私保护,了解并设置有效的监控方法都是必不可少的。 本文将详细介绍五种电脑程序变化监控的方法,帮助…

️ Vulnhuntr:利用大型语言模型(LLM)进行零样本漏洞发现的工具

在网络安全领域,漏洞的发现和修复是保护系统安全的关键。今天,我要向大家介绍一款创新的工具——Vulnhuntr,这是一款利用大型语言模型(LLM)进行零样本漏洞发现的工具,能够自动分析代码,检测远程…

SAP-ABAP开发学习-FUNCTION ALV

ALV概览 ALV全称SAP List View,是SAP提供的一个强大的数据报表显示工具。ALV实质上是一个屏幕控件对象,它通过程序传递数据内表的方式来显示数据。 实现方式:调用标准函数;优化接口:用户可以实现对字段的排序、筛选及统计等功能。…

51c嵌入式~IO合集1

我自己的原文哦~ https://blog.51cto.com/whaosoft/12383193 一、单片机通信数据接收解析方法 前阵子一朋友使用单片机与某外设进行通信时,外设返回的是一堆格式如下的数据: AA AA 04 80 02 00 02 7B AA AA 04 80 02 00 08 75 AA AA 04 80 02 00 9B E2…

layaair给图片精灵绘制形状并添加点击事件注意点击的区域不是方块

默认的图片添加进来都是方块,哪怕是圆形的图片,点击也是方块区域如下图,这个圆的上下左右方向角的位置都可点击。 利用sprite的Graphics属性则可以编制线条,圆形等形状。如下图 但是点击的区域还是默认根据sprite的高宽来设定的。…

vite 创建了一个项目后,如何实现工程化

当我们使用 vite 创建了一个项目后&#xff0c;要开发自己的东西。首先要做的就是先将开发文件变成自己的样子。 这是一个刚刚创建项目的文件夹及展示 开始整改文件夹 修改文件 main.ts不需要修改App.vue删除无用的内容 <template><div>app组件</div> &l…

推荐一款好用的redis管理工具TinyRDM

简述 对于经常要操作redis的人员来说&#xff0c;一款好用开源的redis可视化管理工具可以事半功倍&#xff0c;今天要介绍的TinyRDM就是这样的工具&#xff0c;支持多端&#xff08;MAC/Window/Linux&#xff09;&#xff0c;并且是开源的。 github地址&#xff1a;https://git…

CSPM(项目管理专业人员评价)证书还不如PMP?垃圾证书……

一、什么是CSPM CSPM&#xff08;China Standards Project Management&#xff09;是指依据中国标准开展的项目管理专业人员能力评价。它是由中国标准化协会&#xff08;全国项目管理标准化技术委员会秘书处&#xff09;设立&#xff0c;运用已发布的项目管理国家标准&#xf…

平衡相图在资源可持续利用方向的应用

平衡相图是描述物质在特定温度、压力和组成条件下达到相平衡状态的图表。在环境科学中&#xff0c;平衡相图可以用于预测和解释自然环境中物质的分布、迁移和转化过程&#xff0c;对于资源的可持续利用和环境污染的防治具有重要意义。 平衡相图在资源的可持续利用方向的应用主…

【YOLOv11[基础]】目标对象模糊处理

目录 一 安装YOLOv11 二 实践 使用Ultralytics YOLO11进行目标对象模糊处理,包括对图像或视频中特定检测到的对象应用模糊效果。这可以使用YOLO11模型功能来识别和操作给定场景中的对象。 目标对象模糊处理的优点: 隐私保护

Day16-非关系型数据库服务-redis

Day16-非关系型数据库服务-redis 1、非关系型数据库服务Redis1.1 Redis服务概述介绍1.1.1 缓存服务介绍1.1.2 缓存服务产品介绍1.1.3 缓存服务应用场景 1.2 Redis服务安装部署1.2.1 缓存服务安装部署 1.3 Redis服务基础管理操作1.3.1 缓存服务配置文件介绍1.3.2 缓存服务安全配…

如何对pdf文件进行加密?pdf文件加密全攻略与深度解析(5个方法)

如何对pdf文件进行加密&#xff1f; 只见&#xff0c;在深夜的情报局里&#xff0c;特工小李将一份绝密PDF文件放在保险箱内&#xff0c;以为这样就天衣无缝了。 细细推敲&#xff0c;漏洞百出&#xff1a; 如果钥匙被盗呢&#xff1f;如果被神匠破解出密码呢&#xff1f;如果…

解析MES管理系统在企业中的应用策略

在智能制造浪潮汹涌的今天&#xff0c;MES管理系统成为了连接生产现场与管理决策层的关键桥梁&#xff0c;其重要性在企业的智能化转型中愈发凸显。面对智能制造时代的新挑战&#xff0c;如何充分利用MES管理系统的优势&#xff0c;实现生产流程的智能、高效与透明&#xff0c;…

Pytest中autouse参数的用法

引言 在Pytest中&#xff0c;Fixture是一种非常有用的功能&#xff0c;它允许我们在测试前后进行一些设置和清理工作。通常&#xff0c;我们会在测试函数中显式地声明需要使用的Fixture。然而&#xff0c;有时候我们希望某些Fixture在所有测试中自动应用&#xff0c;而不需要在…

循序渐进丨openGauss / MogDB 数据库内存占用相关SQL

一、内存总体分布 数据库总体内存使用分布 select * from gs_total_memory_detail; 当dynamic_used_memory大于max_dynamic_memory就会报内存不足&#xff1b;如果此时dynamic_used_memory小于max_dynamic_memory&#xff0c;而dynamic_peak_memory大于max_dynamic_memory表…