詳談 MySQL 8.0 原子 DDL 原理

来源:https://www.cnblogs.com/radondb/archive/2022/09/13/16688994.html
-Advertisement-
Play Games

柯煜昌 青雲科技研發顧問級工程師 目前從事 RadonDB 容器化研發，華中科技大學研究生畢業，有多年的資料庫內核開發經驗。 文章字數 3800+，閱讀時間 15 分鐘 背景 MySQL 5.7 的字典信息保存在非事務表中，並且存放在不同的文件中（.FRM，.PAR，.OPT，.TRN，.TRG 等 ...


柯煜昌 青雲科技研發顧問級工程師 目前從事 RadonDB 容器化研發，華中科技大學研究生畢業，有多年的資料庫內核開發經驗。

文章字數 3800+，閱讀時間 15 分鐘

背景

MySQL 5.7 的字典信息保存在非事務表中，並且存放在不同的文件中（.FRM，.PAR，.OPT，.TRN，.TRG 等)。所有 DDL 操作都不是 Crash Safe，而且對於組合 DDL（ALTER 多個表）會出現有的成功有的失敗的情況，而不是總體失敗。這樣主從複製就出現了問題，也導致基於複製的高可用系統不再安全。

MySQL 8.0 推出新特性 - 原子 DDL，解決了以上的問題。

什麼是原子 DDL？

DDL 是指數據定義語言（Data Definition Language），負責數據結構的定義與數據對象的定義。原子 DDL 是指一個 DDL 操作是不可分割的，要麼全成功要麼全失敗。

有哪些限制？

MySQL 8.0 只有 InnoDB 存儲引擎支持原子 DDL。

支持語句：資料庫、表空間、表、索引的 CREATE、ALTER 以及 DROP 語句，以及 TRUNCATE TABLE 語句。

MySQL 8.0 系統表均以 InnoDB 存儲引擎存儲，涉及到字典對象的均支持原子 DDL。

支持的語句：存儲過程、觸發器、視圖以及用戶定義函數（UDF）的 CREATE 和 DROP 、ALTER 操作，用戶和角色的 CREATE、ALTER、DROP 語句，以及適用的 RENAME 語句，以及 GRANT 和 REVOKE 語句。

不支持的語句：

  • INSTALL PLUGIN、UNINSTALL PLUGIN
  • INSTALL COMPONENT、UNINSTALL COMPONENT
  • REATE SERVER、ALTER SERVER、DROP SERVER

實現原理是什麼？

首先，8.0 將字典信息存放到事務引擎的系統表（InnoDB 存儲引擎）中。這樣 DDL 操作轉變成一組對系統表的 DML 操作，從而失敗後可以依據事務引擎自身的事務回滾保證系統表的原子性。

似乎 DDL 原子性就此就可以完成，但實際上並沒有這麼簡單。首先字典信息不光是系統表，還有一組字典緩存，如：

  • Table Share 緩存
  • DD 緩存
  • InnoDB 中的 dict

此外，字典信息只是資料庫對象的元數據，DDL 操作不光要修改字典信息，還要實實在在的操作對象，以及對象本身在記憶體中緩存。

  • 表空間
  • Dynamic meta
  • Btree
  • ibd 文件
  • buffer pool 中表空間的 page 頁

此外，binlog 也要考慮 DDL 失敗的情況。

因此，原子 DDL 在處理 DDL 失敗的時候，不光是直接回滾系統表的數據，而且也要保證記憶體緩存，資料庫對象也能回滾到一致狀態。

實現細節

為瞭解決 DDL 失敗情況中資料庫對象的回滾，8.0 引入了系統表 DDL_LOG。該表在 mysql 庫中。不可見，也不能人為操作。如果想瞭解該表的結果，先編譯一個 debug 版的 MySQL：

SET SESSION debug='+d,skip_dd_table_access_check';
show create table  mysql.innodb_ddl_log;

可以看到如下表結構：

CREATE TABLE `innodb_ddl_log` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `thread_id` bigint unsigned NOT NULL,
  `type` int unsigned NOT NULL,
  `space_id` int unsigned DEFAULT NULL,
  `page_no` int unsigned DEFAULT NULL,
  `index_id` bigint unsigned DEFAULT NULL,
  `table_id` bigint unsigned DEFAULT NULL,
  `old_file_path` varchar(512) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  `new_file_path` varchar(512) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `thread_id` (`thread_id`)
) /*!50100 TABLESPACE `mysql` */ ENGINE=InnoDB AUTO_INCREMENT=48 DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0 ROW_FORMAT=DYNAMIC

在 8.0 中，這個表需要滿足兩個場景以及兩個任務：

  • 場景 1: 符合 DDL 失敗的場景，需要回滾部分完成的 DDL。

  • 場景 2：DDL 進行中，發生故障（掉電、軟硬體故障等），重啟機器需要完成部分 DDL。

兩個任務：

  • 任務 1：失敗後回滾，執行反向操作。

  • 任務 2：如果成功，則執行清理工作。

也許有人會問，為什麼執行成功需要執行清理工作呢？

之所以要執行清理工作，因為 ibd 文件和索引一旦刪除就不能恢復。為了實現回滾，DDL 刪除這些對象時候，並不是真正刪除，而是先將它們備份一下，以備回滾時使用。所以只有確認 DDL 已經執行成功，這些備份對象不需要了，才執行清理工作。

舉個例子

為了將這個原理將清楚，我們流程相對簡單的 CREATE TABLE 講起，管中窺豹，可見一斑。假設已經有編譯好了 8.0 debug 版本，並且 innodb_file_per_table 為 on，先執行以下命令：

mysql> set global log_error_verbosity=3;
Query OK, 0 rows affected (0.00 sec)

mysql> set global innodb_print_ddl_logs = on;
Query OK, 0 rows affected (0.00 sec)

從而開啟了ddl log的日誌，然後創建表：

mysql> create table t2 (a int);
Query OK, 0 rows affected (25 min 26.42 sec)

可以看到如下日誌：

XXXXX 8 [Note] [MY-012473] [InnoDB] DDL log insert : [DDL record: DELETE SPACE, id=20, thread_id=8, space_id=6, old_file_path=./test/t2.ibd]
XXXXX 8 [Note] [MY-012478] [InnoDB] DDL log delete : 20
XXXXX 8 [Note] [MY-012477] [InnoDB] DDL log insert : [DDL record: REMOVE CACHE, id=21, thread_id=8, table_id=1067, new_file_path=test/t2]
XXXXX 8 [Note] [MY-012478] [InnoDB] DDL log delete : 21
XXXXX 8 [Note] [MY-012472] [InnoDB] DDL log insert : [DDL record: FREE, id=22, thread_id=8, space_id=6, index_id=157, page_no=4]
XXXXX 8 [Note] [MY-012478] [InnoDB] DDL log delete : 22
XXXXX 8 [Note] [MY-012485] [InnoDB] DDL log post ddl : begin for thread id : 8
XXXXX 8 [Note] [MY-012486] [InnoDB] DDL log post ddl : end for thread id : 8

create table 的 DDL 只有反向操作日誌記錄，而無清理操作日誌記錄。細心的讀者可能看到日誌中插入某條 DDL log，隨後又將其刪除，會心生疑惑。但這正是 MySQL 原子 DDL 的秘密所在。我們選 DELETE SPACE 這個 DDL 日誌寫入函數Log_DDL::write_delete_space_log 來揭秘這個過程。

dberr_t Log_DDL::write_delete_space_log(trx_t *trx, const dict_table_t *table,

space_id_t space_id,

const char *file_path, bool is_drop,

bool dict_locked) {

ut_ad(trx == thd_to_trx(current_thd));

ut_ad(table == nullptr || dict_table_is_file_per_table(table));


if (skip(table, trx->mysql_thd)) {

return (DB_SUCCESS);

}


uint64_t id = next_id();

ulint thread_id = thd_get_thread_id(trx->mysql_thd);

dberr_t err;


trx->ddl_operation = true;


DBUG_INJECT_CRASH("ddl_log_crash_before_delete_space_log",

crash_before_delete_space_log_counter++);



if (is_drop) { //（1）

err = insert_delete_space_log(trx, id, thread_id, space_id, file_path,

dict_locked);

if (err != DB_SUCCESS) {

return err;

}


DBUG_INJECT_CRASH("ddl_log_crash_after_delete_space_log",

crash_after_delete_space_log_counter++);

} else { // （2）

err = insert_delete_space_log(nullptr, id, thread_id, space_id, file_path,

dict_locked);

if (err != DB_SUCCESS) {

return err;

}


DBUG_INJECT_CRASH("ddl_log_crash_after_delete_space_log",

crash_after_delete_space_log_counter++);


DBUG_EXECUTE_IF("DDL_Log_remove_inject_error_2",

srv_inject_too_many_concurrent_trxs = true;);


err = delete_by_id(trx, id, dict_locked); //（3）

ut_ad(err == DB_SUCCESS || err == DB_TOO_MANY_CONCURRENT_TRXS);


DBUG_EXECUTE_IF("DDL_Log_remove_inject_error_2",

srv_inject_too_many_concurrent_trxs = false;);


DBUG_INJECT_CRASH("ddl_log_crash_after_delete_space_delete",

crash_after_delete_space_delete_counter++);

}

return (err);

}

在create table 這個過程中調用write_delete_space_log，is_drop 為false，執行以上代碼執行分支 (2) 和 (3) 。註意的是 insert_delete_space_log 第一個參數為空，這意味著會在創建一個後臺事務（調用trx_allocate_for_background）插入DELETE_SPACE 記錄到innodb_ddl_log 表中，然後提交該事務。註意到(3) 處delete_by_id 第一個參數為trx , 這裡的trx 即本次 DDL 的事務，(3) 所做的動作是在本次事務中刪除(2)插入的記錄。

為什麼是這樣的邏輯呢？

file

以下分兩種情況來討論，如上圖所示：

  1. 如果插入 DDL log 之後，DDL 的各個步驟都成功執行，最後事務trx 成功提交，那麼 innodb_ddl_log 並沒有該 DDL 的記錄，因此在後續的post_ddl 中什麼也不做（post_ddl 在後面會描述）。
  2. 如果插入 DDL log 之後，DDL 的某個步驟失敗，則 DDL 所在的事務trx會回滾。此時，上圖中delete [DELETE SPACE, id=20]這個動作也會回滾。最後，innodb_ddl_log 中就會存在DELETE SPACE 這條記錄，後續執行post_ddl 進行 Replay（重演）， 從而刪除這次失敗的create table 的 DDL 已經創建的表空間。你可以發現，create table 的 DDL 創建表空間，就一定會以這樣的機制往innodb_ddl_log 中插入一條相反的動作DELETE SPACE的日誌記錄，所以也被稱為反向操作日誌。

其它 DDL log 記錄的操作如REMOVE CACHE 、FREE 日誌記錄的寫入也是類似的邏輯。複雜的 DDL，不光是會插入反向操作日誌記錄，也會插入清理操作日誌。比如TRUNCATE 表操作會將原有的表空間重命名為一個零時表空間，當 DDL 成功之後，需要通過post_ddl Replay DDL log 記錄，將臨時表空間刪除。如果失敗，又需要 post_ddl重演 DDL log，執行反向操作，將臨時表空間重命名為原來的表空間。總之，如果是反向操作日誌，則使用background trx 插入並提交，然後使用trx 刪除；如果是清理日誌，則使用trx 插入即可。

註意：innodb_ddl_log表與其他 InnoDB 表一樣，對該表所有操作 InnoDB 引擎都會產生 Redo 日誌與 Undo 記錄，所以不要將 DDL log 表中反向操作記錄看作 Undo log，這兩者不在同一個抽象層次上。而且反向操作在另一個事務中執行，而回滾時，Undo log 則是在原有同一個事務上執行。

需要探討的幾個問題

DDL 是否有必要日誌刷盤？

我們知道 MySQL 有一個 innodb_flush_log_at_trx_commit 參數，當設置為 0 時，提交時並不會立刻將 Redo log 刷入持久存儲中。雖然能提高性能，但在掉電或者停機時會有一定概率丟失已經提交的事務。對於 DML 操作來說，這樣僅僅是丟失事務，但對於 DDL 來說，丟失 DDL 的事務，就會導致資料庫元數據與其他數據不一致，以至資料庫系統無法正常工作。

所以，在trx_commit 會根據該事務是否為 DDL 操作，進行特殊處理：

無論innodb_flush_log_at_trx_commit參數如何設置，與 DDL 有關的事務，提交時必須日誌刷盤！

DDL log 的寫入時機

在理解了 DDL log 的機制之後，筆者問大家一個問題，對於create table 來說，是先執行write_delete_space_log 還是先創建表空間呢？

我們先假設是先創建表空間（A 動作），再寫反向操作日誌（B 動作）。如果 A 執行結束後出現掉的情況，此時 B 還未執行，此時create table 動作並沒有完成，而innodb_ddl_log 不存在DELETE SPACE 這樣的 DDL 反嚮日志記錄，資料庫崩潰恢復後，資料庫系統會將系統表數據回滾，但是 A 創建的表空間卻沒有刪除，由於存在中間狀態，此時create table 就不是原子DDL 了。

所以，在 DDL 中每個步驟中，先寫入該步驟的反向操作日誌記錄到innodb_ddl_log ，再執行該步驟。也就是說 DDL Log 寫入時機在執行步驟之前。如果create table 已經寫入了 DDL log， 但是沒有創建表空間就出現掉電情況呢？ 這並不要緊，在 post_ddl 做 Replay 的時候，會進行處理。

Replay 的調用邏輯

在 DDL 操作完成之後，無論 DDL 的事務提交還是回滾，都會調用post_ddl 函數，post_ddl 則會調用replay函數進行 Replay。此外，MySQL 8.0 資料庫崩潰恢復過程中，與 MySQL 5.7 相比，也多了ha_post_recover的過程，它會調用log_ddl->recover 將 innodb_ddl_log 所有的日誌記錄進行 Replay。

在post_ddl調用的是replay_by_thread_id，崩潰恢復中ha_post_recover 調用的是replay_all，其邏輯如下描述：

  1. 依據傳入的thread_id 為索引（thread_id 與trx 是可以一一對應的)，以逆序方式將所有記錄獲取出來，然後根據記錄的內容，依次執行 Replay 動作，最後刪除已經重演的記錄。
  2. replay_all 將innodb_ddl_log 所有記錄逆序方式獲取出來，依次執行 Replay 動作，最後刪除已經重演的記錄。

可以看到，以上兩個函數都有將記錄逆序的獲取的過程，為什麼要逆序呢？

逆函數

1、反向操作

我們如果將 DDL 中每個步驟看做一個函數，參數為資料庫系統。假設第 i 個步驟函數為oi，那麼n個步驟就是 n 個函數的複合函數：

file

也即，複合函數的逆時所有步驟逆函數的反向複合。所以反向操作需要將 DDL log 逆序進行處理。

2、清理操作

DDL 的清理動作往往沒有順序要求，逆向操作與正向操作效果往往是一樣的，所以統一進行逆序處理也沒有問題。

冪等性

與 Redo、Undo 類似，每個類型的日誌重演均要考慮其冪等性。

所謂冪等性，就是執行多次和執行一次的效果是一樣的。特別是在崩潰恢復的時候，在重演反向操作的時候，尚未完成時發生掉電故障，重新進行崩潰恢復。此時某項重演操作可能發生多次。

因此，MySQL 8.0 實現這些重演操作，必須要考慮冪等性。最典型是重演一些刪除操作，必須先判斷資料庫對象是否存在。如果存在，才進行刪除，否則什麼都不做。

Tips：說到這裡，筆者推薦一本書《具體數學：電腦科學中的一塊基石》此書講解了許多電腦科學中用到的數學知識及技巧，並特別著墨於演算法分析方面。

Server 層的動作

  1. DDL 開始更新，無論失敗與否，table share 都要進行緩存更新，tdc_remove_table；
  2. DDL 成功之後，執行事務提交，否則執行事務回滾；
  3. 無論事務提交還是回滾，都要調用 post_ddl ， post_ddl 作用在前面已經描述，用以r Replay 系統表 innodb_ddl_log 記錄的日誌；
  4. 崩潰恢復時候，除了執行 Redo 日誌，回滾未提交的事務之後，還需要執執行 ha_post_recover，而 InnoDB 的 ha_post_recover 就是調用 post_ddl 執行 DDL 的反向操作；
  5. binglog 處理只有一個原則，就是 DDL 事務成功。並且提交之後，才調用 write_bin_log 寫 binlog。

註意事項

  1. MySQL 8.0 支持原子 DDL，並不意味著 DDL 可以通過 SQL 語句命令進行回滾。實際上除了 SQLServer 外，幾乎所有的資料庫系統不支持 DDL 的 SQL 命令進行回滾，DDL 回滾引入的問題遠遠多於其帶來的好處。

  2. MySQL 8.0 只承諾單個 DDL 語句的原子性，並不能保證多個 DDL 組合也能保持原子性。某大廠為了實現 Truncate table flashback ，僅僅在 MySQL 的 Server 層將 truncate table 動作轉換為 rename table 動作，flashback 的時候將表、索引、約束重新以 RENAME DDL 組合執行來實現 flashback，這個是及其危險的，不保證其原子性。筆者也完成過此功能，並沒有如此取巧，而是老老實實的從 Server 層、InnoDB 存儲引擎、binlog 各方面進行改造，完整保證其原子性。

  3. MySQL 8.0 用這種方法實現原子 DDL，並不意味著其它資料庫也是這種方式實現原子DDL。

參考


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • docker部署安裝Nginx
    TCP編程模型 server創建socket套接字 socket套接字--可以理解為文件描述符(file descriptor)，UNIX把網路看成文件 /** * @param domain domain參數指定了一個通信域；它選擇了將被用於通信的協議族。 比如 AF_UNIX AF_INET * ...
  • Linux之vim編輯器
    1.vim三種模式 | 模式 |操作 | | : : | : : | | 可視模式 | 可查看內容 | | 編輯模式 | 可查看可修改內容 | | 命令行模式 | 給vim發送控制命令，可查看內容 | 註：打開文件，預設是可視模式 2.三種模式的切換 可視模式下 按i/a/o鍵 >進入編輯模式 編輯 ...
  • Mathematica 13 for Mac(功能廣泛的科學計算軟體)中文
    如果您還為數學計算的繁瑣，函數作圖的費事，所畫圖形的不規範二煩惱的話，那麼您真的需要這款Mathematica 13 for Mac(科學計算軟體)，是Mac平臺上致力於科學計算的軟體，很好地結合了數值和符號計算引擎、圖形系統、編程語言、文本系統、和與其他應用程式的高級連接。很多功能在相應領域內處於 ...
  • Linux命令之find、grep、echo、tar、whoami、uname
    ####1. whoami--查看當前登錄的用戶名 book@100ask:~/linux$ whoami book ####2. echo--列印命令，配合'>'或者'>>'使用 echo 列印信息 //輸出信息到終端 echo 列印信息 > 文件名 //先清空文件裡面的內容，然後將輸出信息保存到 ...
  • 電腦硬體的讀寫速度差異
    作者：小牛呼嚕嚕 | https://xiaoniuhululu.com 電腦內功、JAVA底層、面試相關資料等更多精彩文章在公眾號「小牛呼嚕嚕 」 現代電腦系統 現代電腦系統與馮·諾依曼電腦差別不大，最大的區別馮·諾依曼電腦 是 以運算器為中心的，而現代電腦 以儲存器為中心： 我們主要 ...
  • Redis變慢？深入淺出Redis性能診斷系列文章(二)
    本篇為Redis性能問題診斷系列的第二篇，本文主要從應用發起的典型命令使用上進行講解，由於Redis為單線程服務架構，對於一些命令如果使用不當會極大的影響Redis的性能表現，這裡也會對不合理的使用方式給出優化解決方案。 ...
  • 開源項目丨ChengYing 1.1版本重磅發佈：新增超多功能，全新優化體驗！
    ChengYing是一站式全自動化全生命周期大數據平臺運維管家，提供大數據產品的一站式部署、運維、監控服務，其可實現產品部署、產品升級、版本回滾、擴縮節點、日誌診斷、集群監控、實時告警等功能，致力於最大化節省運維成本，降低線上故障率與運維難度，為客戶提供安全穩定的產品部署與監控。 ChengYing ...
  • 加班整理出來的MySQL資料庫基本操作送給大家，非常詳細！
    哈嘍兄弟們，中秋閑著沒事，整理了一些資料庫的基本操作，分享給大家，希望對大家有所幫助~ 一、SQL語句 (mysql 資料庫中的語言) show databases;查看資料庫 use "database_ name" ;進入資料庫 show tables; 查看當前資料庫中有哪些表 select ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類