# 典型應用場景 可以這樣說，任何一個開發語言、開發框架，都有它存在的明確目的，重心是為了解決什么問題。沒有說我們學習一門語言或技術，就可以解決所有的問題。同樣的，`OpenResty`的存在也有其自身適用的應用場景。 其實官網 wiki 已經列了出來： - 在lua中混合處理不同nginx模塊輸出（proxy, drizzle, postgres, redis, memcached等）。 - 在請求真正到達上游服務之前，lua中處理復雜的準入控制和安全檢查。 - 比較隨意的控制應答頭（通過Lua）。 - 從外部存儲中獲取后端信息，并用這些信息來實時選擇哪一個后端來完成業務訪問。 - 在內容handler中隨意編寫復雜的web應用，同步編寫異步訪問后端數據庫和其他存儲。 - 在rewrite階段，通過Lua完成非常復雜的處理。 - 在Nginx子查詢、location調用中，通過Lua實現高級緩存機制。 - 對外暴露強勁的Lua語言，允許使用各種Nginx模塊，自由拼合沒有任何限制。該模塊的腳本有充分的靈活性，同時提供的性能水平與本地C語言程序無論是在CPU時間方面以及內存占用差距非常小。所有這些都要求LuaJIT 2.x是啟用的。其他腳本語言實現通常很難滿足這一性能水平。 #### 不擅長的應用場景 前面的章節，我們是從它適合的場景出發，`OpenResty`不適合的場景又有哪些？以及我們在使用中如何規避這些問題呢？ 這里官網并沒有給出答案，我根據我們的應用場景給大家列舉，并簡單描述一下原因： - 有長時間阻塞調用的過程 - 例如通過 `Lua` 完成系統命令行調用 - 使用阻塞的`Lua API`完成相應操作 - 單個會話處理邏輯復雜，尤其是需要和請求方多次交互的長連接場景 - `Nginx`的內存池 pool 是每次新申請內存存放數據 - 所有的內存釋放都是在會話退出的時候統一釋放 - 如果單個會話處理過于復雜，將會有過多內存無法及時釋放 - 內存占用高的處理 - 受制于`Lua VM`的最大使用內存 1G 的限制 - 這個限制是單個`Lua VM`，也就是單個`Nginx worker` - 兩個會話之間有交流的場景 - 例如你做個在線聊天，要完成兩個用戶之間信息的傳遞 - 當前`OpenResty`還不具備這個通訊能力（后面可能會有所完善） - 與行業專用的組件對接 - 最好是 TCP 協議對接，不要是 API 方式對接，防止里面有阻塞 TCP 處理 - 由于`OpenResty`必須要使用非阻塞 API ，所以傳統的阻塞 API ，我們是沒法直接使用的 - 獲取 TCP 協議，使用 cosocket 重寫（重寫后的效率還是很贊的） - 每請求開啟的 `light thread` 過多的場景 - 雖然已經是`light thread`，但它對系統資源的占用相對是比較大的 這些適合、不適合信息可能在后面隨著 `OpenResty` 的發展都會有新的變化，大家拭目以待。