問題
可能是由於經驗太少,工作中經常會遇到問題,探究和解決問題的過程總想記錄一下,所以我寫博客經常是問題驅動,首先介紹一下今天要解決的問題:
服務耦合
我們在開發過程中可能會遇到這樣的情況:
- 進程依賴於某服務,所以把服務耦合在進程代碼中;
- 服務初始化耗時長,拖慢了進程啟動時間;
- 服務運行要占用大量內存,多進程時內存損耗嚴重。
如我上篇文章 小時到分鍾 - 一步步優化巨量關鍵詞的匹配 中介紹的文本匹配服務,它是消息處理流程中的一環,被多個消息處理進程依賴,每次初始化進程要 6秒
左右時間構造 Trie 樹,而且服務讀取關鍵詞大文件、使用樹組構造 Trie 樹,會占用大量(目前設置為 256M
)內存。
我已經把進程寫成了守護進程的形式,讓它們長時間執行,雖然不用更多地考慮初始化時間了,但占用內存量巨大的問題沒有辦法。如果關鍵詞量再大一些,一台機器上面跑十來個消息處理進程后就干不了其他了。
而且,如果有需求讓我把文本匹配服務封裝為接口給外部調用呢?我們知道,web 服務時,每一個請求處理進程的生存周期是從受理請求到響應結束,如果每次請求都用大量內存和時間來初始化服務,那接口響應時間和服務器壓力可想而知。
服務抽取
這樣,服務形式必須要改變,我們希望這個文本匹配這個服務能做到:
- 隨調隨走,不依賴,不再與“消息處理服務”耦合在一起;
- 一次初始化,進程運行期間持續提供服務;
- 同步響應,高效而准確,最好能不用各種鎖來保持資源占有;
解決辦法也很簡單,就是把這個文本匹配的服務抽取出來,單獨作為一個守護進程來運行,像一個特殊的服務器,多個“消息處理服務”在有需要時能調用此服務進程。
現在,我們需要考慮文本匹配服務進程如何與外界通信,接受匹配請求,響應匹配結果。繞來繞去,問題還是回到了 進程間通信
。
Unix Domain Sockets
進程間通信
進程間通信(IPC,Inter-Process Communication),指至少兩個進程或線程間傳送數據或信號的一些技術或方法。進程是計算機系統分配資源的最小單位(嚴格說來是線程)。每個進程都有自己的一部分獨立的系統資源,彼此是隔離的。為了能使不同的進程互相訪問資源並進行協調工作,才有了進程間通信。
進程間通信的方式有很多,網上對此介紹的也很多,下面根據文章的需求來分析一下這些方式:
- 管道:管道是Unix最初的IPC形式,但它只能用於具有共同祖先進程的各個進程,無法用於在沒有親緣關系的進程。如果使用它,需要在“消息處理服務”中啟動“文本匹配服務”,跟原來差別不大。
- 命名管道:也被稱為有名管道,它在Unix稱為
FIFO
,它通過一個文件來進行進程間數據交互,但服務於多個進程時,需要添加鎖來保證原子性,從而避免寫入和讀取不對應。 - 信號和信號量:用於進程/線程事件級的通信,但它們能交流的信息太少。
- 消息隊列和共享內存:都是通過一個公共內存介質來進行通信,我之前也寫過一篇關於PHP進程間使用消息隊列和共享內存通信的文章: 從並發處理談PHP進程間通信(二)System V IPC,但它們在通信上都是異步的,處理多個進程時無法分辨請求和對應的響應信息。
- socket:通過Unix封裝好的網絡API來進行通信,像數據庫、服務器都是通過這種方式實現,它們也能提供本地服務。不過網絡socket固然能使用,但是要面臨着數據包裝和網絡調用開銷,也不是完美的選擇。
簡單介紹
當然還是有完美的方式的,這就是今天的主角 - Unix Domain Sockets
,它可以理解為一種特殊的 Socket,但它不需要經過網絡協議棧,不需要打包拆包、計算校驗和、維護序號和應答等,只是將應用層數據從一個進程拷貝到另一個進程,所以在系統內通信效率更高。而且免去了網絡問題,它也更能保證消息的完整性,既不會丟失也不會順序錯亂。
作為特殊的 Socket,它的創建、調用方式和網絡 Socket 一樣,一次完整的交互,服務端都要經過create、bind、listen、accept、read、write
,客戶端要通過create、connect、write、read
。與普通 Socket 不同的是它綁定一個系統內的文件,而不是 IP 和端口。
創建代碼這里不再多介紹了,之前的一篇文章 用C寫一個web服務器(一) 基礎功能 的功能實現
小節里詳細介紹了 socket 通信的具體步驟,C 系的語言都是相似的,很容易理解。
適用場景
Unix Domain Sockets 真的是進程間通信的一個重型武器,用它可以快速實現進程間的數據、信息交互,而且不需要鎖等繁雜操作,也不用考慮效率,可謂是簡單高效。
當然,“重型武器” 的在各種場景下也有適合不適合。Unix Domain Sockets適用於以下場景:
- 服務長時間存在。 Unix Domain Sockets 的服務端是個服務器一樣的存在,在守護進程中,它阻塞並等待客戶端連接的特性可以被充分利用。
- 一服務器多客戶端。它能通過 Socket 的文件描述符來區分不同的客戶端,避免資源之間的鎖操作。
- 同一系統內。它只能在同一系統內進行進程數據復制,跨系統請使用傳統 Sockets。
代碼實現
接下來要 show code 了,不過學 PHP 的都知道,PHP 不太適合處理 CPU 密集形的任務,我剛好學了點 Go,一時手癢,就用 Go 實現了下 Trie 樹,所以才牽扯到 PHP 和 Go 之間的通信,有了今天的文章。當然介紹的方法,並不只適合 PHP 與 Go 通信,其他語言也可以,至少 C系語言中是通用的。
完整代碼見 IPC-GitHub-枕邊書,里面還附帶了一份隨手寫的 PHP 版本的 Unix Domain Sockets server 端。
Go 實現的 Trie 樹
Trie樹不再是今天的主題,這里介紹一下數據結構和需要注意的點。
// trie樹結點定義
type Node struct {
depth int
children map[int32]Node // 用map實現key-value型的 字符-節點 對應
}
需要注意:
- 使用 slice 的
append()
函數保存遞增的匹配結果時,有可能由於 slice 容量不夠而重新分配地址,所以要傳入 slice 的地址來保存遞增后的匹配結果結果,*result = append(*result, word)
,最后再將遞增之后的 slice 地址傳回。 - 由於 Go 中的編碼統一使用的
utf-8
,不用像 PHP 一樣判斷字符的邊界,所以在進行關鍵詞拆散和消息拆散時,直接使用int32()
方法將關鍵詞和消息都轉換為成員為int32
類型的 slice,匹配過程中就使用int32
類型的數字來代表這個中文字符,匹配完成后再使用fmt.Printf("%c", int32)
將其轉換為中文。
Go Server
Go 中創建一個 socket 並使用的步驟非常簡單,只是 Go 沒有異常,判斷 error 會比較惡心一點,不知道有沒有大神有更好的寫法。下面為了精簡,把 error 全置空了。
// 創建一個Unix domain soceket
socket, _ := net.Listen("unix", "/tmp/keyword_match.sock")
// 關閉時刪除綁定的文件
defer syscall.Unlink("/tmp/keyword_match.sock")
// 無限循環監聽和受理客戶端請求
for {
client, _ := socket.Accept()
buf := make([]byte, 1024)
data_len, _ := client.Read(buf)
data := buf[0:data_len]
msg := string(data)
matched := trie.Match(tree, msg)
response := []byte("[]") // 給響應一個默認值
if len(matched) > 0 {
json_str, _ := json.Marshal(matched)
response = []byte(string(json_str))
}
_, _ = client.Write(response)
}
PHP Client
下面是 PHP 實現的客戶端:
$msg = "msg";
// 創建 連接 發送消息 接收響應 關閉連接
$socket = socket_create(AF_UNIX, SOCK_STREAM, 0);
socket_connect($socket, '/tmp/keyword_match.sock');
socket_send($socket, $msg, strlen($msg), 0);
$response = socket_read($socket, 1024);
socket_close($socket);
// 有值則為匹配成功
if (strlen($response) > 3) {
var_dump($response);
}
小結
效率
這里總結一下這套設計的效率表現:
純粹用 Go 進行文本關鍵詞匹配,一千條數據運行一秒多,差不多是 PHP 效率的兩倍。不過說好的 8倍效率呢?果然測評都是騙人的。當然,也可能是我寫法有問題或者 Trie 樹不在 Go 的發揮范圍之內。然后是 PHP 使用 Unix Domain Socket 調用 Go 服務的耗時,可能是進程間復制數據耗時或 PHP 拖了后腿,3秒多一點,跟純 PHP 腳本差不多。
雜談
用 PHP 的都知道,PHP 因為解釋型語言的特性和其高度的封裝,導致其雖然在開發上速度很快,可是執行與其他語言相比略差。對此,業界的 FB 有 HHVM,PHP7 有 opcache 新特性,據說還要在 PHP8 添加 JIT,用以彌補其先天硬傷。
不過,對於開發者,特別是跟我一樣對於效率有執著追求的人來說,在了解使用 PHP 的新特性之外,自己再掌握一門較高執行效率、開發效率略低的語言,用來寫一些高計算量,邏輯單一的代碼,與 PHP 互補或許會更好一點。
於是,在考慮良久,也見識了各種 Go 的支持者和反對者之間的撕逼后,我覺得還是要相信一下谷歌爸爸,畢竟也沒什么其他我覺得可選的語言了。PS:請不要針對這一段發表意見,謝謝:)
另外C呢,雖然暫時開發中用不到,可是畢竟是當代N多語言的起源,偶爾寫寫數據結構、算法什么的以免生銹。而且學了些C,從 PHP 到 Go,切換起來還略有些得心應手的感覺~
關於本文有什么問題可以在下面留言交流,如果您覺得本文對您有幫助,可以點擊下面的 推薦 支持一下我。博客一直在更新,歡迎 關注 。