OpenResty 究竟解決了什麼痛點？

轉～

做者：耿小扭
連接：https://www.zhihu.com/question/266535644/answer/705067582
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

好比 MySQL 卡，就算 OpenResty 極其快，對打開瀏覽器的用戶來講，遲遲看不到從數據庫獲取的信息，頁面一片空白，他們認爲也是卡，跟沒有用 OpenResty 不是同樣嗎？

因此它到底解決了什麼痛點？

OpenResty解決的是高併發的痛點。如今服務的後臺大部分是java寫的，可是用java寫出穩定的高併發服務是很複雜的一件事，首先是服務器的選擇，web服務器有幾個選型，tomcat，apache,weblogic,還有商用webphere. 一、tomcat官方宣稱的併發量是1000，厲害點的作點參數調優，也不過3000併發,若是要開發一個併發百萬的服務，1000000/3000,須要1000臺服務器，想一想都不可能。 二、apache的併發比tomcat更不堪，200-300 三、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了

 

做者：Horan
連接：https://www.zhihu.com/question/266535644/answer/311914648
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

OpenResty 是快，可是MySQL卡了，你換什麼都是卡的，這和你用哪一個技術棧沒有關係，我我的認爲好的幾點的是：

1. 作網關，好比說 ngx-waf，從較高的位置處理了安全問題
2. 高併發，異步非阻塞的項目需求（甚至說你的MySQL卡，若是你用 ngx.timer.at 來實現異步寫庫，用戶的請求徹底能夠不受 MySQL 卡的影響，固然 mysql 響應慢，積累太多鏈接不釋放致使系統出問題就是另外一回事了 ）
3. 對其餘語言的兼容，能夠直接在 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本身測性能去謝謝。

 

 

OpenResty搭建高性能服務端：https://www.jianshu.com/p/09c17230e1ae