事务隔离级别

事务隔离级别是数据库系统中控制事务间相互影响程度的重要机制。不同的隔离级别在数据一致性保证和系统性能之间提供不同的权衡选择。下面我将详细解析四种标准隔离级别、它们能解决的问题以及可能存在的并发问题。

一、四种标准隔离级别

1. 读未提交 (Read Uncommitted)

  • 定义：事务可以读取其他事务尚未提交的修改（“脏读”）
  • 实现方式：通常不施加读锁或读取最新版本（包括未提交的）
  • 特点：
    • 性能最好（几乎没有锁开销）
    • 数据一致性最差
  • 适用场景：统计类查询，对准确性要求不高但需要高性能的场景

2. 读已提交 (Read Committed)

  • 定义：事务只能读取其他事务已提交的修改
  • 实现方式：
    • 锁机制：读操作获取共享锁，语句执行完立即释放
    • MVCC：每个语句看到的是语句开始时的已提交快照
  • 特点：
    • 防止了脏读
    • 可能出现不可重复读和幻读
  • 适用场景：大多数数据库的默认隔离级别（如Oracle、PostgreSQL）

3. 可重复读 (Repeatable Read)

  • 定义：事务在整个过程中看到的数据与事务开始时一致
  • 实现方式：
    • 锁机制：读锁保持到事务结束
    • MVCC：整个事务看到事务开始时的已提交快照
  • 特点：
    • 防止了脏读和不可重复读
    • 可能出现幻读（但MySQL InnoDB通过间隙锁防止了幻读）
  • 适用场景：需要同一事务内多次读取结果一致的场景

4. 可串行化 (Serializable)

  • 定义：事务串行执行，完全隔离
  • 实现方式：
    • 锁机制：严格的锁协议（如范围锁）
    • MVCC：通过冲突检测实现串行化（如SSI）
  • 特点：
    • 防止所有并发问题
    • 性能最差（高锁等待）
  • 适用场景：金融交易等对数据一致性要求极高的场景

二、隔离级别解决的并发问题

1. 脏读 (Dirty Read)

  • 定义：读取到其他事务未提交的数据
  • 可能引发的问题：基于无效数据做出错误决策
  • 解决级别：读已提交及以上级别可防止

示例：

-- 事务A
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;  -- 未提交-- 事务B（读未提交级别）
BEGIN;
SELECT balance FROM accounts WHERE id = 1;  -- 读到A未提交的修改
-- 如果A回滚，B读到的就是无效数据

2. 不可重复读 (Non-repeatable Read)

  • 定义：同一事务内两次读取同一数据，结果不同
  • 可能引发的问题：事务内逻辑判断不一致
  • 解决级别：可重复读及以上级别可防止

示例：

-- 事务A
BEGIN;
SELECT balance FROM accounts WHERE id = 1;  -- 第一次读，返回1000-- 事务B
BEGIN;
UPDATE accounts SET balance = 900 WHERE id = 1;
COMMIT;-- 事务A
SELECT balance FROM accounts WHERE id = 1;  -- 第二次读，返回900
-- 同一事务内两次读取结果不同

3. 幻读 (Phantom Read)

  • 定义：同一事务内两次相同查询返回不同的行集合
  • 可能引发的问题：新增或删除的行影响事务逻辑
  • 解决级别：可串行化级别可完全防止（MySQL RR级别也防止）

示例：

-- 事务A
BEGIN;
SELECT * FROM accounts WHERE balance < 1000;  -- 返回id为1,2的两条记录-- 事务B
BEGIN;
INSERT INTO accounts(id, balance) VALUES(3, 800);
COMMIT;-- 事务A
SELECT * FROM accounts WHERE balance < 1000;  -- 返回id为1,2,3的三条记录
-- 多出了一条"幻影"记录

三、不同隔离级别的实现对比

锁机制实现

隔离级别读锁保持时间写锁保持时间防止问题
读未提交不获取或立即释放事务结束无
读已提交语句结束事务结束脏读
可重复读事务结束事务结束脏读、不可重复读
可串行化事务结束+范围锁事务结束脏读、不可重复读、幻读

MVCC实现

隔离级别快照时间点防止问题
读未提交读取最新版本无
读已提交语句开始时脏读
可重复读事务开始时脏读、不可重复读
可串行化事务开始时+冲突检测所有问题

四、MySQL InnoDB的特殊实现

MySQL的InnoDB引擎在可重复读(RR)级别下通过以下机制也防止了幻读：

  1. Next-Key Locking：结合记录锁和间隙锁

    • 记录锁：锁定索引记录
    • 间隙锁：锁定索引记录之间的间隙
    • 防止其他事务在锁定范围内插入新记录

  2. 示例：

-- 事务A（RR级别）
BEGIN;
SELECT * FROM accounts WHERE balance BETWEEN 800 AND 1000 FOR UPDATE;
-- 不仅锁定了balance=800和1000的记录，还锁定了800-1000之间的间隙-- 事务B
BEGIN;
INSERT INTO accounts(id, balance) VALUES(3, 900);  -- 会被阻塞

五、隔离级别选择建议

  1. 优先考虑读已提交：

    • 大多数应用的平衡选择
    • 良好的性能与适中的一致性保证

  2. 需要可重复读时：

    • 报表生成等需要一致性快照的场景
    • 金融系统中需要多次读取相同数据的操作

  3. 谨慎使用可串行化：

    • 仅用于对一致性要求极高的场景
    • 注意可能导致的性能问题和死锁

  4. 避免使用读未提交：

    • 除非明确知道风险且能接受不一致数据

六、实际案例分析

电商库存管理场景

问题场景：

  • 商品库存：100件
  • 用户A和用户B同时下单购买最后一件商品

不同隔离级别下的表现：

  1. 读未提交：

    -- 事务A
BEGIN;
SELECT stock FROM products WHERE id = 1;  -- 看到100
UPDATE products SET stock = stock - 1 WHERE id = 1;-- 事务B（同时执行）
BEGIN;
SELECT stock FROM products WHERE id = 1;  -- 可能看到A未提交的99
UPDATE products SET stock = stock - 1 WHERE id = 1;  -- 最终库存98，超卖

  2. 读已提交：

    -- 事务A
BEGIN;
SELECT stock FROM products WHERE id = 1;  -- 看到100
UPDATE products SET stock = stock - 1 WHERE id = 1;-- 事务B
BEGIN;
SELECT stock FROM products WHERE id = 1;  -- 看到100（A未提交）
UPDATE products SET stock = stock - 1 WHERE id = 1;  -- 等待A提交
-- 最终库存99，仍可能超卖

  3. 可重复读（带FOR UPDATE）：

    -- 事务A
BEGIN;
SELECT stock FROM products WHERE id = 1 FOR UPDATE;  -- 加排他锁
UPDATE products SET stock = stock - 1 WHERE id = 1;-- 事务B
BEGIN;
SELECT stock FROM products WHERE id = 1 FOR UPDATE;  -- 等待A释放锁
-- 最终库存99，不会超卖

  4. 可串行化：

    -- 自动序列化执行，性能差但保证安全

最佳实践：

-- 使用RR隔离级别+悲观锁
BEGIN;
SELECT stock FROM products WHERE id = 1 FOR UPDATE;
-- 业务逻辑检查
IF stock >= 1 THENUPDATE products SET stock = stock - 1 WHERE id = 1;-- 创建订单
END IF;
COMMIT;

七、总结

理解事务隔离级别需要掌握：

  1. 四种标准隔离级别及其特点
  2. 三种主要并发问题（脏读、不可重复读、幻读）
  3. 不同数据库的具体实现差异
  4. 根据业务需求选择合适的隔离级别

实际应用中，通常：

  • 默认使用读已提交
  • 需要更高一致性时使用可重复读+适当的锁机制
  • 极少情况下使用可串行化

不可重复读与幻读的区别详解

不可重复读(Non-repeatable Read)和幻读(Phantom Read)确实都是指在同一个事务内两次查询结果不一致的现象，但它们的本质区别在于不一致的类型和范围。理解这两种现象的差异对于正确选择事务隔离级别和设计并发控制策略至关重要。

核心区别对比表

对比维度不可重复读 (Non-repeatable Read)幻读 (Phantom Read)
操作对象同一行数据的值发生变化结果集的行数发生变化
数据变化已存在行的数据被更新新增或删除了满足条件的行
锁定范围行级锁即可防止需要范围锁或间隙锁
问题本质数据值的不可重复性数据集合的不可重复性
典型SQLUPDATE操作导致INSERT/DELETE操作导致
解决级别可重复读(Repeatable Read)及以上可串行化(Serializable)

深入解析区别

1. 操作对象不同

不可重复读：

  • 针对的是同一行数据的内容变化
  • 例如：事务内两次读取id=1的用户余额，结果不同（1000→900）

幻读：

  • 针对的是结果集的行数变化
  • 例如：事务内两次执行WHERE age>30的查询，第一次返回2行，第二次返回3行

2. 引发操作不同

不可重复读由UPDATE操作引起：

-- 事务A
SELECT balance FROM accounts WHERE id = 1; -- 返回1000-- 事务B
UPDATE accounts SET balance = 900 WHERE id = 1;-- 事务A
SELECT balance FROM accounts WHERE id = 1; -- 返回900（不可重复读）

幻读由INSERT/DELETE操作引起：

-- 事务A
SELECT * FROM accounts WHERE balance > 800; -- 返回id为1,2的两行-- 事务B
INSERT INTO accounts(id, balance) VALUES(3, 900);-- 事务A
SELECT * FROM accounts WHERE balance > 800; -- 返回id为1,2,3的三行（幻读）

3. 锁定机制需求不同

防止不可重复读：

  • 只需要锁定已存在的行
  • 例如：共享锁(S锁)保持到事务结束

防止幻读：

  • 需要锁定可能满足条件的范围
  • 例如：间隙锁(Gap Lock)锁定值区间
  • MySQL的Next-Key Lock(记录锁+间隙锁)就是为此设计

4. 实际案例对比

银行账户系统案例

不可重复读场景：

  1. 对账单生成事务查询账户余额：
    -- 事务A（上午9:00开始）
SELECT balance FROM accounts WHERE id = 1001; -- 余额5000
  2. 同时有转账事务修改余额：
    -- 事务B（9:01执行）
UPDATE accounts SET balance = 4000 WHERE id = 1001;
COMMIT;
  3. 对账单事务再次查询：
    -- 事务A（9:02再次查询）
SELECT balance FROM accounts WHERE id = 1001; -- 余额4000
-- 同一行数据值变化，不可重复读

幻读场景：

  1. 信贷审批事务查询负债账户：
    -- 事务A
SELECT COUNT(*) FROM accounts WHERE balance < 0; -- 返回3个负债账户
  2. 同时有开户事务创建新负债账户：
    -- 事务B
INSERT INTO accounts(id, balance) VALUES(1004, -500);
COMMIT;
  3. 信贷事务基于查询结果决定总额度：
    -- 事务A
SELECT COUNT(*) FROM accounts WHERE balance < 0; -- 现在返回4个
-- 结果集行数变化，幻读

5. 技术实现差异

可重复读隔离级别下：

  • 可以防止不可重复读（通过行锁或MVCC保持行值不变）
  • 但可能无法防止幻读（除非像MySQL那样实现间隙锁）

可串行化隔离级别：

  • 通过严格的锁协议防止所有并发问题
  • 包括：
    • 谓词锁（锁定查询条件涉及的范围）
    • 索引范围锁
    • 全表扫描时的表级锁

6. 对应用的影响

不可重复读的影响：

  • 导致事务内基于同一数据的逻辑判断不一致
  • 例如：基于第一次查询结果做计算，但第二次查询值已变

幻读的影响：

  • 导致事务对数据集合的整体认知错误
  • 例如：统计计数、存在性检查等操作不可靠
  • 更隐蔽但可能影响更大

特殊注意事项

  1. MySQL的独特实现：

    • InnoDB在RR级别通过Next-Key Locking也防止了幻读
    • 这与SQL标准不同（标准中RR允许幻读）

  2. MVCC下的表现：

    • 使用多版本并发控制时：
      • 不可重复读：读取事务开始时的行版本
      • 幻读：快照中看不到新插入的行

  3. 业务层面的区别：

    • 不可重复读影响"数据准确性"
    • 幻读影响"数据完整性"

如何选择解决方案

防止不可重复读

  1. 使用可重复读隔离级别
  2. 对关键查询添加FOR UPDATE（悲观锁）
  3. 使用乐观锁（版本号控制）

防止幻读

  1. 使用可串行化隔离级别（性能代价高）
  2. 在RR级别下使用适当的锁：
    SELECT * FROM table WHERE condition FOR UPDATE; -- MySQL会加间隙锁
  3. 应用层校验（如二次确认）

总结记忆技巧

  • “不可重复读”：记住"值变了"（同一行的值不可重复）
  • “幻读”：记住"行变了"（像幻觉一样多出/少了行）
  • 简单说：
    • 不可重复读 = 行内数据不一致
    • 幻读 = 结果集行数不一致

理解这两种现象的差异，能帮助您更精准地选择事务隔离级别和设计并发控制策略，在保证数据一致性的同时获得最佳性能。

事务传播行为

一、事务传播行为核心概念

事务传播行为定义了在多个事务方法相互调用时，事务如何传播的规则。Spring框架提供了7种传播行为，每种行为对应不同的应用场景：

传播行为类型说明适用场景
REQUIRED默认值。当前有事务则加入，没有则创建新事务大多数业务场景
SUPPORTS当前有事务则加入，没有则以非事务方式执行查询操作，可接受非事务执行
MANDATORY当前必须有事务，否则抛出异常强制要求调用方提供事务环境
REQUIRES_NEW总是创建新事务，暂停当前事务（如果存在）独立子操作（如审计日志）
NOT_SUPPORTED以非事务方式执行，暂停当前事务（如果存在）不要求事务的批量操作
NEVER以非事务方式执行，如果当前存在事务则抛出异常强制要求非事务环境
NESTED如果当前存在事务，则在嵌套事务内执行（可部分回滚）；否则同REQUIRED复杂业务流程中的可回滚子操作

二、传播行为与线程安全深度解析

1. 线程安全的核心挑战

事务资源绑定机制：

  • Spring使用TransactionSynchronizationManager管理事务资源
  • 基于ThreadLocal存储当前线程的事务上下文
  • 每个线程有独立的事务状态和数据库连接
// Spring事务资源管理核心逻辑
public abstract class TransactionSynchronizationManager {private static final ThreadLocal<Map<Object, Object>> resources = new NamedThreadLocal<>("Transactional resources");private static final ThreadLocal<Set<TransactionSynchronization>> synchronizations =new NamedThreadLocal<>("Transaction synchronizations");private static final ThreadLocal<String> currentTransactionName =new NamedThreadLocal<>("Current transaction name");// ... 其他状态管理
}

2. REQUIRED 传播行为

典型场景：

@Service
public class OrderService {@Transactional(propagation = Propagation.REQUIRED)public void createOrder(Order order) {// 操作1：保存订单orderRepository.save(order);// 操作2：更新库存inventoryService.updateStock(order.getItems());}
}@Service
public class InventoryService {@Transactional(propagation = Propagation.REQUIRED)public void updateStock(List<Item> items) {// 库存更新逻辑}
}

线程安全分析：

  1. 同一线程内共享同一个事务上下文
  2. 共用同一个数据库连接
  3. 所有操作在同一个物理事务中提交或回滚
  4. 安全：天然线程封闭，无并发问题

3. REQUIRES_NEW 传播行为

典型场景（审计日志）：

@Service
public class PaymentService {@Transactional(propagation = Propagation.REQUIRED)public void processPayment(Payment payment) {// 支付处理逻辑paymentRepository.save(payment);// 审计日志（独立事务）auditService.logAction("PAYMENT_PROCESSED", payment.getId());}
}@Service
public class AuditService {@Transactional(propagation = Propagation.REQUIRES_NEW)public void logAction(String action, Long entityId) {// 审计日志记录}
}

线程安全风险点：

// 错误示例：跨线程使用事务
@Transactional
public void parentMethod() {new Thread(() -> {// 子线程尝试使用事务childMethod(); }).start();
}@Transactional(propagation = Propagation.REQUIRES_NEW)
public void childMethod() {// 实际执行：// 1. 新线程无事务上下文// 2. 创建新连接执行（非预期行为）
}

风险分析：

  1. 子线程无法继承父线程的事务上下文
  2. 每个线程创建独立数据库连接
  3. 可能导致：
    • 连接泄露
    • 事务不完整
    • 数据不一致

4. NESTED 传播行为

实现机制：

  • 使用数据库保存点（SAVEPOINT）实现
  • 可部分回滚嵌套事务内的操作
  • 外层事务提交时统一提交
@Transactional
public void complexBusinessProcess() {// 步骤1：核心操作coreOperation();try {// 步骤2：嵌套事务操作nestedOperation();} catch (BusinessException e) {// 仅回滚嵌套操作，不影响核心操作}// 步骤3：后续操作
}@Transactional(propagation = Propagation.NESTED)
public void nestedOperation() {// 嵌套事务逻辑
}

线程安全注意事项：

  1. 必须在同一线程内执行
  2. 依赖JDBC 3.0+的保存点功能
  3. 不支持所有数据库（如MySQL的MyISAM引擎不支持）

三、多线程场景下的安全实践

1. 正确模式：异步任务+独立事务

@Service
public class ReportService {@Async // Spring异步执行@Transactional(propagation = Propagation.REQUIRES_NEW)public void generateReportAsync(Long reportId) {// 生成复杂报表（独立事务）}
}@RestController
public class ReportController {@PostMapping("/reports")public ResponseEntity<?> requestReport() {reportService.generateReportAsync(reportId);return ResponseEntity.accepted().build();}
}

配置要求：

@Configuration
@EnableAsync
public class AsyncConfig implements AsyncConfigurer {@Overridepublic Executor getAsyncExecutor() {ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();executor.setCorePoolSize(5);executor.setMaxPoolSize(10);executor.setQueueCapacity(25);executor.initialize();return executor;}
}

2. 线程池事务管理要点

  1. 连接泄露预防：

    @Bean
public DataSource dataSource() {HikariDataSource ds = new HikariDataSource();ds.setMaximumPoolSize(20); // 匹配线程池大小ds.setLeakDetectionThreshold(30000); // 泄漏检测return ds;
}

  2. 事务超时控制：

    @Transactional(propagation = Propagation.REQUIRES_NEW,timeout = 30 // 秒
)
public void timeSensitiveOperation() {// ...
}

3. 分布式事务场景

跨服务调用模式：

ClientServiceAServiceB开启事务调用（携带事务ID）执行结果提交/回滚ClientServiceAServiceB

实现方案选择：

  • Seata：AT/TCC模式
  • Spring Cloud：支持XA协议的事务管理器
  • Saga模式：补偿事务实现最终一致性

四、并发问题深度防御策略

1. 隔离级别与传播行为组合

场景推荐组合说明
金融交易REQUIRED + SERIALIZABLE最高隔离级别
报表生成REQUIRES_NEW + READ_COMMITTED独立事务+中等隔离
批量处理NOT_SUPPORTED + READ_UNCOMMITTED非事务+最低隔离
微服务调用NESTED + REPEATABLE_READ部分回滚+重复读

2. 悲观锁与乐观锁选择

悲观锁实现：

@Transactional
public void updateWithPessimisticLock(Long id) {Entity entity = entityRepository.findById(id, LockModeType.PESSIMISTIC_WRITE);// 业务处理entityRepository.save(entity);
}

乐观锁实现：

@Entity
public class Account {@Idprivate Long id;@Versionprivate Integer version;// ...
}@Transactional
public void updateWithOptimisticLock(Account account) {// 自动校验版本号accountRepository.save(account);
}

3. 死锁预防策略

  1. 访问顺序：统一资源访问顺序
  2. 超时机制：
    @Transactional(timeout = 10)
public void quickOperation() {...}
  3. 死锁检测：数据库级（InnoDB）或应用级检测

五、最佳实践总结

  1. 传播行为选择原则：

    • 80%场景使用REQUIRED
    • 独立操作使用REQUIRES_NEW
    • 复杂业务流程考虑NESTED

  2. 线程安全黄金法则：

    一个事务 = 一个线程 = 一个连接

  3. 多线程事务规范：

    • 使用@Async+REQUIRES_NEW
    • 配置合适线程池大小
    • 添加事务超时设置
    • 避免跨线程共享事务状态

  4. 事务设计注意事项：

    • 保持事务短小精悍
    • 避免事务中远程调用
    • 合理设置隔离级别
    • 重要操作添加重试机制

  5. 事务监控指标：

    • 事务平均执行时间
    • 事务失败率
    • 事务回滚率
    • 线程池活跃度

通过合理选择事务传播行为并遵循线程安全实践，可以在保证数据一致性的同时，构建高性能、高可用的并发应用系统。

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

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

相关文章

不同地区的主要搜索引擎工具

不同地区的主要搜索引擎工具

研究seo&#xff0c;想汇总一下不同国家的搜索引擎工具&#xff0c;顺带了解一下这些公司提供的服务。 韩国&#xff1a;NAVER——>LINE 日本: 我还不知道&#xff0c;如果你知道可以评论告诉我 俄罗斯&#xff1a;yandex yandex有点像本土化的google 搜索引擎 邮箱 网盘 在…
阅读更多...
实操：AWS CloudFront的动态图像转换

实操：AWS CloudFront的动态图像转换

概述 适用于 Amazon CloudFront 的动态图像转换&#xff08;前身为无服务器图像处理器&#xff09;&#xff0c;通过 Amazon CloudFront 的全球内容分发网络&#xff08;CDN&#xff09;实现实时图像处理。此 AWS 解决方案可帮助您优化视觉内容交付&#xff0c;同时显著降低运营…
阅读更多...
Spring Boot 实战详解：从静态资源到 Thymeleaf 模板引擎

Spring Boot 实战详解：从静态资源到 Thymeleaf 模板引擎

Spring Boot 凭借其 "约定大于配置" 的理念&#xff0c;极大简化了 Java 应用开发流程。本文将从 Spring Boot 核心特性出发&#xff0c;详细解析静态资源映射规则、Thymeleaf 模板引擎的使用&#xff0c;并结合完整实战案例&#xff0c;帮助开发者快速上手 Spring B…
阅读更多...
docker的镜像与推送

docker的镜像与推送

docker build# 1. 基本构建命令&#xff08;使用当前目录的 Dockerfile&#xff09; docker build .# 2. 指定 Dockerfile 路径和构建上下文 docker build -f /path/to/Dockerfile /path/to/build/context# 3. 为镜像设置名称和标签 docker build -t my-image:latest .# 4. 设置…
阅读更多...
计算机网络学习----域名解析

计算机网络学习----域名解析

在互联网世界中&#xff0c;我们习惯通过域名&#xff08;如www.example.com&#xff09;访问网站&#xff0c;而非直接记忆复杂的 IP 地址&#xff08;如 192.168.1.1&#xff09;。域名与 IP 地址之间的转换过程&#xff0c;就是域名解析。它是互联网通信的基础环节&#xff…
阅读更多...
构建高性能推荐系统：MixerService架构解析与核心实现

构建高性能推荐系统：MixerService架构解析与核心实现

——深入剖析推荐服务的分层设计、工作流引擎与高可用策略 一、整体架构与分层设计 该推荐服务采用经典分层架构模式​7&#xff0c;各层职责清晰&#xff1a; ​HTTP接口层​ 支持 GET/POST 请求解析&#xff0c;自动映射参数到 RcmdReq 协议对象统一错误处理&#xff1a;参…
阅读更多...
【安全漏洞】隐藏服务器指纹：Nginx隐藏版本号配置修改与重启全攻略

【安全漏洞】隐藏服务器指纹：Nginx隐藏版本号配置修改与重启全攻略

🚀 隐藏服务器指纹：Nginx配置修改与重启全攻略 你是否知道，默认情况下Nginx会在HTTP响应头中暴露版本号？这个看似无害的Server: nginx/1.x.x字段，实则可能成为黑客的"藏宝图"。今天我们就来揭秘如何通过简单配置提升服务器安全性，并手把手教你完成Windows环境…
阅读更多...
构建RAG智能体(2)：运行状态链

构建RAG智能体(2)：运行状态链

在现代AI应用开发中&#xff0c;如何让聊天机器人具备记忆能力和上下文理解是一个核心挑战。传统的无状态对话系统往往无法处理复杂的多轮对话场景&#xff0c;特别是当用户需要提供多种信息来完成特定任务时。 本文就来讨论一下如何利用runnable来编排更有趣的语言模型系统&a…
阅读更多...
RPA认证考试全攻略：如何高效通过uipath、实在智能等厂商考试

RPA认证考试全攻略：如何高效通过uipath、实在智能等厂商考试

rpa认证考试有什么作用&#xff1f;数字洪流席卷全球&#xff0c;企业效率之争已进入秒级战场。当重复性工作吞噬着创造力&#xff0c;RPA&#xff08;机器人流程自动化&#xff09;技术正以前所未有的速度重塑职场生态。财务对账、报表生成、跨系统数据搬运……这些曾经耗费人…
阅读更多...
浅析MySQL事务隔离级别

浅析MySQL事务隔离级别

MySQL 的事务隔离级别定义了多个并发事务在访问和修改相同数据时&#xff0c;彼此之间的可见性和影响程度。它解决了并发事务可能引发的三类核心问题&#xff1a; 脏读&#xff1a; 一个事务读取了另一个未提交事务修改的数据。不可重复读&#xff1a; 一个事务内多次读取同一行…
阅读更多...
【Linux系统】基础IO（上）

【Linux系统】基础IO（上）

1. 深入理解"文件"概念1.1 文件的狭义理解狭义上的“文件”主要指存储在磁盘上的数据集合。具体包括&#xff1a;文件在磁盘里&#xff1a;文件是磁盘上以特定结构&#xff08;如FAT、ext4文件系统&#xff09;保存的数据集合&#xff0c;由字节或字符序列构成。磁盘…
阅读更多...
构建智能可视化分析系统：RTSP|RTMP播放器与AI行为识别的融合实践

构建智能可视化分析系统：RTSP|RTMP播放器与AI行为识别的融合实践

技术背景 随着人工智能向边缘侧、实时化方向加速演进&#xff0c;视频已从传统的“记录媒介”跃升为支撑智能感知与自动决策的关键数据入口。在安防监控、工业安全、交通治理等复杂应用场景中&#xff0c;行为识别系统的准确性和响应效率&#xff0c;越来越依赖于视频源的时效…
阅读更多...
AI入门学习-Python 最主流的机器学习库Scikit-learn

AI入门学习-Python 最主流的机器学习库Scikit-learn

一、Scikit-learn 核心定位是什么&#xff1a;Python 最主流的机器学习库&#xff0c;涵盖从数据预处理到模型评估的全流程。 为什么测试工程师必学&#xff1a;✅ 80% 的测试机器学习问题可用它解决✅ 无需深厚数学基础&#xff0c;API 设计极简✅ 与 Pandas/Numpy 无缝集成&a…
阅读更多...
apache-doris安装兼datax-web配置

apache-doris安装兼datax-web配置

Doris安装 官方快速开始链接 下载2.1.10&#xff0c;解压。我这边个人服务器CPU是J1900&#xff0c;是没有 avx2的&#xff0c;所以选no 配置JAVA_HOME&#xff0c;这里没有配置的要配置下&#xff0c;注意要Oracle的jdk&#xff0c;openjdk没有jps等工具集&#xff0c;后面跑…
阅读更多...
问题实例：4G网络下语音呼叫失败

问题实例：4G网络下语音呼叫失败

问题描述 测试机 拨号呼出后&#xff0c;一直在4G&#xff0c;超时后自动挂断。 对比机可以呼出成功&#xff0c;呼出时回落3G。 日志分析 测试机和对比机一样发起了CSFB 呼叫。 只是测试机后面没有回落3G。 03:44:40.373264 [0xB0ED] LTE NAS EMM Plain OTA Outgoing Message …
阅读更多...
MATLAB 2024b深度学习新特性全面解析与DeepSeek大模型集成开发技术

MATLAB 2024b深度学习新特性全面解析与DeepSeek大模型集成开发技术

随着人工智能技术向多学科交叉融合与工程实践领域纵深发展&#xff0c;MATLAB 2024b深度学习工具箱通过架构创新与功能强化&#xff0c;为科研创新和行业应用提供了全栈式解决方案。基于该版本工具链的三大革新方向展开&#xff1a;一是构建覆盖经典模型与前沿架构的体系化&…
阅读更多...
Springboot美食分享平台

Springboot美食分享平台

一、 绪论 1.1 研究意义 当今社会作为一个飞速的发展社会&#xff0c;网络已经完全渗入人们的生活&#xff0c; 网络信息已成为传播的第一大媒介&#xff0c; 可以毫不夸张说网络资源获取已逐步改变了人们以前的生活方式&#xff0c;网络已成为人们日常&#xff0c;休闲主要工…
阅读更多...
微信小程序——世界天气小助手

微信小程序——世界天气小助手

哈喽&#xff0c;大家好&#xff01; 最近小编开发了一个简单的微信小程序——世界天气小助手&#xff0c;希望大家喜欢。 No.1: 为大家介绍下开发者工具下的页面结构。一共有三个界面{主页、搜索页、详情页}No.2&#xff1a; 具体页面展示&#xff1a;当前页面是主页&…
阅读更多...
基于单片机的智能家居安防系统设计

基于单片机的智能家居安防系统设计

摘 要 为了应对目前人们提出的对生活越来越智能的要求&#xff0c;在提高生活品质的同时降低意外事件发生对用户造成的经济损失或其他损失。针对日常生活中经常发生的火灾&#xff0c;失窃&#xff0c;电力资源浪费等生活问题&#xff0c;本设计正是在这种需求背景下展开研究…
阅读更多...
腾讯研究院 | AI 浪潮中的中国品牌优势解码：华为、小米、大疆、科大讯飞等品牌从技术破壁到生态领跑的全维突围

腾讯研究院 | AI 浪潮中的中国品牌优势解码：华为、小米、大疆、科大讯飞等品牌从技术破壁到生态领跑的全维突围

当 DeepSeek-R1 模型在 2025 年掀起大众 AI 热潮&#xff0c;当腾讯混元大模型与京东言犀大模型在产业场景中落地生根&#xff0c;中国品牌正在 AI 技术革命的浪潮中完成从追随者到引领者的蜕变。腾讯营销洞察&#xff08;TMI&#xff09;联合京东消费及产业研究院、腾讯研究院…
阅读更多...
最新文章

Copyright @ 2022~2023