MySQL之Redo Log：确保数据持久性和崩溃恢复

文章目录

  • MySQL Redo Log：确保数据持久性和崩溃恢复
    • 1. 简介：Redo Log 的本质
    • 2. 核心概念和机制
      • 2.1. 预写式日志 (WAL)
      • 2.2. Redo Log 结构
      • 2.3. 日志序列号 (LSN)
      • 2.4. Redo Log 记录格式
      • 2.5. 迷你事务 (MTR)
      • 2.6. Redo Log 写入过程
      • 2.7. 组提交优化
      • 2.8. `innodb_flush_log_at_trx_commit`
    • 3. 检查点机制
    • 4. 崩溃恢复
    • 5. 电商场景应用
    • 6. 备份与恢复
      • 6.1. 时间点恢复 (PITR)
      • 6.2. 崩溃恢复流程
    • 7. 性能调优参数
    • 8. 监控与诊断
      • 8.1. 关键状态指标
      • 8.2. 性能分析工具
    • 9. 总结与最佳实践

MySQL Redo Log：确保数据持久性和崩溃恢复

1. 简介：Redo Log 的本质

Redo Log（重做日志）是 MySQL InnoDB 存储引擎中实现持久性的基石。它是一种物理日志，记录了对数据页所做的修改，而不是行级别的变更。这种“物理”特性使其在崩溃恢复时更加紧凑和高效。Redo Log 的核心原则是“预写式日志”（Write-Ahead Logging，WAL）：在将更改应用到数据文件之前先记录日志。这确保了即使数据库在修改后的数据页写入磁盘之前崩溃，已提交的事务也不会丢失。Redo Log 有效地体现了承诺：“已提交的内容一定会完成，即使在崩溃后也是如此。”

2. 核心概念和机制

2.1. 预写式日志 (WAL)

Redo Log 的基础是 WAL 原则：

  1. 先写日志： 当事务修改数据时，InnoDB 首先将更改的记录写入 Redo Log Buffer（内存中）。

  2. 提交需要日志刷新： 只有当 Redo Log 条目刷新到 Redo Log Files（磁盘上）后，事务才被视为已提交。innodb_flush_log_at_trx_commit 参数控制此行为。

  3. 数据页稍后刷新： Buffer Pool 中修改后的数据页在后台异步刷新到数据文件。

WAL 的优点：

  • 持久性： 保证已提交的事务在崩溃后存活。即使数据页未写入，Redo Log 也包含重新应用更改所需的信息。

  • 性能： Redo Log 写入是顺序的（追加到文件），这比写入数据页所需的随机 I/O 快得多。

2.2. Redo Log 结构

Redo Log 由两个主要部分组成：

  • Redo Log Buffer（内存）： 一个内存缓冲区，Redo Log 记录最初写入其中。其大小由 innodb_log_buffer_size 控制。

  • Redo Log Files（磁盘）： 磁盘上的物理文件（通常命名为 ib_logfile0、ib_logfile1 等），Redo Log 记录持久化存储在其中。这些文件以循环方式写入。这些文件的数量和大小分别由 innodb_log_files_in_group 和 innodb_log_file_size 配置。

2.3. 日志序列号 (LSN)

LSN 是一个单调递增的、唯一的字节偏移量，用于标识 Redo Log 文件中 Redo Log 记录的位置。它对于以下方面至关重要：

  • 日志记录标识： 每个 Redo Log 记录都有一个唯一的 LSN。 通过 LSN，InnoDB 能够准确无误地定位到 Redo Log 文件中的每一个 Redo Log 记录。 在崩溃恢复时，需要按顺序读取和重放 Redo Log 记录，LSN 保证了能够正确地找到并处理每一个日志记录，不会遗漏或错乱。 就像图书馆的书籍编号，LSN 确保每条 Redo Log 记录都有唯一的 “地址”。

  • 数据页版本控制 (数据一致性判断): 每个数据页的头部也会记录一个 page_LSN，表示最近一次修改该数据页的 Redo Log 记录的 LSN 值。 page_LSN 非常重要，它用于在崩溃恢复时，判断数据页是否需要进行 Redo 操作，以及应该 Redo 到哪个版本。

    • 崩溃恢复时的数据页检查: 在崩溃恢复阶段，InnoDB 会读取数据页的 page_LSN，并与 Redo Log 中记录的 LSN 进行比较：

      • page_LSN < Redo Log LSN: 表示数据页上的修改操作可能尚未完全刷新到磁盘，需要根据 Redo Log 中的记录进行 Redo (重演) 操作，将数据页更新到 Redo Log 记录对应的状态。

      • page_LSN >= Redo Log LSN: 表示数据页已经包含了 Redo Log 记录对应的修改，无需进行 Redo 操作 (或者已经 Redo 过)。

page_LSN 就像数据页的 “版本戳”，记录了数据页最后更新的时间 (以 LSN 来衡量)。 通过比较 page_LSN 和 Redo Log LSN，InnoDB 能够精确地确定哪些数据页需要恢复，哪些数据页已经是最新状态，从而保证数据一致性。

  • 检查点 (恢复起始点):** Checkpoint LSN 是 Checkpoint 机制的关键组成部分。 Checkpoint 操作会将当前数据库状态 (包括所有脏页和 Redo Log Buffer) 刷新到磁盘，并将当前的 LSN 值记录为 Checkpoint LSN。 Checkpoint LSN 标志着一个数据库状态的快照点。

  • 崩溃恢复的起点: 在崩溃恢复时，InnoDB 不必从 Redo Log 的开头开始重放，而是从 Checkpoint LSN 开始，扫描和重放 Redo Log 记录。 因为 Checkpoint LSN 之前的 Redo Log 记录所对应的修改，都已经保证刷新到磁盘上的数据页了。 Checkpoint LSN 大大缩短了数据库的恢复时间，因为它减少了需要处理的 Redo Log 记录量。 Checkpoint LSN 就像一个 “恢复锚点”，指示了从哪里开始进行数据恢复。

  • 保证 WAL 预写式日志 (核心机制支撑): LSN 是 Write-Ahead Logging (WAL) 预写式日志机制的核心支撑。 WAL 要求必须先将 Redo Log 写入磁盘，才能修改数据页。 LSN 保证了 Redo Log 的顺序性和持久性，使得 WAL 机制能够有效地工作。 每次修改数据页之前，都必须先获取一个更大的 LSN 并写入 Redo Log，确保 Redo Log 的 LSN 始终领先于数据页的 page_LSN，从而保证了数据持久性和崩溃恢复的可靠性。

结构：

  • 结构: LSN 通常并非一个简单的整数，而是由多个部分组成，常见的结构包括：

    • Log File Number (日志文件编号): 标识 Redo Log 记录所在的 Redo Log 文件。 由于 Redo Log Files 通常以文件组形式存在 (例如 ib_logfile0, ib_logfile1, …)，这个编号用来区分不同的日志文件。

    • Log Offset (日志偏移量): 标识 Redo Log 记录在日志文件内的具体偏移位置 (字节数)。

      将日志文件编号和偏移量结合起来，就能在整个 Redo Log 文件组中精确定位到一个 Redo Log 记录。

  • 生成与增长: LSN 由 InnoDB 存储引擎全局维护，并随着 Redo Log 的不断写入而单调递增。 每当生成一条新的 Redo Log 记录时，都会分配一个新的、更大的 LSN。 LSN 的增长反映了数据库事务操作的顺序和时间线。 可以将其理解为数据库操作的 “版本号”，LSN 值越大，代表着数据库状态越新。

2.4. Redo Log 记录格式

Redo Log 记录通常包含：

  • 日志类型： 指定修改的类型（例如，MLOG_COMP_REC_INSERT、MLOG_REC_UPDATE、MLOG_1BYTE、MLOG_2BYTE 等）。

  • 空间 ID 和页号： 标识已修改的数据页。

  • 偏移量和长度： 指示页面内更改的位置和大小。

  • 数据： 实际更改的字节（对于物理日志）或操作的表示（对于逻辑日志）。

  • 事务 ID (trx_id): 标识事务.

  • LSN： 日志序列号.

一个概念性的 C 结构体示例：

struct log_record {uint64_t lsn;        // 日志序列号uint32_t trx_id;     // 事务IDuint16_t type;       // 日志类型（MLOG_COMP_REC_INSERT等）byte data[];         // 重做数据
};

2.5. 迷你事务 (MTR)

MTR 是一组相关的 Redo Log 条目，表示对一个或多个页面的单个原子操作。例如，将一行插入 B+ 树可能涉及修改多个页面（叶节点、内部节点）。将这些更改分组到 MTR 中可确保在恢复期间应用所有更改或不应用任何更改。

2.6. Redo Log 写入过程

写入 Redo Log 条目的过程涉及多个步骤：

  1. 生成 Redo Log 记录： 当事务修改数据页时，InnoDB 创建相应的 Redo Log 记录。

  2. 写入 Log Buffer： 该记录将追加到内存中的 Redo Log Buffer。

  3. 刷新到磁盘： 在以下情况下，Redo Log Buffer 将刷新到磁盘上的 Redo Log Files：

    1. 事务提交： 这是最重要的触发器，由 innodb_flush_log_at_trx_commit 控制。

    2. Log Buffer 已满： 当缓冲区大约半满时。

    3. 后台线程： 后台线程定期刷新缓冲区。

    4. 检查点： 检查点操作会触发刷新。

  4. 三级缓冲机制:

    1. 用户线程生成 MTR (Mini-Transaction)

    2. Log Buffer (innodb_log_buffer_size)

    3. OS Cache (由 innodb_flush_log_at_trx_commit 控制)

    4. 磁盘文件

2.7. 组提交优化

  • 合并多个事务的 fsync 操作。

  • 提高 IOPS 利用率（尤其是在 HDD 上）。

  • 由 binlog_group_commit_sync_delay（延迟时间窗口）控制。

在 MySQL 中，组提交（Group Commit） 是一种通过合并多个事务的日志刷盘操作来提升性能的机制。其核心目标是通过减少磁盘 I/O 次数，尤其是 fsync 操作的频率，从而提高事务提交的吞吐量。以下是具体实现和参数控制：

  1. 组提交的核心原理

  • 合并 **fsync**** 操作**： 默认情况下，每个事务提交时需要将 Redo Log 和 Binlog 分别刷盘（fsync）。组提交通过将多个事务的刷盘操作合并为一次，显著减少磁盘 I/O 次数

  • 三个阶段：

    • Flush 阶段：将 Redo Log 的 prepare 状态数据刷盘，并将 Binlog 写入文件系统缓存（Page Cache）。

    • Sync 阶段：将多个事务的 Binlog 合并后一次性刷盘（fsync），这是性能优化的关键步骤。

    • Commit 阶段：将 Redo Log 状态更新为 commit，无需刷盘（因 Binlog 已持久化）

  1. 参数控制

  • binlog_group_commit_sync_delay：

    • 作用：定义事务组提交的 延迟时间窗口（单位为微秒）。

    • 效果：在等待该参数设置的时长内，收集多个事务的 Binlog，合并后一次性刷盘。例如设置为 1000（1 毫秒），则每毫秒触发一次组提交

    • 适用场景：适用于高并发写入场景，通过增加延迟换取更高的吞吐量，但需权衡响应时间。

  • binlog_group_commit_sync_no_delay_count：

    • 作用：定义触发刷盘的 事务数量阈值。

    • 效果：当队列中的事务数达到该阈值时，立即触发刷盘，忽略 binlog_group_commit_sync_delay 的设置

2.8. innodb_flush_log_at_trx_commit

这个关键参数控制持久性和性能之间的权衡：

  • 0****（最不安全，性能最高）： Redo Log 条目被写入日志缓冲区，并每秒刷新到操作系统的缓存。崩溃可能会丢失最多一秒的事务。

  • 1****（最安全，默认，推荐）： Redo Log 条目在每次事务提交时写入日志缓冲区并刷新到磁盘（使用 fsync）。保证不丢失已提交的事务。

  • 2****（中等安全，中等性能）： Redo Log 条目在提交时写入日志缓冲区并写入操作系统的缓存。刷新到磁盘会发生，但不一定立即使用 fsync。操作系统（不仅仅是 MySQL）崩溃可能会丢失事务。

3. 检查点机制

Redo Log 文件的大小是有限的。检查点机制可防止它们被填满并加快崩溃恢复速度。

  • 目的：

    • 缩短恢复时间： 恢复只需要应用最后一个检查点之后的 Redo Log 条目。

    • 回收日志空间： 一旦相应的脏页已刷新到磁盘，检查点之前的 Redo Log 条目就不再需要。

  • 过程：

    • 确定检查点 LSN： 通常是缓冲池中最早的修改的 LSN（最早的脏页）。

    • 刷脏页： 将检查点 LSN 之前的所有脏页（Buffer Pool 中已修改但尚未刷新到磁盘的数据页）刷新到磁盘。

    • 记录检查点信息： 将检查点 LSN 和其他信息写入 Redo Log 文件和数据文件头。

    • 回收 Redo Log 文件空间: 检查点 LSN 之前的 Redo Log 文件空间可以被标记为“可重用”。

  • 检查点类型:

    • Sharp Checkpoint: 在数据库正常关闭时执行，刷新所有脏页。恢复速度最慢，但数据最安全。

    • Fuzzy Checkpoint (模糊检查点): 在数据库运行期间定期执行，只刷新部分脏页。

      • Master Thread Checkpoint: 由 Master Thread 定期触发。

      • LRU Checkpoint: 淘汰 LRU 链表尾部的脏页时触发。

      • Async Flush Checkpoint: 限制脏页比例过高时触发。

      • InnoDB Shutdown Checkpoint: 关闭时执行，类似于 Sharp Checkpoint。

4. 崩溃恢复

当 MySQL 崩溃并重新启动时，InnoDB 使用 Redo Log 执行崩溃恢复：

  1. 确定起始位置： 从数据文件头读取检查点 LSN。

  2. 扫描 Redo Log： 从检查点 LSN 开始，扫描 Redo Log 文件。

  3. 重放 Redo Log (Redo)： 对于每个 Redo Log 记录，InnoDB 重做对数据页的物理修改。

  4. 应用 Undo Log (Undo)： 对于崩溃时尚未提交的事务，InnoDB 使用 Undo Log 回滚更改。

优化:

  • 使用哈希表按页面对 Redo Log 条目进行分组，减少恢复期间的随机 I/O。

  • 通过比较页面的 FIL_PAGE_LSN 和检查点 LSN，跳过已刷新到磁盘的页面。

5. 电商场景应用

  • 订单支付持久性: Redo Log 确保支付记录和订单状态更新永久保存。

  • 库存扣减可靠性: Redo Log 确保库存扣减操作的持久性，避免超卖。

  • 用户账户资金安全: Redo Log 保证账户资金操作的持久性。

  • 事务 ACID 特性保障: Redo Log 与 Undo Log、锁机制、MVCC 等共同保证事务的 ACID 特性。

  • 秒杀库存扣减保障（例子）

/* 事务提交策略 */
SET GLOBAL innodb_flush_log_at_trx_commit=1;  -- 实时刷盘保证数据安全START TRANSACTION;
UPDATE stock SET quantity=quantity-1 
WHERE item_id=1001 AND quantity>0;
COMMIT;  -- 触发Redo日志同步写入
  • 分布式事务恢复 (XA 例子)
-- 使用XA事务协调多个数据库
XA START 'order_transaction';
UPDATE orders SET status=2 WHERE order_id=1001;
XA END 'order_transaction';
XA PREPARE 'order_transaction';  -- 写入Redo日志-- 崩溃恢复时自动重做已Prepare的事务

6. 备份与恢复

6.1. 时间点恢复 (PITR)

  1. 全量备份 + Redo 日志
# 备份时记录LSN
mysqldump --single-transaction --master-data=2 > backup.sql# 恢复时应用Redo
mysqlbinlog --start-position=457890 /var/lib/mysql/ib_logfile* | mysql -uroot -p
  1. 与 Binlog 协同工作
日志类型记录内容恢复作用
Redo Log物理页修改保证存储引擎数据
Binlog逻辑SQL语句保证数据逻辑一致

6.2. 崩溃恢复流程

  1. 前滚（Redo）阶段

    1. 从 Checkpoint LSN 开始重做所有日志

    2. 通过 LSN 顺序保证恢复一致性

  2. 回滚（Undo）阶段

    1. 扫描未提交事务的 Undo Log 进行回滚

    2. 维护事务原子性

7. 性能调优参数

参数名默认值推荐值作用域风险说明
innodb_log_file_size48MB4-8GB静态修改需删除旧日志文件
innodb_log_files_in_group23-4静态总大小不超过512GB
innodb_flush_log_at_trx_commit11（金融）/2（电商）动态设为0可能丢失1秒数据
innodb_log_buffer_size16MB64-256MB动态大事务场景需调大

8. 监控与诊断

8.1. 关键状态指标

SHOW ENGINE INNODB STATUS\G
-- LOG段重点指标
Log sequence number 117766351395  -- 当前LSN
Log flushed up to   117766351395  -- 刷盘LSN
Last checkpoint at  117766351386  -- Checkpoint LSN

8.2. 性能分析工具

# 使用innodb_ruby解析日志文件
innodb_space -s ibdata1 -T test/t1 -p 3 page-dump | grep -i lsn# 监控日志写入吞吐
iostat -x 1 | grep -E 'Device|sda'  # 观察磁盘写入量

9. 总结与最佳实践

  • 理解 WAL 原理: 深入理解预写式日志 (WAL) 的工作原理。

  • 合理配置 Redo Log 参数: 根据应用场景合理配置 Redo Log 参数。

  • 监控 Redo Log 状态: 监控 Redo Log 的写入速度、刷新频率等指标。

  • 定期备份 Redo Log (归档): 定期备份 Redo Log 可用于审计和数据恢复。

  • 结合其他日志类型: Redo Log 专注于数据持久性，MySQL 还有其他类型的日志，共同保障数据库的可靠性。理解各种日志类型的特点和作用。

  • 金融级系统保持**innodb_flush_log_at_trx_commit=1**，电商等高并发场景可适当放宽至2以提升吞吐量。

Redo Log 是 MySQL InnoDB 存储引擎中至关重要的组件，它默默地守护着数据的持久性，是构建可靠、稳定的 MySQL 应用系统的基石。深入理解 Redo Log 的工作原理和配置调优，对于数据库管理员和开发人员都至关重要。

参考：https://relph1119.github.io/mysql-learning-notes/#/mysql ,推荐理解本文之后去看原书，原书有一定深度需前后贯穿仔细理解

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

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

相关文章

搭建Nexus前端npm私服，上传发布npm包和下载依赖

搭建Nexus前端npm私服，上传发布npm包和下载依赖

1、创建repository 登录Nexus的管理页面&#xff0c;创建npm&#xff08;proxy&#xff09;和npm&#xff08;hosted&#xff09;&#xff0c;然后创建npm&#xff08;group&#xff09;将这两个repository包含进来。 1.1 创建npm&#xff08;proxy&#xff09; 选择npm&…
阅读更多...
数组总结【代码随想录】

数组总结【代码随想录】

一.数组 1.lc 27移除数组中的重复元素 且必须仅使用 O(1) 额外空间并 原地 修改输入数组。 输入&#xff1a;nums [3,2,2,3], val 3 输出&#xff1a;2, nums [2,2] 解释&#xff1a;函数应该返回新的长度 2, 并且 nums 中的前两个元素均为 2。你不需要考虑数组中超出新长…
阅读更多...
大模型训练——pycharm连接实验室服务器

大模型训练——pycharm连接实验室服务器

一、引言 我们在运行或者复现大佬论文代码的时候&#xff0c;笔记本的算力不够&#xff0c;需要使用实验室的服务器进行运行。可以直接在服务器的终端上执行&#xff0c;但是这样的话代码调试就不方便。而我们可以使用 pycharm 连接到服务器&#xff0c;既方便了代码调试&…
阅读更多...
STM32的C语言软件延时函数

STM32的C语言软件延时函数

STM32的延时方法很多&#xff0c;其中采用定时器延时&#xff0c;可以得到较为精确的延时&#xff0c;但是有时对延时精度要求不高的场合&#xff0c;采用软件延时&#xff0c;也是必须的。特别是在RTOS系统中&#xff0c;使用SysTick的普通计数模式对延迟进行管理&#xff0c;…
阅读更多...
前端网页或者pwa如何实现只横屏显示，设备竖着的时候依然保持横屏

前端网页或者pwa如何实现只横屏显示，设备竖着的时候依然保持横屏

开发的时候&#xff0c;就是以横屏的样式开发的&#xff0c;所以横屏的展示效果就是&#xff1a; 当设备竖着的时候&#xff0c;会进行缩放&#xff0c;展示效果不友好&#xff0c;所以需要设备竖着的时候&#xff0c;也横屏显示&#xff1a; 实现原理就是&#xff1a;使用css监…
阅读更多...
计算机毕业设计SpringBoot+Vue.js电影评论网站系统(源码+文档+PPT+讲解)

计算机毕业设计SpringBoot+Vue.js电影评论网站系统(源码+文档+PPT+讲解)

温馨提示&#xff1a;文末有 CSDN 平台官方提供的学长联系方式的名片&#xff01; 温馨提示&#xff1a;文末有 CSDN 平台官方提供的学长联系方式的名片&#xff01; 温馨提示&#xff1a;文末有 CSDN 平台官方提供的学长联系方式的名片&#xff01; 作者简介&#xff1a;Java领…
阅读更多...
Locale+Jackson导致Controller接口StackOverflowError异常解决

Locale+Jackson导致Controller接口StackOverflowError异常解决

问题 由于参与的项目有出海需求&#xff0c;即需要给外国人使用&#xff0c;即&#xff1a;需要支持i18n&#xff08;Internationalization的缩写&#xff0c;共20个字母&#xff0c;除去首尾两个字母&#xff0c;中间有18个&#xff0c;故简称i18n&#xff09;。 本来是好的…
阅读更多...
Graph and GNN——图的表示与图神经网络的介绍与应用

Graph and GNN——图的表示与图神经网络的介绍与应用

Hi&#xff0c;大家好&#xff0c;我是半亩花海。细数日子已然有很长一段时间没有更新博客了&#xff0c;不是在忙东忙西&#xff0c;就是在玩这玩那&#xff0c;在家摆&#xff0c;在学校gap&#xff0c;无敌了。言归正传&#xff0c;今天暂且先进一步探索并整理一部分图神经网…
阅读更多...
京准电钟：NTP精密时钟服务器在自动化系统中的作用

京准电钟：NTP精密时钟服务器在自动化系统中的作用

京准电钟&#xff1a;NTP精密时钟服务器在自动化系统中的作用 京准电钟&#xff1a;NTP精密时钟服务器在自动化系统中的作用 NTP精密时钟服务器在自动化系统中的作用非常重要&#xff0c;特别是在需要高精度时间同步的场景中。NTP能够提供毫秒级的时间同步精度&#xff0c;这…
阅读更多...
Https解决了Http的哪些问题

Https解决了Http的哪些问题

部分内容来源&#xff1a;小林coding 详细解析 Http的风险 HTTP 由于是明文传输&#xff0c;所以安全上存在以下三个风险&#xff1a; 1.窃听风险 比如通信链路上可以获取通信内容&#xff0c;用户号容易没。 2.篡改风险 比如强制植入垃圾广告&#xff0c;视觉污染&#…
阅读更多...
GO 进行编译时插桩，实现零码注入

GO 进行编译时插桩，实现零码注入

Go 编译时插桩 Go 语言的编译时插桩是一种在编译阶段自动注入监控代码的技术&#xff0c;目的是在不修改业务代码的情况下&#xff0c;实现对应用程序的监控和追踪。 基本原理 Go 编译时插桩的核心思想是通过在编译过程中对源代码进行分析和修改&#xff0c;将监控代码注入到…
阅读更多...
flex布局自定义一行几栏,靠左对齐===grid布局

flex布局自定义一行几栏,靠左对齐===grid布局

模板 <div class"content"><div class"item">1222</div><div class"item">1222</div><div class"item">1222</div><div class"item">1222</div><div class"…
阅读更多...
微软推出Office免费版，限制诸多，只能编辑不能保存到本地

微软推出Office免费版，限制诸多，只能编辑不能保存到本地

易采游戏网2月25日独家消息&#xff1a;微软宣布推出一款免费的Office版本&#xff0c;允许用户进行基础文档编辑操作&#xff0c;但限制颇多&#xff0c;其中最引人关注的是用户无法将文件保存到本地。这一举措引发了广泛讨论&#xff0c;业界人士对其背后的商业策略和用户体验…
阅读更多...
NLP的预处理数据

NLP的预处理数据

处理文本数据的主要工具是Tokenizer。Tokenizer根据一组规则将文本拆分为tokens。然后将这些tokens转换为数字&#xff0c;然后转换为张量&#xff0c;成为模型的输入。模型所需的任何附加输入都由Tokenizer添加。 如果您计划使用预训练模型&#xff0c;重要的是使用与之关联的…
阅读更多...
应用的负载均衡

应用的负载均衡

概述 负载均衡&#xff08;Load Balancing&#xff09; 调度后方的多台机器&#xff0c;以统一的接口对外提供服务&#xff0c;承担此职责的技术组件被称为“负载均衡”。 负载均衡器将传入的请求分发到应用服务器和数据库等计算资源。负载均衡是计算机网络中一种用于优化资源利…
阅读更多...
C# 根据Ollama+DeepSeekR1开发本地AI辅助办公助手

C# 根据Ollama+DeepSeekR1开发本地AI辅助办公助手

在上一篇《访问DeepSeekR1本地部署API服务搭建自己的AI办公助手》中&#xff0c;我们通过通过Ollama提供的本地API接口用Python实现了一个简易的AI办公助手&#xff0c;但是需要运行Py脚本&#xff0c;还比较麻烦&#xff0c;下面我们用C#依据Ollama提供的API接口开发一个本地A…
阅读更多...
springboot+dubbo+zookeeper的注册服务和调用实践

springboot+dubbo+zookeeper的注册服务和调用实践

目录 zookeeper为什么可作为注册中心zookeeper注册中心优缺点启动zookeeper编写springboot项目提供dubbo服务1. 服务接口2. Springboot引入dubbo实现服务接口2.1 工程目录和依赖2.2 启动程序和application.properties2.3 DubboService 实现服务接口2.4 测试api&#xff0c;用于…
阅读更多...
NL2SQL的应用-长上下文模型在处理NL2SQL任务时，相较于传统模型，有哪些显著的优势

NL2SQL的应用-长上下文模型在处理NL2SQL任务时，相较于传统模型，有哪些显著的优势

大家好&#xff0c;我是微学AI&#xff0c;今天给大家介绍一下NL2SQL的应用-长上下文模型在处理NL2SQL任务时&#xff0c;相较于传统模型&#xff0c;有哪些显著的优势。NL2SQL&#xff08;自然语言转SQL&#xff09;技术旨在将用户自然语言提问自动转换为结构化查询语句&#…
阅读更多...
A Large Recurrent Action Model: xLSTM Enables Fast Inference for Robotics Tasks

A Large Recurrent Action Model: xLSTM Enables Fast Inference for Robotics Tasks

奥地利林茨约翰开普勒大学机器学习研究所 ELLIS 小组&#xff0c;LIT 人工智能实验室奥地利林茨 NXAI 有限公司谷歌 DeepMind米拉 - 魁北克人工智能研究所 摘要 近年来&#xff0c;强化学习&#xff08;Reinforcement Learning, RL&#xff09;领域出现了一种趋势&#xff0c;…
阅读更多...
DeepSeek本地部署+自主开发对话Web应用

DeepSeek本地部署+自主开发对话Web应用

文章目录 引言前端部分核心页面DeepSeek.vueMyModal.vue 后端部分WebSocketConfig 配置类AbstractDeepSeekToolDeepSeekWebSocketHandler 数据库设计总结 引言 最近DeepSeep横空出世&#xff0c;在全球内掀起一股热潮&#xff0c;到处都是满血大模型接入的应用&#xff0c;但这…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023