【MySQL】你以為設置了並行複製就降低延遲了？這個你絕對想不到！

来源:https://www.cnblogs.com/linuxsql/archive/2019/09/25/11586845.html
-Advertisement-
Play Games

<! Title：記一次MySQL主從同步延遲處理 Date：2019.09.25 Key：MySQL，gtid，relay 在MySQL官方版本中，為了保證其的高可用性，一般情況我們會採用主從複製的方式來解決。當然，方法很多。而我們今天所要處理的是採用GTID方式並且開了多線程複製後，仍然延遲的情 ...


在MySQL官方版本中，為了保證其的高可用性，一般情況我們會採用主從複製的方式來解決。當然，方法很多。而我們今天所要處理的是採用GTID方式並且開了多線程複製後，仍然延遲的情況，糟糕的是，延遲還在不斷擴大！

  • 環境概要

    • 序號 清單 說明
    1 系統 Redhat 6.x（4c，32g）
    2 資料庫 MySQL-5.7.25
    3 同步方式 基於GTID主從同步

  • 環境排查

    • 1）已經配置的重要參數：

    

    relay for slave
    

    slave_parallel_type = LOGICAL_CLOCK
    
slave_parallel_workers = 6
    
master_info_repository = TABLE
    
relay_log_info_repository = TABLE
    
relay_log_recovery = on
    
sync_relay_log = 10000

    註：此時沒有設置slave_preserve_commit_order參數。

    2）從庫延遲狀態查詢


    
mysql> show slave status\G
    
*************************** 1. row ***************************
    
Slave_IO_State: Queueing master event to the relay log
    
Master_Host: xxx.xxx.xxx.xxx
    
Master_User: repl
    
Master_Port: 3306
    
Connect_Retry: 60
    
Master_Log_File: mysql-bin.008978
    
Read_Master_Log_Pos: 696914605
    
Relay_Log_File: DB41-relay-bin.001259
    
Relay_Log_Pos: 207377582
    
Relay_Master_Log_File: mysql-bin.008970
    
Slave_IO_Running: Yes
    
Slave_SQL_Running: Yes
    
Replicate_Do_DB: neteagle3
    
Replicate_Ignore_DB: mysql
    
Replicate_Do_Table:
    
Replicate_Ignore_Table:
    
Replicate_Wild_Do_Table:
    
Replicate_Wild_Ignore_Table:
    
Last_Errno: 0
    
Last_Error:
    
Skip_Counter: 0
    
Exec_Master_Log_Pos: 1068770059
    
Relay_Log_Space: 8425484286
    
Until_Condition: None
    
Until_Log_File:
    
Until_Log_Pos: 0
    
Master_SSL_Allowed: No
    
Master_SSL_CA_File:
    
Master_SSL_CA_Path:
    
Master_SSL_Cert:
    
Master_SSL_Cipher:
    
Master_SSL_Key:
    
Seconds_Behind_Master: 187358
    
Master_SSL_Verify_Server_Cert: No
    
Last_IO_Errno: 0
    
Last_IO_Error:
    
Last_SQL_Errno: 0
    
Last_SQL_Error:
    
Replicate_Ignore_Server_Ids:
    
Master_Server_Id: 42
    
Master_UUID: eab7fcac-3cda-11e6-ada8-fa163e648db2
    
Master_Info_File: mysql.slave_master_info
    
SQL_Delay: 0
    
SQL_Remaining_Delay: NULL
    
Slave_SQL_Running_State: Waiting for dependent transaction to commit
    
Master_Retry_Count: 86400
    
Master_Bind:
    
Last_IO_Error_Timestamp:
    
Last_SQL_Error_Timestamp:
    
Master_SSL_Crl:
    
Master_SSL_Crlpath:
    
Retrieved_Gtid_Set: eab7fcac-3cda-11e6-ada8-fa163e648db2:58031191-59927276
    
Executed_Gtid_Set: eab7fcac-3cda-11e6-ada8-fa163e648db2:1-58080239:58080241
    
Auto_Position: 1
    
Replicate_Rewrite_DB:
    
Channel_Name:
    
Master_TLS_Version:
    
1 row in set (0.00 sec)


    簡單介紹一下幾個指標信息：

    1. Master_Log_File
    2. Read_Master_Log_Pos
    3. Seconds_Behind_Master
    4. Relay_Log_File
    5. Relay_Log_Pos
    6. Relay_Master_Log_File
    7. Exec_Master_Log_Pos

    Master_Log_File, Read_Master_Log_Pos：
    這兩個參數是成對的，表示的是從庫IO thread傳輸主庫的binlog日誌號及具體位置。

    Relay_Log_File, Relay_Log_Pos：
    這兩個參數也是成對的，表示的是從庫sql thread應用中繼日誌（relay log）號及具體位置。

    Relay_Master_Log_File, Relay_Log_Pos：
    這兩個參數也是成對的，表示的是上一項中的中繼日誌對應的主庫binlog日誌及具體位置（有點繞）。

    Seconds_Behind_Master：
    此參數可簡單理解為主從延遲時間，單位為秒。

    從上面這段MySQL從狀態信息中，我們可以看到，Seconds_Behind_Master: 187358這是從庫sql應用延遲主庫的時間為187358秒，轉換成天，大概兩天多。這說明，我們從庫複製的數據是兩天前的。

    3)驗證並行複製


    
mysql> show full processlist;
    
---- ------------- -------------- ----------- ------------------ -------- --------------------------------------------------------------- -----------------------
    
| Id | User | Host | db | Command | Time | State | Info |
    
---- ------------- -------------- ----------- ------------------ -------- --------------------------------------------------------------- -----------------------
    
| 1 | system user | | NULL | Connect | 18204 | Waiting for master to send event | NULL |
    
| 2 | system user | | NULL | Connect | 0 | Waiting for dependent transaction to commit | NULL |
    
| 3 | system user | | NULL | Connect | 154914 | System lock | NULL |
    
| 4 | system user | | NULL | Connect | 154914 | Waiting for an event from Coordinator | NULL |
    
| 5 | system user | | NULL | Connect | 154918 | Waiting for an event from Coordinator | NULL |
    
| 6 | system user | | NULL | Connect | 155525 | Waiting for an event from Coordinator | NULL |
    
| 7 | system user | | NULL | Connect | 180427 | Waiting for an event from Coordinator | NULL |
    
| 8 | system user | | NULL | Connect | 18204 | Waiting for an event from Coordinator | NULL |
    
| 10 | root | localhost | neteagle3 | Query | 0 | starting | show full processlist |
    
| 11 | repl | DBSlave:9683 | NULL | Binlog Dump GTID | 18156 | Master has sent all binlog to slave; waiting for more updates | NULL |
    
| 13 | root | localhost | neteagle3 | Sleep | 4962 | | NULL |
    
---- ------------- -------------- ----------- ------------------ -------- --------------------------------------------------------------- -----------------------
    


    
mysql> select * from  performance_schema.replication_applier_status_by_worker ;
 -------------- ----------- ----------- --------------- ----------------------------------------------- ------------------- -------------------- ---------------------- 
| CHANNEL_NAME | WORKER_ID | THREAD_ID | SERVICE_STATE | LAST_SEEN_TRANSACTION                         | LAST_ERROR_NUMBER | LAST_ERROR_MESSAGE | LAST_ERROR_TIMESTAMP |
 -------------- ----------- ----------- --------------- ----------------------------------------------- ------------------- -------------------- ---------------------- 
|              |         1 |        51 | ON            | eab7fcac-3cda-11e6-ada8-fa163e648db2:80240805 |                 0 |                    | 0000-00-00 00:00:00  |
|              |         2 |        52 | ON            | eab7fcac-3cda-11e6-ada8-fa163e648db2:80240210 |                 0 |                    | 0000-00-00 00:00:00  |
|              |         3 |        53 | ON            | eab7fcac-3cda-11e6-ada8-fa163e648db2:80235089 |                 0 |                    | 0000-00-00 00:00:00  |
|              |         4 |        54 | ON            | eab7fcac-3cda-11e6-ada8-fa163e648db2:80191268 |                 0 |                    | 0000-00-00 00:00:00  |
|              |         5 |        55 | ON            | eab7fcac-3cda-11e6-ada8-fa163e648db2:75296683 |                 0 |                    | 0000-00-00 00:00:00  |
|              |         6 |        56 | ON            |                                               |                 0 |                    | 0000-00-00 00:00:00  |
 -------------- ----------- ----------- --------------- ----------------------------------------------- ------------------- -------------------- ---------------------- 
6 rows in set (0.00 sec)
通過本條查詢，可以看到開啟了6個並行進行複製。

  • 細找瓶頸？


    • 通過以上來看，所有一切似乎都正常，並行複製開了，並且查看到CPU，IO，記憶體均沒有達到瓶頸地步。主庫寫binlog日誌大概為2MB/s,這樣的日質量並不是非常高。

    從庫也同樣查看了是否存在鎖的情況，也沒有發現。

    因此反覆的在查看slave狀態，看能否發現一些細節，結果還真看到了一些異常現象。Relay_Log_Pos這個參數在頻繁的刷slave狀態時，發現時常會卡著不動（此時已確認沒有看到鎖）。或許問題真正的原因正在這裡！

  • 順藤摸瓜！


    • 分析binlog或者relay log日誌，看有啥線索：


    
[mysql@xxx data]$ mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS relay-bin.001384 --start-position=420090430|more
    

    
/!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1/;
    
/!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0/;
    
DELIMITER /!/;
    
# at 420090430
    

    190923 9:24:28 server id 42 end_log_pos 420090282 CRC32 0xd9097eaf GTID last_committed=57148 sequence_number=57149 rbr_only=yes
    

    /!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED//!/;
    
SET @@SESSION.GTID_NEXT= 'eab7fcac-3cda-11e6-ada8-fa163e648db2:69415610'/!/;
    
# at 420090495
    

    190923 9:24:28 server id 42 end_log_pos 420090364 CRC32 0x82b57dfd Query thread_id=95 exec_time=0 error_code=0
    

    SET TIMESTAMP=1569201868/!/;
    
SET @@session.pseudo_thread_id=95/!/;
    
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/!/;
    
SET @@session.sql_mode=1075838976/!/;
    
SET @@session.auto_increment_increment=2, @@session.auto_increment_offset=1/!/;
    
/!\C gbk //!/;
    
SET @@session.character_set_client=28,@@session.collation_connection=28,@@session.collation_server=8/!/;
    
SET @@session.lc_time_names=0/!/;
    
SET @@session.collation_database=DEFAULT/!/;
    
BEGIN
    
/!/;
    
# at 420090577
    

    190923 9:24:28 server id 42 end_log_pos 420090585 CRC32 0x752e27cf Table_map: net.f_event mapped to number 108
    

    # at 420090798
    

    190923 9:24:28 server id 42 end_log_pos 420090812 CRC32 0x72b8e10d Table_map: net.f_eventstorage mapped to number 245
    

    # at 420091025
    

    190923 9:24:28 server id 42 end_log_pos 420091039 CRC32 0x1797f9d8 Table_map: net.f_eventstorage mapped to number 245
    

    # at 420091252
    

    190923 9:24:28 server id 42 end_log_pos 420091106 CRC32 0x8af14ad2 Table_map: net.f_eventdetail mapped to number 243
    

    # at 420091319
    

    190923 9:24:28 server id 42 end_log_pos 420091177 CRC32 0xf1ce87c8 Table_map: net.f_eventoperation mapped to number 244
    

    # at 420091390
    

    190923 9:24:28 server id 42 end_log_pos 420091244 CRC32 0x586c0b9d Table_map: net.f_eventaudit mapped to number 242
    

    # at 420091457
    

    190923 9:24:28 server id 42 end_log_pos 420093382 CRC32 0x505e5408 Update_rows: table id 108
    

    # at 420093595
    

    190923 9:24:28 server id 42 end_log_pos 420098858 CRC32 0x0f404509 Update_rows: table id 245
    

    # at 420099071
    

    190923 9:24:28 server id 42 end_log_pos 420098910 CRC32 0xb8d9ed15 Write_rows: table id 243
    

    # at 420099123
    

    190923 9:24:28 server id 42 end_log_pos 420098966 CRC32 0x3c489a7f Write_rows: table id 244 flags: STMT_END_F

    我們查看了中繼日誌relay-bin.001384卡住的位置號420090430，為設置GTID_NEXT，信息沒什麼用。

    繼續看在卡住時刻，資料庫open的是什麼表？


    
mysql> show open tables where In_use=1;
    
----------- --------------------- -------- -------------
    
| Database | Table | In_use | Name_locked |
    
----------- --------------------- -------- -------------
    
| net | f_currentxxx | 1 | 0 |
    
----------- --------------------- -------- -------------

    這張表有什麼特殊的麽？查看其表結構

    
mysql> show create table net.f_currentxxx\G
    
*************************** 1. row ***************************
    
Table: f_currentxxx
    
Create Table: CREATE TABLE f_currentxxx (
    
serial int(20) NOT NULL COMMENT 'xxx',
    
audittime bigint(20) NOT NULL COMMENT 'xxx',
    
type int(11) DEFAULT NULL COMMENT 'xxx',
    
severity int(11) DEFAULT NULL COMMENT 'xxx,
    
KEY audittime (audittime)
    
) ENGINE=MEMORY DEFAULT CHARSET=gbk COMMENT='xxx'
    
1 row in set (0.00 sec)

    有沒有看到什麼與眾不同？

    沒錯，就是表的存儲引擎ENGINE=MEMORY。MEMORY的表進行主從複製，首先來說如果從庫不做查詢，一點意義沒有，另外對Memory表做複製，性能是非常堪憂的。如果必須進行同步，考慮將表的存儲引擎改為InnoDB

    
mysql> select table_name from information_schema.tables where TABLE_SCHEMA='net' and ENGINE='memory';

 ---------------------- 
| table_name           |
 ---------------------- 
| f_currentxxx         |
 ---------------------- 
1 row in set, 6 warnings (0.01 sec)
出於嚴謹，我們將要複製的資料庫進行徹底排查，確實只有這一張表是Memory存儲引擎。

  • 措施


    • 停止複製進程，將選項中添加replicate-ignore-table=net.f_currentxxx,重新啟動複製進程，觀察slave狀態。

    
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: xxx.xxx.xxx.xxx
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.009194
          Read_Master_Log_Pos: 939698255
               Relay_Log_File: relay-bin.001964
                Relay_Log_Pos: 444060572
        Relay_Master_Log_File: mysql-bin.009027
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: net
          Replicate_Ignore_DB: mysql
           Replicate_Do_Table: 
       Replicate_Ignore_Table: net.f_currentxxx
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 444060359
              Relay_Log_Space: 180287882098
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 179221
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 42
                  Master_UUID: eab7fcac-3cda-11e6-ada8-fa163e648db2
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Waiting for dependent transaction to commit
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: eab7fcac-3cda-11e6-ada8-fa163e648db2:69497322-107886661
            Executed_Gtid_Set: 1264a536-da12-11e9-81ea-005056856ba5:1,
eab7fcac-3cda-11e6-ada8-fa163e648db2:1-71980857
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

    我們可以看到net.f_currentxxx表已經被忽略複製。持續觀察一段時間後，Seconds_Behind_Master在逐漸縮小。
    中繼日誌應用速度大約5分鐘一個（每個中繼日誌為1GB大小），而主庫binlog日誌大約為10分鐘一個（每個binlog日誌為1GB大小）。

  • 總結


    • 在梳理了整個處理過程後，其實難度不高，主要是要細心，細心去排查每一個想到的點。 在非輕量級的資料庫中問題發生的概率也會隨著量級的增加而增多。而這恰恰是能夠磨練個人的成長。


    同時，知識的儲備也要充足，這是進階高手的必要前提！


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

    -Advertisement-
    Play Games
    更多相關文章
    • 高通平臺：USB充電【轉】
      USB Battery Charging V1.2 Specification 定義了USB充電器的類型或者叫做充電源。 1. 支持的充電器類型 1.1 Standard Downstream Port(SDP) 這種USB埠存在於主機PC中，這個是與USB的規格書一致的。 當一個USB外設接到S ...
    • 操作系統修煉秘籍（1）：秘籍簡介
      毋庸置疑，操作系統（Operating System，OS）是一個非常大的概念，涉及到的內容非常非常多，在探討它的時候，往往會將操作系統置於一個比較底層的角度去對待，這也使得多數人對OS是“聞之喪膽”，對OS相關的資料或概念也是望而卻步，這也是我曾經親身經歷的過程。 君不見那些力量之書自地獄來。 這 ...
    • Linux07 查找文件（find、locate）
      一、一般查找：find find PATH -name FILENAME 我們也可是使用 ‘*’ 通配符來模糊匹配要查找的文件名 二、資料庫查找：locate locate FILENAME 1、這種方法相對於find命令反饋更為迅速 2、在使用這個命令之前，一般需要執行updatedb ...
    • SQL Server查看login所授予的具體許可權
      在SQL Server資料庫中如何查看一個登錄名(login)的具體許可權呢，如果使用SSMS的UI界面查看登錄名的具體許可權的話，用戶資料庫非常多的話，要梳理完它所有的許可權，操作又耗時又麻煩，個人十分崇尚簡潔、高效的方法，反感那些需要大量手工操作的UI界面操作方式，哪怕就是腳本，如果不能一次搞定，手工... ...
    • 資料庫事務的四種隔離模式
      四種隔離模式主要是用來解決不同線程的事務造成的幾種問題： 1.修改丟失：兩個事務A,B對同一數據同時進行讀取與修改，出現事務B 覆蓋事務A的提交結果 2.臟讀:事務A讀到事務B修改卻未提交的數據，事務B回滾數據修改操作，導致了事務A獲得數據是臟數據（也可以理解為事務A獲取的數據與資料庫中存儲的數據是 ...
    • [20190920]完善vim調用sqlplus腳本.txt
      [20190920]完善vim調用sqlplus腳本.txt--//以前寫的http://blog.itpub.net/267265/viewspace-2140936/=>[20170617]vim中調用sqlplus.txt --//本來自己想寫一個轉化oracle 數字的腳本,對於我來講難度有 ...
    • 博客的第一天：回顧半年前的基礎：SQL--基礎查詢+年月日格式+拼接
      2019/6月份 <<必知必會>>書本練習-實踐練習 order by沒有where就是在前，而又多個列的組合條件在在後面select top 10 * from VF_TSTOSTOCK_UCMLselect top 10 STOID,BPSCOD,BPSNAM,ITMNAM,STOFCYName ...
    • redis資料庫的使用
      一.安裝redis與可視化操作工具 可視化工具:RedisDesktopManager redis載地址：https://github.com/MSOpenTech/redis/releases。 二.在服務中管理redis伺服器的開啟關閉 三.命令行簡單使用 redis cli 啟動客戶端 set ...
    一周排行
      -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.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
    所有分類