OpenResty 阻塞操作

OpenResty 的誕生，一直對外宣傳是同步非阻塞(100% non-blocking)的?；谑录ㄖ?Nginx 給我們帶來了足夠強悍的高并發(fā)支持，但是也對我們的編碼有特殊要求。這個特殊要求就是我們的代碼，也必須是非阻塞的。如果你的服務端編程生涯一開始就是從異步框架開始的，恭喜你了。但如果你的編程生涯是從同步框架過來的，而且又是剛剛開始深入了解異步框架，那你就要小心了。

Nginx 為了減少系統(tǒng)上下文切換，它的 worker 是用單進程單線程設計的，事實證明這種做法運行效率很高。Nginx 要么是在等待網(wǎng)絡訊號，要么就是在處理業(yè)務（請求數(shù)據(jù)解析、過濾、內(nèi)容應答等），沒有任何額外資源消耗。

常見語言代表異步框架

• Golang：使用協(xié)程技術實現(xiàn)
• Python：gevent 基于協(xié)程的 Python 網(wǎng)絡庫
• Rust：用的少，只知道語言完備支持異步框架
• OpenResty：基于 Nginx，使用事件通知機制
• Java：Netty，使用網(wǎng)絡事件通知機制

異步編程的噩夢

異步編程，如果從零開始，難度是非常大的。一個完整的請求，由于網(wǎng)絡傳輸?shù)姆沁B續(xù)性，這個請求要被多次掛起、恢復、運行，一旦網(wǎng)絡有新數(shù)據(jù)到達，都需要立刻喚醒恢復原始請求處于運行狀態(tài)。開發(fā)人員不僅僅要考慮異步 API 接口本身的使用規(guī)范，還要考慮業(yè)務請求的完整處理，稍有不慎，全盤皆輸。

最最重要的噩夢是，我們好不容易搞定異步框架和業(yè)務請求完整性，但是卻在我們的業(yè)務請求上使用了阻塞函數(shù)。一開始沒有任何感知，只有做壓力測試的時候才發(fā)現(xiàn)我們的并發(fā)量上不去，各種卡頓，甚至開始懷疑人生：異步世界也就這樣。

OpenResty 中的阻塞函數(shù)

官方有明確說明，OpenResty 的官方 API 絕對 100% non-blocking，所以我們只能在她的外面尋找了。我這里大致歸納總結了一下，包含下面幾種情況：

• 高 CPU 的調(diào)用（壓縮、解壓縮、加解密等）
• 高磁盤的調(diào)用（所有文件操作）
• 非 OpenResty 提供的網(wǎng)絡操作（luasocket 等）
• 系統(tǒng)命令行調(diào)用（os.execute 等）

這些都應該是我們盡量要避免的。理想豐滿，現(xiàn)實骨感，誰能保證我們的應用中不使用這些類型的 API？沒人保證，我們能做的就是把他們的調(diào)用數(shù)量、頻率降低再降低，如果還是不能滿足我們需要，那么就考慮把他們封裝成獨立服務，對外提供 TCP/HTTP 級別的接口調(diào)用，這樣我們的 OpenResty 就可以同時享受異步編程的好處又能達到我們的目的。