# 阻塞操作 Openresty的誕生，一直對外宣傳是非阻塞(100% noblock)的。基于事件通知的Nginx給我們帶來了足夠強悍的高并發支持，但是也對我們的編碼有特殊要求。這個特殊要求就是我們的代碼，也必須是非阻塞的。如果你的服務端編程生涯一開始就是從異步框架開始的，恭喜你了。但如果你的編程生涯是從同步框架過來的，而且又是剛剛開始深入了解異步框架，那你就要小心了。 Nginx為了減少系統上下文切換，它的worker是用單進程單線程設計的，事實證明這種做法運行效率很高。Nginx要么是在等待網絡訊號，要么就是在處理業務（請求數據解析、過濾、內容應答等），沒有任何額外資源消耗。 ### 常見語言代表異步框架 - Golang ：使用協程技術實現 - Python ：gevent基于協程的Python網絡庫 - Rust ：用的少，只知道語言完備支持異步框架 - Openresty：基于Nginx，使用事件通知機制 - Java ：Netty，使用網絡事件通知機制 ### 異步編程的噩夢 異步編程，如果從零開始，難度是非常大的。一個完整的請求，由于網絡傳輸的非連續性，這個請求要被多次掛起、恢復、運行，一旦網絡有新數據到達，都需要立刻喚醒恢復原始請求處于運行狀態。開發人員不僅僅要考慮異步api接口本身的使用規范，還要考慮業務會話的完整處理，稍有不慎，全盤皆輸。 最最重要的噩夢是，我們好不容易搞定異步框架和業務會話完整性，但是卻在我們的業務會話上使用了阻塞函數。一開始沒有任何感知，只有做壓力測試的時候才發現我們的并發量上不去，各種卡曼頓，甚至開始懷疑人生：異步世界也就這樣。 ### Openresty中的阻塞函數 官方有明確說明，Openresty的官方API絕對100% noblock，所以我們只能在她的外面尋找了。我這里大致歸納總結了一下，包含下面幾種情況： - 高CPU的調用（壓縮、解壓縮、加解密等） - 高磁盤的調用（所有文件操作） - 非Openresty提供的網絡操作（luasocket等） - 系統命令行調用（os.execute等） 這些都應該是我們盡量要避免的。理想豐滿，現實骨感，誰能保證我們的應用中不使用這些類型的API？沒人保證，我們能做的就是把他們的調用數量、頻率降低再降低，如果還是不能滿足我們需要，那么就考慮把他們封裝成獨立服務，對外提供TCP/HTTP級別的接口調用，這樣我們的Openresty就可以同時享受異步編程的好處又能達到我們的目的。