事務隔離級別和傳播方式

事務隔離級別

事務隔離級別是數據庫系統中控制事務間相互影響程度的重要機制。不同的隔離級別在數據一致性保證和系統性能之間提供不同的權衡選擇。下面我將詳細解析四種標準隔離級別、它們能解決的問題以及可能存在的并發問題。

一、四種標準隔離級別

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