1. 進(jìn)程間通訊到底在解決什么問(wèn)題很多剛接觸系統(tǒng)編程的朋友第一次聽(tīng)到“進(jìn)程間通訊”這個(gè)詞腦子里冒出來(lái)的畫(huà)面大概是兩個(gè)程序互相喊話。這個(gè)直覺(jué)其實(shí)挺準(zhǔn)的但只對(duì)了一半。進(jìn)程之間不光要“喊話”還得保證喊的內(nèi)容不丟、不亂、不重復(fù)甚至有時(shí)候還得讓一方等另一方先說(shuō)完。這就不是喊一嗓子那么簡(jiǎn)單了。進(jìn)程是操作系統(tǒng)分配資源的基本單位每個(gè)進(jìn)程都有自己獨(dú)立的虛擬地址空間。這個(gè)“獨(dú)立”是操作系統(tǒng)刻意設(shè)計(jì)的保護(hù)機(jī)制好處是一個(gè)進(jìn)程崩了不會(huì)輕易把別的進(jìn)程帶崩壞處就是進(jìn)程之間沒(méi)法直接讀寫(xiě)對(duì)方的內(nèi)存。你在這邊定義了一個(gè)變量隔壁進(jìn)程根本看不見(jiàn)。所以但凡兩個(gè)進(jìn)程需要協(xié)作——比如一個(gè)負(fù)責(zé)采集數(shù)據(jù)、一個(gè)負(fù)責(zé)寫(xiě)數(shù)據(jù)庫(kù)或者一個(gè)負(fù)責(zé)計(jì)算、一個(gè)負(fù)責(zé)渲染界面——就必須借助操作系統(tǒng)提供的“中間通道”來(lái)傳遞信息。這個(gè)通道就是進(jìn)程間通訊IPCInter-Process Communication機(jī)制。我見(jiàn)過(guò)不少項(xiàng)目前期為了圖快兩個(gè)進(jìn)程之間直接用臨時(shí)文件傳數(shù)據(jù)跑起來(lái)看著也沒(méi)問(wèn)題。等到并發(fā)量一上來(lái)文件讀寫(xiě)沖突、數(shù)據(jù)半截寫(xiě)入、清理邏輯遺漏各種問(wèn)題全冒出來(lái)了?；仡^再改成消息隊(duì)列或者共享內(nèi)存改動(dòng)量比一開(kāi)始就選對(duì)方案大得多。所以理解 IPC 不是學(xué)院派的知識(shí)儲(chǔ)備而是實(shí)打?qū)嵱绊懠軜?gòu)穩(wěn)定性的基本功。這篇文章面向的是有一定編程基礎(chǔ)、但沒(méi)系統(tǒng)梳理過(guò) IPC 的開(kāi)發(fā)者。我會(huì)把常見(jiàn)的幾種通訊方式拆開(kāi)講清楚它們各自適合什么場(chǎng)景、底層大概是怎么實(shí)現(xiàn)的、實(shí)際寫(xiě)代碼時(shí)要注意哪些坑。每種方式我都會(huì)給出可運(yùn)行的代碼示例和參數(shù)選擇依據(jù)盡量做到看完就能上手試。2. 主流進(jìn)程間通訊方式全景拆解2.1 管道與命名管道最古老的單向通道管道Pipe是 Unix 系統(tǒng)里最經(jīng)典的 IPC 方式它的本質(zhì)是內(nèi)核維護(hù)的一塊緩沖區(qū)兩個(gè)進(jìn)程分別持有讀端和寫(xiě)端。匿名管道只能用于有親緣關(guān)系的進(jìn)程比如父子進(jìn)程因?yàn)槲募枋龇枰ㄟ^(guò) fork 繼承。命名管道FIFO則通過(guò)文件系統(tǒng)中的一個(gè)特殊文件來(lái)標(biāo)識(shí)無(wú)關(guān)進(jìn)程也能通過(guò)打開(kāi)這個(gè)文件來(lái)通訊。管道的核心特點(diǎn)是單向和字節(jié)流。數(shù)據(jù)寫(xiě)進(jìn)去就是一連串字節(jié)沒(méi)有消息邊界。如果寫(xiě)端一次寫(xiě)了 100 字節(jié)讀端可能分兩次讀到 60 和 40 字節(jié)也可能一次讀到 100 字節(jié)。這一點(diǎn)非常關(guān)鍵很多初學(xué)者在這里翻車(chē)——他們默認(rèn)“寫(xiě)一次就讀一次”結(jié)果數(shù)據(jù)錯(cuò)位。// 匿名管道示例父進(jìn)程寫(xiě)子進(jìn)程讀 #include unistd.h #include stdio.h #include string.h int main() { int fd[2]; pipe(fd); // fd[0]讀端fd[1]寫(xiě)端 pid_t pid fork(); if (pid 0) { close(fd[1]); char buf[128] {0}; read(fd[0], buf, sizeof(buf)); printf(child got: %s\n, buf); close(fd[0]); } else { close(fd[0]); const char *msg hello from parent; write(fd[1], msg, strlen(msg)); close(fd[1]); } return 0; }管道的內(nèi)核緩沖區(qū)默認(rèn)大小是 64KBLinux 下可通過(guò)fcntl的F_SETPIPE_SZ調(diào)整。當(dāng)緩沖區(qū)寫(xiě)滿時(shí)寫(xiě)操作會(huì)阻塞直到讀端取走數(shù)據(jù)。這個(gè)阻塞特性既是優(yōu)點(diǎn)也是缺點(diǎn)優(yōu)點(diǎn)是天然實(shí)現(xiàn)了背壓讀得慢寫(xiě)端就會(huì)等缺點(diǎn)是如果讀端意外退出寫(xiě)端會(huì)收到 SIGPIPE 信號(hào)默認(rèn)行為是進(jìn)程終止。所以實(shí)際項(xiàng)目中一定要處理這個(gè)信號(hào)或者忽略它并檢查 write 的返回值。注意管道寫(xiě)端關(guān)閉后讀端會(huì)讀到 EOFread 返回 0。很多程序忘記判斷這個(gè)返回值導(dǎo)致死循環(huán)。2.2 消息隊(duì)列帶邊界的異步通訊消息隊(duì)列解決了管道“沒(méi)有消息邊界”的問(wèn)題。每條消息是一個(gè)獨(dú)立的數(shù)據(jù)塊接收方一次讀一條不會(huì)出現(xiàn)半截消息。POSIX 消息隊(duì)列通過(guò)mq_open、mq_send、mq_receive這套接口使用System V 消息隊(duì)列則是msgget、msgsnd、msgrcv。兩者思路類似POSIX 接口更現(xiàn)代一些我一般推薦用 POSIX 的。消息隊(duì)列的另一個(gè)優(yōu)勢(shì)是異步。發(fā)送方把消息放進(jìn)隊(duì)列就可以繼續(xù)干活不需要接收方立刻處理。隊(duì)列由內(nèi)核維護(hù)即使接收方進(jìn)程暫時(shí)沒(méi)運(yùn)行消息也不會(huì)丟只要系統(tǒng)沒(méi)重啟。每條消息可以帶優(yōu)先級(jí)高優(yōu)先級(jí)的消息會(huì)排在前面被先取走。// POSIX 消息隊(duì)列示例 #include mqueue.h #include stdio.h #include string.h int main() { struct mq_attr attr {0}; attr.mq_maxmsg 10; // 隊(duì)列最多10條消息 attr.mq_msgsize 256; // 每條消息最大256字節(jié) mqd_t mq mq_open(/test_queue, O_CREAT | O_RDWR, 0644, attr); const char *msg order:1001; mq_send(mq, msg, strlen(msg), 1); // 優(yōu)先級(jí)1 char buf[256] {0}; unsigned int prio; ssize_t n mq_receive(mq, buf, sizeof(buf), prio); printf(received: %s, prio%u\n, buf, prio); mq_close(mq); mq_unlink(/test_queue); return 0; }參數(shù)選擇上mq_maxmsg和mq_msgsize需要根據(jù)業(yè)務(wù)峰值來(lái)定。隊(duì)列滿了之后mq_send默認(rèn)會(huì)阻塞也可以設(shè)置非阻塞模式返回 EAGAIN。我的經(jīng)驗(yàn)是隊(duì)列長(zhǎng)度至少要是消費(fèi)者單次處理能力的 3 到 5 倍否則突發(fā)流量一來(lái)就堵住了。但也不能無(wú)限大否則內(nèi)存占用不可控而且消息積壓太多會(huì)導(dǎo)致處理延遲飆升。2.3 共享內(nèi)存最快的通訊方式共享內(nèi)存是所有 IPC 方式里速度最快的原因很簡(jiǎn)單它壓根不涉及數(shù)據(jù)拷貝。兩個(gè)進(jìn)程把同一塊物理內(nèi)存映射到各自的地址空間一個(gè)寫(xiě)一個(gè)讀數(shù)據(jù)直接在內(nèi)存里流轉(zhuǎn)。其他方式比如管道、消息隊(duì)列數(shù)據(jù)都要從用戶空間拷到內(nèi)核空間再?gòu)膬?nèi)核空間拷到對(duì)方用戶空間兩次拷貝的開(kāi)銷在高頻場(chǎng)景下非?？捎^。但共享內(nèi)存的代價(jià)是沒(méi)有同步機(jī)制。多個(gè)進(jìn)程同時(shí)讀寫(xiě)同一塊內(nèi)存必然出現(xiàn)競(jìng)態(tài)條件。所以共享內(nèi)存幾乎總是和信號(hào)量Semaphore或互斥鎖配合使用。另外共享內(nèi)存沒(méi)有消息邊界你需要自己設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)來(lái)劃分區(qū)域。// POSIX 共享內(nèi)存 信號(hào)量示例 #include sys/mman.h #include semaphore.h #include fcntl.h #include stdio.h #include string.h #include unistd.h typedef struct { sem_t lock; char data[256]; } SharedBuf; int main() { int fd shm_open(/test_shm, O_CREAT | O_RDWR, 0644); ftruncate(fd, sizeof(SharedBuf)); SharedBuf *buf mmap(NULL, sizeof(SharedBuf), PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); sem_init(buf-lock, 1, 1); // 進(jìn)程間共享初值1 if (fork() 0) { sem_wait(buf-lock); strcpy(buf-data, written by child); sem_post(buf-lock); } else { sleep(1); sem_wait(buf-lock); printf(parent read: %s\n, buf-data); sem_post(buf-lock); } munmap(buf, sizeof(SharedBuf)); shm_unlink(/test_shm); return 0; }共享內(nèi)存的坑主要集中在同步上。我踩過(guò)的一個(gè)典型問(wèn)題是生產(chǎn)者寫(xiě)完數(shù)據(jù)后先sem_post再更新長(zhǎng)度字段消費(fèi)者拿到鎖后讀到的長(zhǎng)度是舊值。正確的順序應(yīng)該是先更新所有數(shù)據(jù)字段最后才釋放信號(hào)量。這個(gè)順序問(wèn)題在壓力測(cè)試下才會(huì)暴露平時(shí)跑單條數(shù)據(jù)根本看不出來(lái)。2.4 信號(hào)輕量但信息量有限信號(hào)Signal嚴(yán)格來(lái)說(shuō)不算“通訊”更像是一種通知機(jī)制。它只能傳遞一個(gè)整數(shù)編號(hào)不能攜帶復(fù)雜數(shù)據(jù)。常見(jiàn)的用途是通知進(jìn)程某個(gè)事件發(fā)生了比如子進(jìn)程退出SIGCHLD、定時(shí)器到期SIGALRM、用戶中斷SIGINT。信號(hào)的處理函數(shù)要盡可能簡(jiǎn)單因?yàn)樾盘?hào)可能在任何時(shí)刻打斷主流程。在信號(hào)處理函數(shù)里調(diào)用printf、malloc這類非異步信號(hào)安全的函數(shù)是危險(xiǎn)行為可能導(dǎo)致死鎖。正確的做法是在處理函數(shù)里只設(shè)置一個(gè)volatile sig_atomic_t標(biāo)志位主循環(huán)檢查這個(gè)標(biāo)志再執(zhí)行實(shí)際邏輯。#include signal.h #include stdio.h #include unistd.h volatile sig_atomic_t got_signal 0; void handler(int sig) { got_signal sig; } int main() { signal(SIGUSR1, handler); printf(waiting for signal...\n); while (!got_signal) { pause(); // 等待信號(hào) } printf(received signal %d\n, got_signal); return 0; }信號(hào)不適合做數(shù)據(jù)傳輸?shù)谶M(jìn)程生命周期管理、超時(shí)控制、優(yōu)雅退出這些場(chǎng)景里非常有用。比如服務(wù)進(jìn)程收到 SIGTERM 后應(yīng)該停止接受新請(qǐng)求、處理完手頭任務(wù)再退出這個(gè)流程就依賴信號(hào)來(lái)觸發(fā)。2.5 套接字跨主機(jī)的通用方案套接字Socket最初是為網(wǎng)絡(luò)通訊設(shè)計(jì)的但本機(jī)進(jìn)程之間也可以用 Unix Domain SocketUDS。UDS 不走網(wǎng)絡(luò)協(xié)議棧性能比 TCP 回環(huán)高不少而且支持傳遞文件描述符這種特殊能力。如果兩個(gè)進(jìn)程可能部署到不同機(jī)器上那從一開(kāi)始就用 TCP Socket 是更穩(wěn)妥的選擇省得后期遷移時(shí)改代碼。套接字的優(yōu)勢(shì)是通用性和成熟度。各種編程語(yǔ)言、各種框架對(duì)它的支持都很好調(diào)試工具也豐富。缺點(diǎn)是相比共享內(nèi)存有額外的協(xié)議棧開(kāi)銷相比消息隊(duì)列有連接管理的復(fù)雜度。不過(guò)對(duì)于大多數(shù)業(yè)務(wù)系統(tǒng)來(lái)說(shuō)這點(diǎn)開(kāi)銷完全可以接受。# Python Unix Domain Socket 服務(wù)端示例 import socket import os sock_path /tmp/test.sock if os.path.exists(sock_path): os.unlink(sock_path) server socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) server.bind(sock_path) server.listen(5) conn, _ server.accept() data conn.recv(1024) print(fserver got: {data.decode()}) conn.sendall(back) conn.close() server.close()2.6 各方式對(duì)比與選型參考通訊方式數(shù)據(jù)傳輸同步機(jī)制跨主機(jī)性能典型場(chǎng)景匿名管道字節(jié)流阻塞讀寫(xiě)否中父子進(jìn)程簡(jiǎn)單傳遞命名管道字節(jié)流阻塞讀寫(xiě)否中無(wú)關(guān)進(jìn)程單向通訊消息隊(duì)列消息阻塞/非阻塞否中異步任務(wù)分發(fā)共享內(nèi)存原始內(nèi)存需自行實(shí)現(xiàn)否最高高頻大數(shù)據(jù)量交換信號(hào)整數(shù)異步中斷否高事件通知Unix Socket字節(jié)流/消息阻塞/非阻塞否較高本機(jī)服務(wù)通訊TCP Socket字節(jié)流阻塞/非阻塞是較低跨主機(jī)通訊選型的核心判斷依據(jù)是三個(gè)問(wèn)題數(shù)據(jù)量大不大、實(shí)時(shí)性要求高不高、進(jìn)程是否在同一臺(tái)機(jī)器上。數(shù)據(jù)量大且同機(jī)優(yōu)先共享內(nèi)存需要異步解耦選消息隊(duì)列可能跨機(jī)直接上 Socket只是通知事件信號(hào)就夠了。3. 實(shí)操落地從零搭建一個(gè)多進(jìn)程通訊系統(tǒng)3.1 場(chǎng)景定義與架構(gòu)設(shè)計(jì)假設(shè)我們要做一個(gè)日志采集系統(tǒng)一個(gè)采集進(jìn)程負(fù)責(zé)從多個(gè)來(lái)源收集日志一個(gè)處理進(jìn)程負(fù)責(zé)解析和過(guò)濾一個(gè)寫(xiě)入進(jìn)程負(fù)責(zé)落盤(pán)。三個(gè)進(jìn)程之間需要傳遞日志條目每條日志大概 1KB 左右峰值每秒 5000 條。算一下帶寬5000 × 1KB 5MB/s。這個(gè)量級(jí)用消息隊(duì)列完全扛得住但考慮到后續(xù)可能擴(kuò)展到每秒幾萬(wàn)條我選擇共享內(nèi)存 信號(hào)量的方案做進(jìn)程間數(shù)據(jù)傳遞用消息隊(duì)列做控制指令的下發(fā)。這樣數(shù)據(jù)通道和控制通道分離互不干擾。架構(gòu)上采集進(jìn)程和處理進(jìn)程之間用一塊共享內(nèi)存環(huán)形緩沖區(qū)采集進(jìn)程是生產(chǎn)者處理進(jìn)程是消費(fèi)者。處理進(jìn)程和寫(xiě)入進(jìn)程之間同樣用環(huán)形緩沖區(qū)?？刂浦噶畋热纭皶和２杉薄罢{(diào)整過(guò)濾規(guī)則”通過(guò)消息隊(duì)列廣播。3.2 環(huán)形緩沖區(qū)的設(shè)計(jì)與實(shí)現(xiàn)環(huán)形緩沖區(qū)是共享內(nèi)存場(chǎng)景下最常用的數(shù)據(jù)結(jié)構(gòu)。它本質(zhì)上是一個(gè)固定大小的數(shù)組加上讀指針和寫(xiě)指針。生產(chǎn)者往寫(xiě)指針位置寫(xiě)數(shù)據(jù)寫(xiě)完移動(dòng)寫(xiě)指針消費(fèi)者從讀指針位置讀數(shù)據(jù)讀完移動(dòng)讀指針。指針到達(dá)末尾就繞回開(kāi)頭。關(guān)鍵設(shè)計(jì)點(diǎn)有幾個(gè)。第一需要區(qū)分“空”和“滿”兩種狀態(tài)。如果讀指針等于寫(xiě)指針可能是空也可能是滿。常見(jiàn)的做法是留一個(gè)空位不存數(shù)據(jù)或者額外維護(hù)一個(gè)計(jì)數(shù)器。我選擇用計(jì)數(shù)器因?yàn)楦庇^。第二讀寫(xiě)指針的更新必須是原子的。在共享內(nèi)存場(chǎng)景下多個(gè)進(jìn)程同時(shí)操作同一塊內(nèi)存需要用信號(hào)量保護(hù)。但每次都加鎖解鎖開(kāi)銷不小可以優(yōu)化成只在指針更新時(shí)加鎖數(shù)據(jù)拷貝本身不需要鎖。#define BUF_SIZE 1024 #define SLOT_SIZE 2048 typedef struct { sem_t mutex; sem_t not_empty; sem_t not_full; int read_idx; int write_idx; int count; char slots[BUF_SIZE][SLOT_SIZE]; } RingBuffer;這里用了三個(gè)信號(hào)量mutex保護(hù)指針操作的互斥not_empty表示有數(shù)據(jù)可讀not_full表示有空位可寫(xiě)。生產(chǎn)者寫(xiě)之前sem_wait(not_full)寫(xiě)完后sem_post(not_empty)。消費(fèi)者反過(guò)來(lái)。這種設(shè)計(jì)下緩沖滿時(shí)生產(chǎn)者自動(dòng)阻塞緩沖空時(shí)消費(fèi)者自動(dòng)阻塞不需要忙等待。3.3 生產(chǎn)者與消費(fèi)者的完整代碼// producer.c #include sys/mman.h #include semaphore.h #include fcntl.h #include string.h #include stdio.h #include unistd.h // RingBuffer 定義同上此處省略 int main() { int fd shm_open(/log_ring, O_CREAT | O_RDWR, 0644); ftruncate(fd, sizeof(RingBuffer)); RingBuffer *rb mmap(NULL, sizeof(RingBuffer), PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); sem_init(rb-mutex, 1, 1); sem_init(rb-not_empty, 1, 0); sem_init(rb-not_full, 1, BUF_SIZE); for (int i 0; i 10000; i) { char log[SLOT_SIZE]; snprintf(log, sizeof(log), log entry %d, i); sem_wait(rb-not_full); sem_wait(rb-mutex); int idx rb-write_idx; memcpy(rb-slots[idx], log, strlen(log) 1); rb-write_idx (idx 1) % BUF_SIZE; rb-count; sem_post(rb-mutex); sem_post(rb-not_empty); } munmap(rb, sizeof(RingBuffer)); return 0; }消費(fèi)者代碼對(duì)稱把not_full和not_empty互換讀操作改成從read_idx取數(shù)據(jù)。這里有個(gè)細(xì)節(jié)memcpy的長(zhǎng)度用strlen(log) 1是為了把結(jié)尾的\0也拷過(guò)去否則消費(fèi)者讀到的字符串沒(méi)有終止符。如果傳輸?shù)氖嵌M(jìn)制數(shù)據(jù)就需要在 slot 頭部額外存一個(gè)長(zhǎng)度字段。3.4 控制通道的消息隊(duì)列實(shí)現(xiàn)控制指令的數(shù)據(jù)量很小但要求可靠送達(dá)用消息隊(duì)列正合適。定義一個(gè)簡(jiǎn)單的指令結(jié)構(gòu)typedef struct { int cmd_type; // 1暫停, 2恢復(fù), 3調(diào)整過(guò)濾 int param; } ControlMsg;發(fā)送方mq_send接收方在主循環(huán)里用非阻塞的mq_receive輪詢。為什么用非阻塞因?yàn)橄M(fèi)者主要工作是處理數(shù)據(jù)不能阻塞在控制指令上。每處理完一批數(shù)據(jù)就檢查一次控制隊(duì)列有指令就執(zhí)行沒(méi)有就繼續(xù)。實(shí)操心得消息隊(duì)列的mq_msgsize要設(shè)得比實(shí)際結(jié)構(gòu)體大一點(diǎn)留出對(duì)齊和擴(kuò)展空間。我有一次設(shè)得剛剛好后來(lái)結(jié)構(gòu)體加了一個(gè)字段發(fā)送直接失敗排查了半天才發(fā)現(xiàn)是消息大小超了。3.5 優(yōu)雅退出與資源清理多進(jìn)程系統(tǒng)最容易被忽視的就是退出流程。如果生產(chǎn)者直接kill掉消費(fèi)者可能永遠(yuǎn)阻塞在sem_wait(not_empty)上。正確的做法是定義一個(gè)特殊的“毒丸”消息生產(chǎn)者退出前發(fā)送消費(fèi)者收到后知道該結(jié)束了。共享內(nèi)存和信號(hào)量的清理也要注意。shm_unlink只是刪除名字已經(jīng)映射的內(nèi)存仍然有效直到所有進(jìn)程munmap。信號(hào)量要用sem_destroy銷毀。如果進(jìn)程異常退出沒(méi)來(lái)得及清理下次啟動(dòng)時(shí)shm_open會(huì)打開(kāi)舊的共享內(nèi)存里面的信號(hào)量狀態(tài)可能是錯(cuò)的。我的做法是啟動(dòng)時(shí)先嘗試shm_unlink再重新創(chuàng)建確保干凈狀態(tài)。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 死鎖最常見(jiàn)的翻車(chē)現(xiàn)場(chǎng)死鎖在多進(jìn)程通訊里太常見(jiàn)了。典型場(chǎng)景是進(jìn)程 A 持有鎖 1 等待鎖 2進(jìn)程 B 持有鎖 2 等待鎖 1。在共享內(nèi)存 信號(hào)量的方案里如果加鎖順序不一致死鎖幾乎必然發(fā)生。排查死鎖的第一步是確認(rèn)現(xiàn)象進(jìn)程卡住不動(dòng)CPU 占用為 0strace顯示卡在sem_wait或futex系統(tǒng)調(diào)用上。這時(shí)候可以用gdbattach 上去看各個(gè)線程的調(diào)用棧找到各自持有什么鎖、等待什么鎖。預(yù)防死鎖的原則很簡(jiǎn)單所有進(jìn)程按相同順序獲取鎖。如果做不到就設(shè)置超時(shí)。POSIX 信號(hào)量沒(méi)有內(nèi)置超時(shí)但可以用sem_timedwait替代sem_wait超時(shí)后返回錯(cuò)誤進(jìn)程可以釋放已持有的鎖再重試。死鎖現(xiàn)象可能原因排查手段解決方案進(jìn)程卡住CPU 0%循環(huán)等待鎖gdb 查看調(diào)用棧統(tǒng)一加鎖順序進(jìn)程卡住CPU 100%忙等待top 查看改用阻塞信號(hào)量間歇性卡頓鎖競(jìng)爭(zhēng)激烈perf 采樣減小臨界區(qū)啟動(dòng)即卡住信號(hào)量初值錯(cuò)誤檢查 sem_init確認(rèn)初值語(yǔ)義4.2 數(shù)據(jù)錯(cuò)亂邊界與同步問(wèn)題數(shù)據(jù)錯(cuò)亂的根源通常有兩個(gè)一是消息邊界處理不當(dāng)二是同步不到位。管道和 Socket 是字節(jié)流必須自己定義消息邊界。常見(jiàn)做法是長(zhǎng)度前綴先發(fā) 4 字節(jié)表示消息長(zhǎng)度再發(fā)消息體。接收方先讀 4 字節(jié)解析出長(zhǎng)度再按長(zhǎng)度讀消息體。共享內(nèi)存場(chǎng)景下的數(shù)據(jù)錯(cuò)亂更隱蔽。我遇到過(guò)一次生產(chǎn)者寫(xiě)完數(shù)據(jù)后釋放信號(hào)量消費(fèi)者拿到信號(hào)量讀數(shù)據(jù)但讀到的數(shù)據(jù)不完整。原因是編譯器優(yōu)化導(dǎo)致寫(xiě)操作被重排信號(hào)量釋放跑到了數(shù)據(jù)寫(xiě)入之前。解決辦法是在關(guān)鍵位置加內(nèi)存屏障或者用sem_post本身的內(nèi)存語(yǔ)義——POSIX 標(biāo)準(zhǔn)規(guī)定sem_post之前的寫(xiě)操作對(duì)sem_wait之后的讀操作可見(jiàn)但前提是編譯器和 CPU 都遵守這個(gè)順序。保險(xiǎn)起見(jiàn)可以在寫(xiě)數(shù)據(jù)和sem_post之間加__sync_synchronize()。4.3 性能瓶頸拷貝與上下文切換IPC 的性能瓶頸通常不在數(shù)據(jù)量本身而在數(shù)據(jù)拷貝次數(shù)和進(jìn)程上下文切換。管道和消息隊(duì)列都有兩次拷貝用戶到內(nèi)核、內(nèi)核到用戶共享內(nèi)存零拷貝但需要同步開(kāi)銷。如果發(fā)現(xiàn) IPC 成為瓶頸先用perf定位是拷貝耗時(shí)還是鎖競(jìng)爭(zhēng)。優(yōu)化方向有幾個(gè)。第一增大批量。一次傳 1KB 傳 1000 次不如一次傳 1MB 傳 1 次。第二減少鎖粒度。把一個(gè)大鎖拆成多個(gè)小鎖不同區(qū)域的數(shù)據(jù)用不同的鎖。第三考慮無(wú)鎖隊(duì)列。在單生產(chǎn)者單消費(fèi)者場(chǎng)景下可以用原子操作實(shí)現(xiàn)無(wú)鎖環(huán)形緩沖區(qū)完全避免信號(hào)量開(kāi)銷。// 單生產(chǎn)者單消費(fèi)者無(wú)鎖隊(duì)列的核心邏輯 // 生產(chǎn)者 int write_idx atomic_load(rb-write_idx); int next (write_idx 1) % BUF_SIZE; if (next ! atomic_load(rb-read_idx)) { memcpy(rb-slots[write_idx], data, len); atomic_store(rb-write_idx, next); }無(wú)鎖方案性能確實(shí)好但正確性驗(yàn)證很麻煩。如果不是對(duì)性能有極致要求我一般還是推薦用信號(hào)量代碼可讀性和可維護(hù)性都更好。4.4 資源泄漏文件描述符與共享內(nèi)存多進(jìn)程程序跑久了/dev/shm下堆滿共享內(nèi)存文件、文件描述符耗盡這類問(wèn)題很常見(jiàn)。排查方法是定期檢查ls /dev/shm和lsof -p pid。共享內(nèi)存泄漏通常是因?yàn)閟hm_unlink沒(méi)調(diào)用或者調(diào)用時(shí)機(jī)不對(duì)。文件描述符泄漏多半是open之后忘記close或者fork之后子進(jìn)程繼承了不需要的 fd。注意fork之后子進(jìn)程會(huì)繼承父進(jìn)程的所有文件描述符。如果父進(jìn)程打開(kāi)了監(jiān)聽(tīng) Socket子進(jìn)程不關(guān)掉的話父進(jìn)程關(guān)閉后端口仍然被占用。正確做法是子進(jìn)程啟動(dòng)后立即關(guān)閉所有不需要的 fd。4.5 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因快速驗(yàn)證解決方向讀端一直阻塞寫(xiě)端未寫(xiě)入或已關(guān)閉檢查寫(xiě)端狀態(tài)處理 EOF 返回值數(shù)據(jù)截?cái)嘞⑦吔缥刺幚泶蛴∶看巫x取長(zhǎng)度加長(zhǎng)度前綴共享內(nèi)存打開(kāi)失敗權(quán)限或殘留文件ls /dev/shm清理后重建信號(hào)量值異常異常退出未清理sem_getvalue啟動(dòng)時(shí)重置吞吐量上不去鎖競(jìng)爭(zhēng)或拷貝過(guò)多perf top批量傳輸或改無(wú)鎖進(jìn)程無(wú)法退出阻塞在信號(hào)量gdb 調(diào)用棧毒丸消息或超時(shí)5. 進(jìn)階話題選型之外的工程考量5.1 安全性共享內(nèi)存的權(quán)限控制共享內(nèi)存和消息隊(duì)列都通過(guò)文件系統(tǒng)路徑來(lái)標(biāo)識(shí)權(quán)限設(shè)置不當(dāng)會(huì)導(dǎo)致其他用戶進(jìn)程也能訪問(wèn)。shm_open的 mode 參數(shù)要嚴(yán)格設(shè)置一般用 0600 只允許創(chuàng)建者讀寫(xiě)。消息隊(duì)列同理mq_open的 mode 不要圖省事給 0666。如果確實(shí)需要跨用戶通訊應(yīng)該通過(guò)權(quán)限組來(lái)管理而不是放開(kāi)全局權(quán)限。另外共享內(nèi)存里的數(shù)據(jù)在進(jìn)程退出后可能仍然留在物理內(nèi)存中如果包含敏感信息需要在退出前主動(dòng)清零。memset可能被編譯器優(yōu)化掉用explicit_bzero或者volatile指針寫(xiě)入更可靠。5.2 可觀測(cè)性如何監(jiān)控 IPC 狀態(tài)生產(chǎn)環(huán)境里IPC 通道的健康狀況需要能監(jiān)控。共享內(nèi)存環(huán)形緩沖區(qū)可以暴露幾個(gè)指標(biāo)當(dāng)前隊(duì)列深度、歷史最大深度、生產(chǎn)速率、消費(fèi)速率。這些指標(biāo)可以通過(guò)一個(gè)只讀的共享內(nèi)存區(qū)域暴露給監(jiān)控進(jìn)程或者定期寫(xiě)入日志。消息隊(duì)列可以用mq_getattr獲取當(dāng)前隊(duì)列中的消息數(shù)量。如果隊(duì)列深度持續(xù)增長(zhǎng)說(shuō)明消費(fèi)者跟不上需要擴(kuò)容或優(yōu)化。如果隊(duì)列長(zhǎng)期為空說(shuō)明生產(chǎn)者是瓶頸。5.3 跨語(yǔ)言場(chǎng)景的兼容性實(shí)際項(xiàng)目里生產(chǎn)者和消費(fèi)者可能是不同語(yǔ)言寫(xiě)的。比如采集端用 C處理端用 Python。這時(shí)候共享內(nèi)存的結(jié)構(gòu)體定義必須嚴(yán)格對(duì)齊包括字段順序、類型大小、字節(jié)序。C 的struct默認(rèn)會(huì)有填充字節(jié)Python 的ctypes需要顯式聲明相同的布局。import ctypes class RingBuffer(ctypes.Structure): _fields_ [ (read_idx, ctypes.c_int), (write_idx, ctypes.c_int), (count, ctypes.c_int), (slots, ctypes.c_char * (1024 * 2048)), ]跨語(yǔ)言場(chǎng)景下消息隊(duì)列和 Socket 通常比共享內(nèi)存更省心因?yàn)榍罢哂忻鞔_的序列化邊界后者需要手動(dòng)保證內(nèi)存布局一致。如果團(tuán)隊(duì)里沒(méi)有同時(shí)精通兩種語(yǔ)言內(nèi)存模型的人我建議優(yōu)先選消息隊(duì)列。5.4 容器環(huán)境下的注意事項(xiàng)容器里跑多進(jìn)程 IPC 有幾個(gè)額外坑。第一/dev/shm默認(rèn)大小可能只有 64MB共享內(nèi)存需求大的話需要顯式掛載更大的 tmpfs。第二容器的 PID 命名空間隔離可能導(dǎo)致信號(hào)發(fā)送失敗需要確認(rèn)進(jìn)程在同一個(gè)命名空間內(nèi)。第三容器重啟后共享內(nèi)存和消息隊(duì)列都會(huì)丟失程序要能處理首次創(chuàng)建和已存在兩種情況。# 查看容器內(nèi) /dev/shm 大小 df -h /dev/shm # 啟動(dòng)容器時(shí)指定大小 # docker run --shm-size256m ...這些細(xì)節(jié)在開(kāi)發(fā)環(huán)境往往不會(huì)暴露一到生產(chǎn)容器里就出問(wèn)題。我的習(xí)慣是在代碼啟動(dòng)階段就檢查/dev/shm的可用空間不夠就打印明確的錯(cuò)誤信息而不是等到運(yùn)行中才失敗。6. 一些個(gè)人體會(huì)進(jìn)程間通訊這塊內(nèi)容剛學(xué)的時(shí)候覺(jué)得每種方式都差不多無(wú)非是換個(gè) API 調(diào)。真正做過(guò)幾個(gè)項(xiàng)目之后才發(fā)現(xiàn)選型只是第一步后面同步、邊界、清理、監(jiān)控每一個(gè)環(huán)節(jié)都有講究。我自己的經(jīng)驗(yàn)是能用消息隊(duì)列解決的就別上共享內(nèi)存共享內(nèi)存的性能優(yōu)勢(shì)只有在數(shù)據(jù)量確實(shí)很大、頻率確實(shí)很高的時(shí)候才體現(xiàn)得出來(lái)而它帶來(lái)的同步復(fù)雜度是實(shí)打?qū)嵉?。另外不管選哪種方式一定要在開(kāi)發(fā)階段就寫(xiě)好壓力測(cè)試和異常測(cè)試。正常流程跑通不代表沒(méi)問(wèn)題進(jìn)程被 kill、磁盤(pán)滿、內(nèi)存不足這些異常場(chǎng)景才是真正考驗(yàn)設(shè)計(jì)的地方。我踩過(guò)的坑里十有八九都是在異常路徑上。最后分享一個(gè)小技巧如果拿不準(zhǔn)選哪種 IPC先用 Socket 把功能跑通因?yàn)?Socket 的調(diào)試工具最豐富出了問(wèn)題最容易定位。等系統(tǒng)穩(wěn)定了如果性能確實(shí)有瓶頸再針對(duì)性地替換成共享內(nèi)存或消息隊(duì)列。過(guò)早優(yōu)化通訊方式往往是在給自己挖坑。