進程管理（二）

来源:https://www.cnblogs.com/1naonao/archive/2019/07/23/11232132.html
-Advertisement-
Play Games

[toc] 進程的優先順序 那麼在系統中如何給進程配置優先順序 在啟動進程時，為不同的進程使用不同的調度策略。 nice值越高：表示優先順序越低，例如19，該進程容易將CPU使用量讓給其他進程。 nice值越低：表示優先順序越高，例如 20，該進程更不傾向於讓出CPU。 遠程連接不上操作步驟 網路 埠 用 ...


目錄

進程的優先順序

那麼在系統中如何給進程配置優先順序

在啟動進程時，為不同的進程使用不同的調度策略。

nice值越高：表示優先順序越低，例如19，該進程容易將CPU使用量讓給其他進程。
nice值越低：表示優先順序越高，例如-20，該進程更不傾向於讓出CPU。

遠程連接不上操作步驟

  • 網路

    ping 10.0.0.100

  • 埠

    telnet 10.0.0.150 22
tcping 10.0.0.150 22

  • 用戶

    root

  • 密碼

    1

使用nice命令指定進程優先順序

#打開一個終端
[root@zls ~]# nice -n -5 vim zls

#打開另一個終端，查看進程的優先順序
[root@zls ~]# ps aux|grep [v]im
root       2342  0.1  0.2 151720  5212 pts/1    S<+  19:49   0:00 vim zls
[root@zls ~]# ps axo command,nice|grep [v]im
vim zls                      -5

使用renice調整已運行程式的優先順序

#先查看sshd的優先順序
[root@zls ~]# ps axo pid,command,nice|grep 摺疊shd
   869 /usr/sbin/sshd -D             0
  1194 sshd: root@pts/0              0
  1307 sshd: root@pts/1              0
  1574 sshd: root@pts/2              0
  
#設置sshd的優先順序為-20
[root@zls ~]# renice -n -20 869
869 (進程 ID) 舊優先順序為 0，新優先順序為 -20

#再次查看sshd的優先順序
[root@zls ~]# ps axo pid,command,nice|grep 摺疊shd
   869 /usr/sbin/sshd -D           -20
  1194 sshd: root@pts/0              0
  1307 sshd: root@pts/1              0
  1574 sshd: root@pts/2              0

#一定要退出終端重新連接
[root@zls ~]# exit
登出

#再檢查，就可以看到當前終端的優先順序變化了
[root@zls ~]# ps axo pid,command,nice|grep sshd
   869 /usr/sbin/sshd -D           -20
  1194 sshd: root@pts/0              0
  1574 sshd: root@pts/2              0
  2361 sshd: root@pts/1            -20

企業案例，linux假死

什麼是假死

所謂假死，就是能ping通，但是ssh不上去；任何其他操作也都沒反應，包括上面部署的nginx也打不開頁面。

假死如何實現

有一個確定可以把系統搞成假死的辦法是：主進程分配固定記憶體，然後不停的fork，並且在子進程裡面sleep(100)。
也就是說，當主進程不停fork的時候，很快會把系統的物理記憶體用完，當物理記憶體不足時候，系統會開始使用swap；那麼當swap不足時會觸發oom killer進程；
當oom killer殺掉了子進程，主進程會立刻fork新的子進程，並再次導致記憶體用完，再次觸發oom killer進程，於是進入死迴圈。而且oom killer是系統底層優先順序很高的內核線程，也在參與死迴圈。

系統假死為何能ping同無法連接

此時機器可以ping通，但是無法ssh上去。這是由於ping是在系統底層處理的，沒有參與進程調度；sshd要參與進程調度，但是優先順序沒oom killer高，總得不到調度。

怎樣解決

其實建議使用nice將sshd的進程優先順序調高。這樣當系統記憶體吃緊，還能勉強登陸sshd，進入調試。然後分析故障

後臺進程管理

後臺進程

通常進程都會在終端前臺運行，但是一旦關閉終端，進程也會隨著結束，那麼此時我們就希望進程能在後臺運行，就是將在前臺運行的進程放到後臺運行，這樣即使我們關閉了終端也不影響進程的正常運行。

為什麼要把進程放到後臺運行

企業中很多時候會有一些需求：
1.傳輸大文件，由於網路問題需要傳輸很久
2.我們之前的國外業務，國內到國外，網速很慢，我們需要選擇節點做跳板機，那麼就必須知道，哪個節點到其他地區網速最快，丟包率最低。
3.有些服務沒有啟動腳本，那麼我們就需要手動運行，並把他們放到後臺

後臺進程管理

jobs：查看後臺進程
bg：永久放到後臺
fg：調出後臺任務

screen

#安裝screen命令
[root@zls ~]# yum install -y screen

#安裝redis
[root@zls ~]# yum install -y redis

#啟動redis
[root@zls ~]# redis-server

#放到後臺ctrl + z
[1]+  已停止               redis-server

#關閉終端，redis進程就沒有了

#下載mysql安裝包
[root@zls ~]# wget https://downloads.mysql.com/archives/get/file/mysql-5.7.24-linux-glibc2.12-x86_64.tar.gz

#使用screen
[root@zls ~]# screen -S download_mysqld
#ctrl + a + d放置後臺
[detached from 3567.download_mysqld]
#查看screen列表
[root@zls ~]# screen -list
There is a screen on:
    3567.download_mysqld    (Detached)
1 Socket in /var/run/screen/S-root.

#打開screen終端
[root@zls ~]# screen -r 3567

系統平均負載

每次發現系統變慢時，我們通常做的第一件事，就是執行top或者uptime命令，來瞭解系統的負載情況。

[root@zls ~]# uptime
 20:45:42 up  8:56,  3 users,  load average: 0.01, 0.03, 0.05
#我們已經比較熟悉前面幾個例子，他們分別是當前時間，系統運行時間，以及正在登陸用戶數

#後面三個數依次是：過去1分鐘,5分鐘,15分鐘的平均負載(Load Average)

平均負載

那到底如何理解平均負載：平均負載是指，單位時間內，系統處於可運行狀態和不可中斷狀態的平均進程數，也就是平均活躍進程數

PS:平均負載與CPU使用率並沒有直接關係。

可運行狀態和不可中斷狀態是什麼？

1.可運行狀態進程，是指正在使用CPU或者正在等待CPU的進程，也就是我們用PS命令看的處於R狀態的進程

2.不可中斷進程，（你在做什麼事情的時候是不能被打斷的呢？...不可描述）系統中最常見的是等待硬體設備的IO相應，也就是我們PS命令中看到的D狀態（也成為Disk Sleep）的進程。

例如：當一個進程向磁碟讀寫數據時，為了保證數據的一致性，在得到磁碟回覆前，他是不能被其他進程或者中斷程式打斷的，這個是後續的進程就處於不可中斷的狀態，如果此時進程強制被打斷，kill -9 ... perfect準備好護照吧，有多遠，走多遠，千萬別回來了。不可中斷狀態實際上是系統對進程和硬體設備的一種保護機制

因此，可以簡單理解為，平均負載其實就是單位時間內的活躍進程數。

平均負載與CPU的使用率有什麼關係

在十幾工作中，我們經常容易把平均負載和CPU使用率混淆，所以在這裡，我也做一個區分，可能你會感覺到疑惑，既然平均負載代表的是活躍進程數，那平均負載搞了，不就意味著CPU使用率高嘛？

我們還是要回到平均負載的含義上來，平均負載指的是每單位時間內，處於可運行狀態和不可中斷狀態的進程數，所以，它不僅包括了正在使用CPU的進程數，還包括等待CPU和等待IO的進程數。

而CPU的使用率是單位時間內，CPU繁忙情況的統計，跟平均浮現在並不一定完全對應。
比如：

CPU密集型進程，使用大量的CPU會導致平均負載升高，此時這兩者是一致的。
IO密集型進程，等待IO也會導致平均負載升高，但CPU使用率不一定很高。

大量等待CPU的進程調度也會導致平均負載升高，此時的CPU使用率也會比較高。

但是CPU的種類也分兩種：
CPU密集型
IO密集型

例如MySQL伺服器，就需要儘量選擇使用IO密集型CPU

平均負載案例分析實戰

下麵我們以三個示例分別來看這三中情況，並用：stress、mpstat、pidstat等工具找出平均負載升高的根源

stress是Linux系統壓力測試工具，這裡我們用作異常進程模擬平均負載升高的場景。

mpstat是多核CPU性能分析工具，用來實時檢查每個CPU的性能指標，以及所有CPU的平均指標。

pidstat是一個常用的進程性能分析工具，用來實時查看進程的CPU，記憶體，IO，以及上下文切換等性能指標。

#安裝stress,命令sysstat
 yum provides strees    #找尋安裝包
[root@zls ~]# yum install -y stress
[root@zls ~]# yum install -y sysstat

案例一：CPU密集型

我們在第一個中斷運行stress命令，模擬一個CPU使用率100%的場景：

#第一個終端執行
[root@zls ~]# stress --cpu 1 --timeout 600

#第二個終端查看
[root@zls ~]# uptime
 22:04:12 up 10:15,  4 users,  load average: 1.98, 0.57, 0.22
 
#高亮顯示變化區域
[root@zls ~]# watch -d uptime
Every 2.0s: uptime                                                                                                                                                                                                                                      Sun Jul 14 22:05:16 2019

 22:05:16 up 10:16,  4 users,  load average: 2.84, 1.05, 0.41

使用mpstat查看CPU使用率的變化情況

[root@zls ~]# mpstat -P ALL 5
Linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 CPU)

22時08分51秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22時08分56秒  all   99.20    0.00    0.80    0.00    0.00    0.00    0.00    0.00    0.00    0.00
22時08分56秒    0   99.20    0.00    0.80    0.00    0.00    0.00    0.00    0.00    0.00    0.00

22時08分56秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22時09分01秒  all   99.60    0.00    0.40    0.00    0.00    0.00    0.00    0.00    0.00    0.00
22時09分01秒    0   99.60    0.00    0.40    0.00    0.00    0.00    0.00    0.00    0.00    0.00

從終端2可以看到，1分鐘平均負載會慢慢增加到2.00，而從終端三中還可以看到，正好有一個CPU的使用率為100%，但他的IOwait只有0，這說明平均負載的升高正式由於CPU使用率為100%，那麼到底哪個進程導致CPU使用率為100%呢？可以使用pidstat來查詢

#間隔5秒輸出一組數據
[root@zls ~]# pidstat -u 5 1
Linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 CPU)

22時14分00秒   UID       PID    %usr %system  %guest    %CPU   CPU  Command
22時14分05秒     0      8349    0.00    0.20    0.00    0.20     0  kworker/0:3
22時14分05秒     0      9903   99.60    0.00    0.00   99.60     0  stress

平均時間:   UID       PID    %usr %system  %guest    %CPU   CPU  Command
平均時間:     0      8349    0.00    0.20    0.00    0.20     -  kworker/0:3
平均時間:     0      9903   99.60    0.00    0.00   99.60     -  stress

案例二：I/O密集型

還是使用stress命令，但是這次模擬IO的壓力

[root@zls ~]# stress --io 1 --timeout 600s

在第二個終端運行uptime查看平均負載的變化情況

[root@zls ~]# watch -d uptime
Every 2.0s: uptime                                                                                                                                                                                                                                      Sun Jul 14 22:17:38 2019

 22:17:38 up 10:28,  4 users,  load average: 2.47, 2.25, 1.61

在第三個終端運行mpstat查看CPU使用率的變化情況

[root@zls ~]# mpstat -P ALL 5
Linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 CPU)

22時19分32秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22時19分37秒  all    2.78    0.00   97.22    0.00    0.00    0.00    0.00    0.00    0.00    0.00
22時19分37秒    0    2.78    0.00   97.22    0.00    0.00    0.00    0.00    0.00    0.00    0.00

22時19分37秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22時19分42秒  all    3.01    0.00   96.99    0.00    0.00    0.00    0.00    0.00    0.00    0.00
22時19分42秒    0    3.01    0.00   96.99    0.00    0.00    0.00    0.00    0.00    0.00    0.00

#發現CPU與內核打交道的sys占用非常高

那麼到底哪個進程導致iowait這麼高呢？

[root@zls ~]# pidstat -u 5 1
Linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 CPU)

22時20分59秒   UID       PID    %usr %system  %guest    %CPU   CPU  Command
22時21分04秒     0      6900    0.00    0.20    0.00    0.20     0  kworker/0:0
22時21分04秒     0     10104    2.76   83.07    0.00   85.83     0  stress
22時21分04秒     0     10105    0.00   10.63    0.00   10.63     0  kworker/u256:2


平均時間:   UID       PID    %usr %system  %guest    %CPU   CPU  Command
平均時間:     0      6900    0.00    0.20    0.00    0.20     -  kworker/0:0
平均時間:     0     10104    2.76   83.07    0.00   85.83     -  stress
平均時間:     0     10105    0.00   10.63    0.00   10.63     -  kworker/u256:2

這時候發現看到的數據比較少，需要更新一下命令：

#下載新版本的包
[root@zls ~]# wget http://pagesperso-orange.fr/sebastien.godard/sysstat-11.7.3-1.x86_64.rpm

#升級到新版本
[root@zls ~]# rpm -Uvh sysstat-11.7.3-1.x86_64.rpm
準備中...                          ################################# [100%]
正在升級/安裝...
   1:sysstat-11.7.3-1                 ################################# [ 50%]
正在清理/刪除...
   2:sysstat-10.1.5-17.el7            ################################# [100%]

然後再次查看結果,明顯顯示的數據多了

[root@zls ~]# pidstat -u 5 1
Linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 CPU)

22時24分40秒   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
22時24分45秒     0       281    0.00    0.20    0.00    0.40    0.20     0  xfsaild/sda3
22時24分45秒     0     10104    2.99   82.67    0.00    0.00   85.66     0  stress
22時24分45秒     0     10105    0.00    8.76    0.00   92.43    8.76     0  kworker/u256:2
22時24分45秒     0     10118    0.20    0.40    0.00    0.00    0.60     0  watch
22時24分45秒     0     10439    0.00    3.98    0.00   94.82    3.98     0  kworker/u256:3
22時24分45秒     0     11007    0.00    0.20    0.00    0.00    0.20     0  pidstat

平均時間:   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
平均時間:     0       281    0.00    0.20    0.00    0.40    0.20     -  xfsaild/sda3
平均時間:     0     10104    2.99   82.67    0.00    0.00   85.66     -  stress
平均時間:     0     10105    0.00    8.76    0.00   92.43    8.76     -  kworker/u256:2
平均時間:     0     10118    0.20    0.40    0.00    0.00    0.60     -  watch
平均時間:     0     10439    0.00    3.98    0.00   94.82    3.98     -  kworker/u256:3
平均時間:     0     11007    0.00    0.20    0.00    0.00    0.20     -  pidstat

案例三：大量進程的場景

當系統運行進程超出CPU運行能力時，就會出現等待CPU的進程。

1.首先，我們還是使用stress命令，模擬的是多個進程

[root@zls ~]# stress -c 4 --timeout 600

2.由於系統只有一個CPU，明顯比4個進程要少的多。因此，系統的CPU處於嚴重過載狀態

[root@zls ~]#
Every 2.0s: uptime                                                                                                                                                                                                                                      Sun Jul 14 22:28:50 2019

 22:28:50 up 10:39,  4 users,  load average: 3.96, 3.89, 3.00

3.在運行pidstat命令來查看一下進程的情況

[root@zls ~]# pidstat -u 5 1
Linux 3.10.0-862.el7.x86_64 (zls)   2019年07月14日     _x86_64_    (1 CPU)

22時31分12秒   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
22時31分17秒     0     11317   24.75    0.00    0.00   75.05   24.75     0  stress
22時31分17秒     0     11318   24.95    0.00    0.00   75.45   24.95     0  stress
22時31分17秒     0     11319   24.75    0.00    0.00   75.25   24.75     0  stress
22時31分17秒     0     11320   24.75    0.00    0.00   75.45   24.75     0  stress
22時31分17秒     0     11381    0.20    0.40    0.00    0.00    0.60     0  watch
22時31分17秒     0     11665    0.00    0.20    0.00    0.00    0.20     0  pidstat

平均時間:   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
平均時間:     0     11317   24.75    0.00    0.00   75.05   24.75     -  stress
平均時間:     0     11318   24.95    0.00    0.00   75.45   24.95     -  stress
平均時間:     0     11319   24.75    0.00    0.00   75.25   24.75     -  stress
平均時間:     0     11320   24.75    0.00    0.00   75.45   24.75     -  stress
平均時間:     0     11381    0.20    0.40    0.00    0.00    0.60     -  watch
平均時間:     0     11665    0.00    0.20    0.00    0.00    0.20     -  pidstat

總結

1.平均負載高有可能是CPU密集型進程導致的
2.平均負載高並不一定代表CPU的使用率就一定高，還有可能是I/O繁忙
3.當發現負載高時，可以使用mpstat、pidstat等工具，快速定位到，負載高的原因，從而做出處理


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

-Advertisement-
Play Games
更多相關文章
  • 位運算、代碼的完整性
    這篇文章主要是介紹劍指offer中的【位運算:二進位中1的個數】，【代碼的完整性:數值的整數次方】，【代碼的完整性:調整數組順序使奇數位於偶數前面】的實現。 1. 位運算:二進位中1的個數， 題目描述 輸入一個整數，輸出該數二進位表示中1的個數。其中負數用補碼表示。 解題思路 把一個整數減去1，再和 ...
  • 動手造輪子：實現一個簡單的 EventBus
    動手造輪子：實現一個簡單的 EventBus Intro EventBus 是一種事件發佈訂閱模式，通過 EventBus 我們可以很方便的實現解耦，將事件的發起和事件的處理的很好的分隔開來，很好的實現解耦。 微軟官方的示例項目 "EShopOnContainers" 也有在使用 EventBus ...
  • 薦讀|屬性與可直接訪問的數據成員之間應該如何選
    寫在前面 在書寫C 代碼的時候你是否有過這樣的經歷：經常混用屬性以及公有的數據成員。畢竟他們的用法基本一致，對於使用來說好像沒什麼區別啊。其實我也經常使用類的公有的數據成員來定義一些常量，為了簡單，在一些僅僅需要對外暴露一些常量的類中（如定義一些全局使用的常量），也都是通過定義公有數據成員實現的。直 ...
  • Linux學習筆記04
    文件查找命令find 文件查找命令: which locate find which:查找命令字所在的位置 locate:模糊匹配(只要包含關鍵字的文件都查找出來) 不是實時的,基於資料庫查找, updatedb升級locate資料庫 查找速度特別快 find:查看文件或目錄的工具 特點： 實時查找 ...
  • yum update 執行報錯： error : unpacking of archive failed on file /usr/.../...;5d26ff7c: cpio : symlink
    早前已發現有台機一直在報這麼個錯誤， 一用yum update 就報一堆: Error: unpacking rpm package ..... error: xxxx : install failed error : unpacking of archive failed on file /usr ...
  • Linux特基礎的知識（接上一條）
    grep:文本過濾工具（找到要找的文本） print lines matching a pattern例： 列印 行 匹配 一個 模式/樣式[root@oldboyedu /opt]# grep "oldboy" oldboy.txt Welcome to oldboy training.grep ...
  • Linux系統安裝JDK
    前言：方法為上傳本地jdk壓縮包文件到遠程linux系統 <<< 驗證系統位數 >>> 在安裝之前，先驗證Linux系統的位數。 運行結果如下，結果顯示當前系統為64位 <<< 官網下載jdk壓縮包 >>> 選擇箭頭指向的壓縮包 <<< 上傳壓縮包 >>> 首先通過在xshell上傳壓縮包 效果圖如 ...
  • 如何選擇適合自己的Linux版本
    如何選擇適合自己的Linux版本: 1.Linux桌面系統,首選Ubuntu; 2.伺服器端的Linux系統,首選RHEL或CentOS,這兩種中首選CentOS,如果公司有錢,不在乎成本也可以選擇RHEL; 3.如果對安全要求很高,可選擇Debian或FreeBSD; 4.如果需要使用資料庫高級服 ...
一周排行
    -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.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類