鏈接：https://www.zhihu.com/question/266535644/answer/705067582
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
比如 MySQL 卡，就算 OpenResty 極其快，對打開瀏覽器的用戶來說，遲遲看不到從數據庫獲取的信息，頁面一片空白，他們認為也是卡，跟沒有用 OpenResty 不是一樣嗎？
OpenResty解決的是高並發的痛點。現在服務的后台大部分是java寫的，但是用java寫出穩定的高並發服務是很復雜的一件事，首先是服務器的選擇，web服務器有幾個選型，tomcat，apache,weblogic,還有商用webphere. 1、tomcat官方宣稱的並發量是1000，厲害點的做點參數調優，也不過3000並發,如果要開發一個並發百萬的服務，1000000/3000,需要1000台服務器，想想都不可能。 2、apache的並發比tomcat更不堪，200-300 3、weblogic的並發稍好，平均能達到3000左右，但是也沒有達到好一個數量級
但是nginx就不一樣了，處理幾萬的請求很輕松，內存占用也不高，之前我們只是把它用作負載均衡，沒想過當做一個web服務器，OpenResty的出現解決了享受nginx高並發優勢的攔路虎，因為nginx是使用異步 事件模型，跟傳統的編程思想不一樣，而lua是用c解釋執行的腳本語言（執行效率很高），可以用傳統的同步編程思想上，在nginx請求接進來后處理稍復雜的邏輯。
對於高並發的系統來說，都是基於內存的，或者說是基於緩存的，題主說的用mysql支撐高並發是不現實的，mysql的並發量在4000-8000，超過這個量mysql性能就會急劇下降。一次內存讀取的時間是幾十納秒，一次緩存讀取是幾毫秒，大家可能對納秒比較陌生，一納秒等於1秒的1000000000分之一，一毫秒等於1秒的1000分之一，請求過來之后直接走內存讀取，在需要和數據庫交互的時候把數據寫入內存，然后再批量入庫，快速響應。
web流量也符合二八原則，百分之八十的流量集中在百分之二十的頁面，比如電商的首頁，產品詳情頁，使用openResty支撐產品詳情頁的高並發訪問，在處理訂購單，購物車等環節用其他的高並發框架處理，比如java的NIO網絡框架netty。
java的netty也是處理高並發的利器，不過我做過測試，整體性能可以達到nginx的80%，所以，臟活累活都讓nginx做吧，關鍵業務用netty。
當然，每個人對高並發的理解可能不太一樣，有人說1000並發就是高並發了，有人說1萬的並發才是高並發，有人說並發百萬才是高並發，OpenResty是可以做到百萬並發的（當然需要各種調優）,現在大部分業務OpenResty都可以勝任，但是像騰訊10億用戶，1億的並發，OpenResty就搞不定了。
不同的並發量要應對的東西不一樣，比如1000並發，用tomcat，springmvc框架加緩存就可以應對，1萬的並發在關鍵節點使用內存處理也很容易，百萬並發就需要linux內核調優，socket緩沖區，文件句柄數，內存池，RPS/RFS SMP等優化也可以達到。千萬並發就需要考慮用戶態協議dpdk了
鏈接：https://www.zhihu.com/question/266535644/answer/311914648
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
OpenResty 是快，但是MySQL卡了，你換什么都是卡的，這和你用哪個技術棧沒有關系，我個人認為好的幾點的是：
- 做網關，比如說 ngx-waf，從較高的位置處理了安全問題
- 高並發，異步非阻塞的項目需求（甚至說你的MySQL卡，如果你用 ngx.timer.at 來實現異步寫庫，用戶的請求完全可以不受 MySQL 卡的影響，當然 mysql 響應慢，積累太多連接不釋放導致系統出問題就是另一回事了 ）
- 對其他語言的兼容，可以直接在 lua 中嵌入 C 來寫，又或者 lua 結合 redis 使用
----------------- 3月6日 面試被問了類似的問題，想起這個問題重寫一下答案-------------
從深入角度來說，這里的 openresty 是基於 nginx 增加了模塊，我們說的其實也就是 nginx 的性能，而 nginx 是異步非阻塞的，基於事件驅動的 server，相比其他的 server 在卡主的時候他為什么不卡？
就拿你的問題來說，mysql 卡了，這條請求的上下文會被卡在這里，不管是 nginx 還是 apache，都會卡住這條請求，但是問題關鍵還在於后續的請求進來后會怎么辦？
apache 的做法是開啟一個新的進程來處理后續的請求，但系統進程資源是有限的，所以面對大量請求時，進程耗盡，apache 就會把所有后續的請求都卡住了。
nginx 只有一個master進程和已配置個數的 worker進程，master 進程把請求交給 worker 去處理，一個worker 在可能出現阻塞的地方會注冊一個事件就放過去了（epoll模型），而不是干巴巴的等待阻塞被處理完，他會繼續處理后續的請求（非阻塞），當這個事件處理完之后會通過callback來通知worker繼續處理那條請求后續的事情（事件驅動）因此單個worker可以處理大量請求而不會輕易讓整個系統卡住。
鏈接：https://www.zhihu.com/question/266535644/answer/328593385
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
異步提高了服務器整體負載能力，而不是提高某個請求的速度。
而openresty可以用寫同步的方式寫異步，簡化開發。
更新下這個答案：
多任務程序分成兩種：
一種是並行，指的是把一個大型任務拆分成N個小任務，把這些小任務分派個N個WORKER（線程，服務器）來執行，最后再組合起來，輸出結果，這種是為了提升單次任務的執行時間。
另一種是並發，主要目標是在同一個CPU上執行幾個松耦合合的任務,充分利用CPU的核,讓其足夠忙碌,從而最大化程序的吞吐量,那么真正要做的是避免因為等待遠程服務的返回,或者對數據庫的查詢,而阻塞線程的執行, 浪費寶貴的計算資源,因為這種等待的時間很可能相當長（摘自JAVA8實戰）。
異步是第二種並發的一種實現方案，OpenResty通過把nginx的事件驅動機制與lua的協程相結合，實現了cosocket這種東西，把異步實現做了一個封裝。使用cosocket，開發者就不需要考慮異步如何實現，同樣用同步的編程方式，就可以完成異步請求MySQL，Redis以及各種網絡服務，從而達到增大服務器吞吐量的目的。
當然，lua語言本身比較小巧，相對來講處理單次請求的效率也會更高，但這個我認為不算是OpenResty一個非常重要的優勢，畢竟對於網絡服務來講單次請求的延時，瓶頸往往還是在數據庫
作者：babayetu liu
鏈接：https://www.zhihu.com/question/266535644/answer/309840098
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
openresty本身是集成了lua組件的nginx，等於是把一部分后端服務的功能用lua集成到反向代理里面了。和mysql慢有個毛關系啊。數據庫慢，你需要加緩存，拆分，看你哪個業務邏輯拖慢了整體的返回速度。業務邏輯復雜，拆域，中間層聚合，很多手段可以用。超時還可以用nginx上的靜態持久化頁面返回。
lvs -> nginx -> server -> database，后端哪一個環節慢，都不是反向代理應該解決的事情，你沒搞懂痛點在哪里。
實名反對圓胖腫的答案。一點常識，永遠不要覺得你比數據庫廠家更懂文件系統。直接寫文件系統，災備，數據丟失，回滾都自己做嗎？Linux上次爆出的ext4數據丟失的bug忘了？
作者：「已注銷」
鏈接：https://www.zhihu.com/question/266535644/answer/548599844
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
首先就單個請求而言，
單次請求響應時間是網絡 + http服務器 + http到后端通信 + 后端 + 后端到數據庫通信 + 數據庫
那么現在openresty直接消除了第三項，第四項明顯減少，整個響應時間是改善的，正因為有這個改善你才能問得出來這個問題。
不然，
“比如mysql卡，就算fastcgi極其快，跟cgi不是一樣的嗎？”
就多個請求而言，openresty降低了整個服務器和單次請求的footprint，使得服務器能承載更多的請求(直到把數據庫撐死)。
你總不能說“反正數據庫是瓶頸，我前面的東西放着快的不用用慢的也沒有關系”吧。
另外某個人說“換成postgre以提高性能”，不好意思，postgre的優勢在於功能和靈活性，論性能，mysql是稍好的。
“用文件系統代替數據庫”，不好意思，你讀寫文件是自己實現緩存嗎？下mysql自己測性能去謝謝。