Redis 7.x 系列【16】持久化机制之 AOF

有道无术,术尚可求,有术无道,止于术。

本系列Redis 版本 7.2.5

源码地址:https://gitee.com/pearl-organization/study-redis-demo

文章目录

    • 1. 概述
    • 2. 执行原理
      • 2.1 Redis 6.x
        • 2.1.1 直接写
        • 2.1.2 重写
      • 2.2 Redis 7.x
        • 2.2.1 直接写
        • 2.2.2 重写
    • 3. 配置项
      • 3.1 appendonly
      • 3.2 appendfilename
      • 3.3 appenddirname
      • 3.4 appendfsync
      • 3.5 no-appendfsync-on-rewrite
      • 3.6 auto-aof-rewrite-percentage、auto-aof-rewrite-min-size
      • 3.7 aof-load-truncated
      • 3.8 aof-use-rdb-preamble
      • 3.9 aof-timestamp-enabled

1. 概述

默认情况下,Redis 使用RDB持久化,但如果进程出现问题或电源中断,可能会导致几分钟的写入数据丢失(具体取决于配置的保存点)。

Append Only FileAOF)是另一种持久化模式,它提供了更好的持久性保证。AOF 以日志的形式来记录每个写操作,Redis重启时通过读取和执行AOF文件中的命令来重建数据集。

优点:

  • 备份机制更稳健,丢失数据概率更低。
  • 可读的日志文本,通过操作AOF文件,可以处理误操作。

缺点:

  • 比起RDB占用更多的磁盘空间。
  • 恢复备份速度要慢。
  • 每次读写都同步的话,有一定的性能压力。
  • 存在个别Bug,造成不能恢复。

2. 执行原理

2.1 Redis 6.x

Redis 6 及之前的版本中,生成的 AOF 只有一个( appendonly.aof ),整个执行流程如下:

在这里插入图片描述

2.1.1 直接写

Redis 在执行写操作时,并不是将指令直接写入到文件中,而是先写入到缓冲区(aof_buf),然后根据相应的策略同步( fsync )到磁盘中,支持以下三种不同的模式(后面配置有详细介绍):

  • no:操作系统自行决定
  • always:每次写入都会立即被刷新到磁盘
  • everysec:每秒只进行一次 fsync 调用

写入的 AOF 文件如下所示:

在这里插入图片描述
Redis 宕机重启时,可以通过读取和执行 AOF 文件中的命令来重建数据集。但是每一次写指令都会存入到 AOF 文件,可能会导致文件变得非常大,文件太大时,无论是写入还是加载都会变得特别慢。

2.1.2 重写

为了避免 AOF 文件多大问题,控制文件大小并优化性能,Redis 支持运行时触发 AOF 文件重写(rewrite),用以压缩 AOF 文件的大小。

重写机制可以通过 BGREWRITEAOF 命令手动触发,也可以自动触发,配置参数如下:

# 当 AOF 文件大小超过上次重写后 AOF 文件大小的百分比时自动触发,默认值为 100 
auto-aof-rewrite-percentage 100
# 当 AOF 文件大小超过指定值时自动触发,默认值为 64 MB
auto-aof-rewrite-min-size 64mb

当触发重写机制后, Redis 主进程会阻塞等待(微秒级)并执行 fork 创建子进程,创建完成后,会继续接收新的请求命令,并将 fork 后的写操作写入到缓冲区并刷盘。此外新操作还会写入到重写缓冲区aof_rewrite_buf)中,以便重写完成后合并到新文件中,确保和内存数据的一致性。

重写子进程会根据当前时刻 Redis 的数据快照,将每个键值对转换为相应的写入命令,并写入到一个临时文件中 ( temp-rewriteaof-bg-pid.aof)。当上述操作完成后,主进程会将重写缓冲区中的数据发送给子进程,由子进程将数据追加到临时AOF文件中。

子进程重写完成后,会发送消息给主进程,主进程负责将重写缓冲区(可能存在未发送的数据)中剩余数据继续追加到临时AOF文件,并执行原子性的重命名操作,覆盖原先的AOF文件,至此整个重写流程结束。

上述 AOF 重写机制存在一些问题:

  • 内存开销:主进程 fork 之后的新操作,会同时写入到缓冲区重写缓冲区,重复内容会带来额外的内存冗余开销。一旦内存开销太大,可能会触发 Redis 内存限制,影响正常命令的写入,甚至会触发操作系统限制被 OOM Killer杀死,导致服务不可用。
  • CPU 开销:可能会造成 Redis在执行命令时出现 RT 上的抖动,甚至造成客户端超时的问题。
    • 重写期间主进程需要花费CPU时间向重写缓冲区写数据,并使用eventloop事件循环向子进程发送重写缓冲区中的数据
    • 在子进程执行重写操作的后期,会循环读取pipe中主进程发送来的增量数据,然后追加写入到临时AOF文件
    • 在子进程完成重写操作后,主进程会进行收尾工作。其中一个任务就是将在重写期间重写缓冲区中没有消费完成的数据写入临时AOF文件。如果遗留的数据很多,这里也将消耗CPU时间。
  • 磁盘IO开销:重写期间主进程的双写操作,缓冲区中的数据最终会被写入到当前使用的旧AOF文件中,产生磁盘IO重写缓冲区中的数据也会被写入重写生成的新AOF文件中,产生磁盘IO。因此,同一份数据会产生两次磁盘IO
  • 代码复杂度Redis使用六个 pipe 进行主进程和子进程之间的数据传输和控制交互,这使得整个重写逻辑变得更为复杂和难以理解。

2.2 Redis 7.x

Redis 7AOF 机制进行了优化,发布了新特性Multi Part AOF,将单个 AOF 拆分为多个,该特性由阿里云数据库Tair团队贡献。

AOF文件分为三种类型:

  • BASE:基础AOF文件,它一般由子进程通过重写产生,该文件最多只有一个。
  • INCR:增量AOF文件,它一般会在重写开始执行时被创建,该文件可能存在多个。
  • HISTORY:表示历史AOF,它由BASEINCR AOF变化而来,每次重写成功完成时,本次重写之前对应的BASEINCR AOF都将变为HISTORYHISTORY类型的AOF会被Redis自动删除。

为了管理这些AOF文件,引入了一个清单(manifest)文件来跟踪、管理这些AOF。同时,为了便于AOF备份和拷贝,所有的AOF文件和manifest文件放入一个单独的文件目录中,默认为 appendonlydir

在这里插入图片描述
整个执行流程如下:

在这里插入图片描述

2.2.1 直接写

Redis 刚启动时,就会创建BASEINCR文件:

在这里插入图片描述
在没有触发重写机制时,执行流程和 Redis 6 一样,只是命令被写入的文件是 appendonly.aof.1.incr.aof 。当 Redis 重启时,会加载BASEINCR文件中的命令来重建数据集。

在这里插入图片描述

2.2.2 重写

当触发重写机制后, Redis 主进程会阻塞等待(微秒级)并执行 fork 创建子进程,创建完成后,会继续接收新的请求命令,并将 fork 后的写操作写入到新打开的INCR(增量AOF)文件,不再需要写入到重写缓冲区aof_rewrite_buf)中,降低了内存消耗。

子进程的重写操作完全是独立的,重写期间不会与主进程进行任何的数据和控制交互,最终重写操作会产生一个新打开的BASE AOF文件。

新生成的BASE AOF和新打开的INCR AOF就代表了当前时刻 Redis的全部数据。重写结束时,主进程会负责更新 manifest 文件,将新生成的BASE AOFINCR AOF信息加入进去,并将之前的BASE AOF和INCR AOF标记为HISTORY(会被Redis异步删除)。一旦manifest文件更新完毕,就标志整个重写流程结束。

Multi Part AOF的引入,成功的解决了之前重写存在的内存和CPU开销,解决了对Redis实例甚至业务访问带来的不利影响。

3. 配置项

redis.confAOF 相关的配置如下:

############################## APPEND ONLY MODE ################################ By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points).
#
# The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
#
# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check https://redis.io/topics/persistence for more information.appendonly no# The base name of the append only file.
#
# Redis 7 and newer use a set of append-only files to persist the dataset
# and changes applied to it. There are two basic types of files in use:
#
# - Base files, which are a snapshot representing the complete state of the
#   dataset at the time the file was created. Base files can be either in
#   the form of RDB (binary serialized) or AOF (textual commands).
# - Incremental files, which contain additional commands that were applied
#   to the dataset following the previous file.
#
# In addition, manifest files are used to track the files and the order in
# which they were created and should be applied.
#
# Append-only file names are created by Redis following a specific pattern.
# The file name's prefix is based on the 'appendfilename' configuration
# parameter, followed by additional information about the sequence and type.
#
# For example, if appendfilename is set to appendonly.aof, the following file
# names could be derived:
#
# - appendonly.aof.1.base.rdb as a base file.
# - appendonly.aof.1.incr.aof, appendonly.aof.2.incr.aof as incremental files.
# - appendonly.aof.manifest as a manifest file.appendfilename "appendonly.aof"# For convenience, Redis stores all persistent append-only files in a dedicated
# directory. The name of the directory is determined by the appenddirname
# configuration parameter.appenddirname "appendonlydir"# The fsync() call tells the Operating System to actually write data on disk
# instead of waiting for more data in the output buffer. Some OS will really flush
# data on disk, some other OS will just try to do it ASAP.
#
# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".# appendfsync always
appendfsync everysec
# appendfsync no# When the AOF fsync policy is set to always or everysec, and a background
# saving process (a background save or AOF log background rewriting) is
# performing a lot of I/O against the disk, in some Linux configurations
# Redis may block too long on the fsync() call. Note that there is no fix for
# this currently, as even performing fsync in a different thread will block
# our synchronous write(2) call.
#
# In order to mitigate this problem it's possible to use the following option
# that will prevent fsync() from being called in the main process while a
# BGSAVE or BGREWRITEAOF is in progress.
#
# This means that while another child is saving, the durability of Redis is
# the same as "appendfsync no". In practical terms, this means that it is
# possible to lose up to 30 seconds of log in the worst scenario (with the
# default Linux settings).
#
# If you have latency problems turn this to "yes". Otherwise leave it as
# "no" that is the safest pick from the point of view of durability.no-appendfsync-on-rewrite no# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb# An AOF file may be found to be truncated at the end during the Redis
# startup process, when the AOF data gets loaded back into memory.
# This may happen when the system where Redis is running
# crashes, especially when an ext4 filesystem is mounted without the
# data=ordered option (however this can't happen when Redis itself
# crashes or aborts but the operating system still works correctly).
#
# Redis can either exit with an error when this happens, or load as much
# data as possible (the default now) and start if the AOF file is found
# to be truncated at the end. The following option controls this behavior.
#
# If aof-load-truncated is set to yes, a truncated AOF file is loaded and
# the Redis server starts emitting a log to inform the user of the event.
# Otherwise if the option is set to no, the server aborts with an error
# and refuses to start. When the option is set to no, the user requires
# to fix the AOF file using the "redis-check-aof" utility before to restart
# the server.
#
# Note that if the AOF file will be found to be corrupted in the middle
# the server will still exit with an error. This option only applies when
# Redis will try to read more data from the AOF file but not enough bytes
# will be found.
aof-load-truncated yes# Redis can create append-only base files in either RDB or AOF formats. Using
# the RDB format is always faster and more efficient, and disabling it is only
# supported for backward compatibility purposes.
aof-use-rdb-preamble yes# Redis supports recording timestamp annotations in the AOF to support restoring
# the data from a specific point-in-time. However, using this capability changes
# the AOF format in a way that may not be compatible with existing AOF parsers.
aof-timestamp-enabled no

3.1 appendonly

appendonly 用于控制是否启用AOF持久化。

appendonly no

被设置为 no(默认) 时,Redis 不会使用 AOF 持久化机制。

3.2 appendfilename

appendfilename 用于配置 AOF 文件的基础名称。

appendfilename "appendonly.aof"

Redis 7 及更高版本使用一组仅追加文件进行AOF,文件主要有两种类型:

  • 基础文件:是数据集在文件创建时完整状态的快照。基础文件可以是 RDB(二进制序列化)格式或 AOF(文本命令)格式。
  • 增量文件:包含在上一个文件之后对数据集应用的其他命令。

此外,还使用清单文件来跟踪文件的创建顺序,以及它们应该被应用的顺序。

Redis 根据特定的模式创建AOF文件的名称。文件名的前缀基于appendfilename配置参数,后面跟着关于序列和类型的额外信息。

例如,如果 appendfilename被设置为appendonly.aof,那么可能会产生以下文件名:

  • appendonly.aof.1.base.rdb 作为基础文件。
  • appendonly.aof.1.incr.aof, appendonly.aof.2.incr.aof 作为增量文件。
  • appendonly.aof.manifest 作为清单文件。

3.3 appenddirname

appenddirname 配置AOF文件的存储目录。

appenddirname "appendonlydir"

3.4 appendfsync

appendfsync 用于配置AOF缓冲区将操作同步(sync)到磁盘的AOF文件中的策略。

# appendfsync always
appendfsync everysec
# appendfsync no

fsync() 是一个系统调用,它告诉操作系统将数据实际写入磁盘,而不是等待更多的数据进入输出缓冲区。不同的操作系统对 fsync() 的实现可能有所不同,一些系统会立即将数据写入磁盘,而另一些系统则会尽快尝试这样做。

Redis 支持三种不同的 fsync 模式:

  • no:不进行 fsync 调用,让操作系统自行决定何时将数据刷新到磁盘。这种方式速度最快,但可能存在数据丢失的风险。
  • always:每次写入 AOF 日志后都进行 fsync 调用。这是最慢但最安全的方式,因为每次写入都会立即被刷新到磁盘。
  • everysec:每秒只进行一次 fsync 调用。这是速度和数据安全性之间的一个折中方案。

默认值是 everysec,因为它通常是在速度和数据安全性之间最好的折中方案。你可以根据自己的需求调整这个设置。如果你能接受一些数据丢失的风险并且追求更好的性能,可以考虑使用 no 模式(但请注意,如果你能接受数据丢失,那么默认的基于快照的持久化模式可能更合适)。相反,如果你追求更高的数据安全性,即使这意味着性能会降低,可以使用 always 模式。

3.5 no-appendfsync-on-rewrite

no-appendfsync-on-rewrite 用于配置在BGSAVEBGREWRITEAOF正在进行时,是否阻止主进程调用fsync()

no-appendfsync-on-rewrite no

AOFfsync策略设置为alwayseverysec时,如果有一个后台保存进程(后台保存或AOF日志后台重写)正在对磁盘进行大量I/O操作,在某些Linux配置下,Redis可能会在fsync()调用上阻塞过长时间。目前这个问题没有修复方法,因为即使在不同的线程中执行fsync也会阻塞我们的同步write调用。

默认为no,不阻止主进程fsync(),还是会把数据往磁盘里刷,但是遇到重写操作,可能会发生阻塞,数据安全,但是性能降低。

当设置为yes时,在BGSAVEBGREWRITEAOF正在进行时,主进程将不会执行fsync调用。这意味着在这段时间内,Redis的持久性与appendfsync no设置时相同,即数据不会立即同步到磁盘。在最坏的情况下,你可能会丢失最多30秒(使用默认Linux设置)的AOF日志数据。因此,如果你对延迟很敏感,可以将其设置为yes。但是,从持久性的角度来看,将其保持为no(默认值)是最安全的选择。

3.6 auto-aof-rewrite-percentage、auto-aof-rewrite-min-size

AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redisfork出一条新进程来将文件重写,也是先写临时文件最后再重命名。

重写过程会创建一个新的 AOF 文件,其中只包含能够恢复当前数据状态所必需的最少命令,从而减小 AOF 文件的大小。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-percentage 用于设置一个百分比阈值,当 AOF 文件的大小相对于上一次重写后的大小增长了超过这个百分比时,Redis 就会自动触发 BGREWRITEAOF 命令来重写 AOF 文件。设置为 100(即 100%),那么当 AOF 文件的大小增长了一倍时触发重写。

auto-aof-rewrite-min-size 用于设置一个 AOF 文件重写所需的最小大小(以字节为单位)。只有当 AOF 文件的大小既超过了指定的百分比( auto-aof-rewrite-percentage ),又超过了 auto-aof-rewrite-min-size 指定的最小大小时,Redis 才会触发 AOF 文件的重写。

3.7 aof-load-truncated

aof-load-truncated 用于配置如果 AOF 文件末尾被截断时的相关处理策略。

aof-load-truncated yes

Redis 启动过程中,当 AOF 数据被加载回内存时,可能会发现 AOF 文件末尾被截断。例如,在运行 Redis 的操作系统崩溃时,尤其是当 ext4 文件系统被挂载但没有使用 data=ordered 选项。然而,当 Redis 本身崩溃或中止但操作系统仍然正常工作时,这种情况不会发生。

当发生这种情况时,Redis 可以选择报错退出,或者加载尽可能多的数据(现在是默认行为)并启动,如果 AOF 文件末尾被截断。以下选项控制这种行为。

  • aof-load-truncated yes:会加载一个被截断的 AOF 文件,并且 Redis 服务器会开始记录日志以通知用户该事件。
  • aof-load-truncated no:服务器会报错并拒绝启动。当选项设置为 no 时,用户需要使用 “redis-check-aof” 工具修复 AOF 文件后再重新启动服务器。

3.8 aof-use-rdb-preamble

aof-use-rdb-preamble 用于配置是否使用 RDB 格式创建AOF的基础文件。使用 RDB 格式总是更快、更高效。

aof-use-rdb-preamble yes

3.9 aof-timestamp-enabled

aof-timestamp-enabled 用于配置 Redis 是否支持在 AOF 中记录时间戳,以支持从特定时间点恢复数据。但是,使用这种功能会以可能与现有 AOF 解析器不兼容的方式更改 AOF 格式。

aof-timestamp-enabled no

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

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

相关文章

JAVA基础-----128陷阱

一、何为128陷阱 Java中Integer类型在使用比较时的特殊行为------128陷阱,解释了当数值在-128到127范围内,由于valueOf方法的缓存机制导致地址相同,比较为真;超出这个范围则新分配内存,地址不同,比较为假。…

抖音矩阵云剪系统saas源码 短视频矩阵获客管理系统

2024抖音矩阵云混剪系统是一款专业的短视频营销管理工具。该系统支持多平台多账号的集中式管理,并实现一键式作品发布功能。它配备了智能标题生成和关键词优化工具,以及排名查询机制,帮助用户提升内容在平台上更好的矩阵管理. 智能剪辑 托管发…

Vue框架引入

vue简介 1.1.vue是什么?Vue官网 英文官网: https://vuejs.org/中文官网: https://cn.vuejs.org/ vue是一套构建用户界面的渐进式javascript框架 构建用户界面:将我们手里拿到的数据通过某种办法变成用户可以看见的界面前端工程师的职责:就是在合适的时候发出合适的请求,然后…

树莓派_Pytorch学习笔记20:初步认识深度学习框架

今日继续学习树莓派4B 4G:(Raspberry Pi,简称RPi或RasPi) 本人所用树莓派4B 装载的系统与版本如下: 版本可用命令 (lsb_release -a) 查询: ​ Python 版本3.7.3: ​ 本文很水,就介绍一下我以后的学习使用P…

R包:ggsci期刊配色

介绍 不同期刊配色大多数时候不一样,为了更好符合期刊图片颜色的配色,有人开发了ggsci这个R包。它提供以下函数: scale_color_palname() scale_fill_palname() 对应不同期刊的color和fill函数。 导入数据R包 library("ggsci")…

vue + element ui 实现侧边栏导航栏折叠收起

首页布局如下 要求点击按钮,将侧边栏收缩, 通过 row 和 col 组件&#xff0c;并通过 col 组件的 span 属性我们就可以自由地组合布局。 折叠前 折叠后 <template><div class"app-layout" :class"{ collapse: app.isFold }"><div class&…

CANoe的capl调用Qt制作的dll

闲谈 因为Qt封装了很多个人感觉很好用的库&#xff0c;所以一直想通过CAPL去调用Qt实现一些功能&#xff0c;但是一直没机会&#xff08;网络上也没看到这方面的教程&#xff09;&#xff0c;这次自己用了两天&#xff0c;踩了很多坑&#xff0c;终于是做成了一个初步的调用方…

Zabbix分布式监控

目录 分布式监控架构 实现分布式监控的步骤 优点和应用场景 安装Zabbix_Proxy Server端Web页面配置 测试 Zabbix 的分布式监控架构允许在大规模和地理上分散的环境中进行高效的监控。通过分布式监控&#xff0c;Zabbix 可以扩展其监控能力&#xff0c;支持大量主机和设备…

汇川CodeSysPLC教程 Modbus变量编址

线圈&#xff1a;位变量&#xff0c;只有两种状态0和1。汇川PLC中包含Q区及SM区等变量。 寄存器&#xff1a;16位&#xff08;字&#xff09;变量&#xff0c;本PLC中包含M区及SD区等变量 说明&#xff1a; 汇川HMI的专用协议使用不同功能码&#xff1a;在访问SM时&#xff0c…

Linux搭建hive手册

一、将hive安装包上传到NameNode节点并解压 1、删除安装MySQL时的.rpm文件 cd /opt/install_packages/ rm -rf *.rpm 2、将安装包拖进/install_packages目录 3、解压安装包 tar -zxvf apache-hive-3.1.2-bin.tar.gz -C /opt/softs/ 4、修改包名 cd /opt/softs mv apache-…

如何在应用运行时定期监控内存使用情况

如何在应用运行时定期监控内存使用情况 在 iOS 应用开发中&#xff0c;实时监控内存使用情况对于优化性能和排查内存泄漏等问题非常重要。本文将介绍如何在应用运行时定期监控内存使用情况&#xff0c;使用 Swift 编写代码并结合必要的工具和库。 1. 创建桥接头文件 首先&…

PyCharm如何安装requirements.txt中的依赖包

问题&#xff1a;下载别人的源码&#xff0c;如何安装代码中requirement.txt中的依赖包。 解决方案&#xff1a; &#xff08;1&#xff09;打开PyCharm下面的Terminal&#xff0c;先为代码创建单独的虚拟环境并进入到虚拟环境中&#xff08;每个项目单独的环境&#xff0c;这…

LLM- 注意力机制

一&#xff1a;什么是注意力机制&#xff0c;以及产生背景&#xff1f; &#xff08;1&#xff09;&#xff1a;RNN模型[RNN模型]的缺点&#xff1a;下图是例如RNN模型解决机器翻译的例子&#xff0c;从这个例子可以看到Encoder最后一个向量&#xff08;eos&#xff09;送给了…

bdeaver mysql忘记localhost密码修改密码添加用户

描述 bdeaver可以连接当前的localhost数据库&#xff0c;但不知道数据库密码是什么。用这个再建一个用户&#xff0c;用来连接数据库 解决 1、在当前的数据库localhost右键&#xff0c;创建-用户 设置这个用户&#xff0c;密码 加权限 2、连接 用新的账号密码去连接&#x…

Keepalived+LVS实现负责均衡,高可用的集群

Keepalived的设计目标是构建高可用的LVS负载均衡群集&#xff0c;可以调用ipvsadm工具来创建虚拟服务器&#xff0c;管理服务器池&#xff0c;而不仅仅用作双机热备。使用Keepalived构建LVS群集更加简便易用&#xff0c;主要优势体现在&#xff1a;对LVS负责调度器实现热备切换…

【购物车案例】for循环为什么使用key

要做出一个简单的购物车界面。首先&#xff0c;有一个复选框&#xff0c;可以选择商品&#xff0c;后面紧跟的是商品名称&#xff0c;然后&#xff0c;是删除按钮&#xff0c;根据这个需求&#xff0c;先写出一个简单的界面&#xff0c;代码如下&#xff1a; <template>…

1.8-word2vec的改进

文章目录 1问题分析一2改进一之Embedding层2.1 Embedding层的实际作用2.2数组切片获取某行的操作2.3 Embedding层的实现2.3.1初始化2.3.2前向计算2.3.3反向传播 3问题分析二4改进二之将多分类变为二分类4.1二分类问题4.1.1概率转换与损失计算4.1.2反向传播4.1.3多分类与二分类的…

2025 百度提前批校招内推

百度2025校园招聘内推开始啦&#xff0c;被推荐人可以免笔试直接面试&#xff0c;提前批结果不影响校招&#xff0c;机会1&#xff0c;还可直推心仪部门&#xff0c;可扫描下面二维码或点击链接进行投递&#xff0c;快来投递你心仪的职位吧&#xff08; 网申链接地址 &#xff…

【面向就业的Linux基础】从入门到熟练,探索Linux的秘密(十)-git(2)

下面是一些git的常用命令和基本操作&#xff0c;可以当做平常的笔记查询&#xff0c;用于学习&#xff01;&#xff01;&#xff01; 文章目录 前言 一、git 二、git常用命令 总结 前言 下面是一些git的常用命令和基本操作&#xff0c;可以当做平常的笔记查询&#xff0c;用于…

第十四届蓝桥杯省赛C++B组F题【岛屿个数】题解(AC)

题目大意 给定一个 01 地图&#xff0c;分别表示陆地和海&#xff0c;问地图中一共有多少块岛屿&#xff1f;另外&#xff0c;若一个岛屿在另一个岛屿的内部&#xff0c;则不统计。如下图中的大岛屿包含着内部的小岛屿&#xff0c;故内部小岛屿不计算&#xff0c;最终输出 1。…