nginx實現高并發的示例

這篇文章主要介紹了nginx實現高并發的示例，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

　　簡單來講，就是異步，非阻塞，使用了epoll和大量的底層代碼優化。

　　稍微詳細一點展開的話，就是nginx的特殊進程模型和事件模型的設計。

　　進程模型

　　nginx采用一個master進程，多個woker進程的模式。

　　master進程主要負責收集、分發請求。當一個請求過來時，master拉起一個worker進程負責處理這個請求。

　　master進程也要負責監控woker的狀態，保證高可靠性

　　woker進程一般設置為跟cpu核心數一致。nginx的woker進程跟apache不一樣。apche的進程在同一時間只能處理一個請求，所以它會開很多個進程，幾百甚至幾千個。而nginx的woker進程在同一時間可以處理額請求數只受內存限制，因此可以處理多個請求。

　　事件模型

　　nginx是異步非阻塞的。

　　每進來一個request，會有一個worker進程去處理。但不是全程的處理，處理到什么程度呢?處理到可能發生阻塞的地方，比如向上游(后端)服務器轉發request，并等待請求返回。那么，這個處理的worker不會這么傻等著，他會在發送完請求后，注冊一個事件：“如果upstream返回了，告訴我一聲，我再接著干”。于是他就休息去了。此時，如果再有request 進來，他就可以很快再按這種方式處理。而一旦上游服務器返回了，就會觸發這個事件，worker才會來接手，這個request才會接著往下走。

　　web server的工作性質決定了每個request的大部份生命都是在網絡傳輸中，實際上花費在server機器上的時間片不多。這是幾個進程就解決高并發的秘密所在。

　　IO多路復用模型epoll

　　epoll() ，內核維護一個鏈表，epoll_wait 直接檢查鏈表是不是空就知道是否有文件描述符準備好了。內核實現epoll 是根據每個 sockfd 上面的與設備驅動程序建立起來的 回調函數 實現的。那么，某個 sockfd 上的事件發生時，與它對應的回調函數就會被調用，來把這個 sockfd 加入鏈表，其他處于“空閑的”狀態的則不會。

　　select() ，內核采用 輪訓 的方法來查看是否有fd 準備好，其中的保存 sockfd 的是類似數組的數據結構 fd_set，key 為 fd，value 為 0 或者 1。

　　poll()

　　【總結】：epoll 與 select 相比最大的優點是不會隨著 sockfd 數目增長而降低效率。

　　服務器端負載均衡 Nginx

　　nginx 是客戶端所有請求統一交給 nginx，由 nginx 進行實現負載均衡請求轉發，屬于服務器端負載均衡。

　　既請求由 nginx 服務器端進行轉發。

　　客戶端負載均衡 Ribbon

　　Ribbon 是從 eureka 注冊中心服務器端上獲取服務注冊信息列表，緩存到本地，然后在本地實現輪詢負載均衡策略。

　　既在客戶端實現負載均衡。

　　應用場景的區別：

　　Nginx適合于服務器端實現負載均衡比如 Tomcat ，Ribbon適合與在微服務中RPC遠程調用實現本地服務負載均衡，比如 Dubbo、SpringCloud 中都是采用本地負載均衡。

　　spring cloud的Netflix中提供了兩個組件實現軟負載均衡調用：ribbon和feign。

　　Ribbon

　　是一個基于 HTTP 和 TCP 客戶端的負載均衡器,它可以在客戶端配置 ribbonServerList(服務端列表)，然后輪詢請求以實現均衡負載。

　　springcloud的ribbon和nginx有什么區別?哪個性能好?

　　nginx性能好，但ribbon可以剔除不健康節點，nginx剔除節點比較復雜。ribbon還可以配合熔斷器一起工作,ribbon是客戶端負載均衡，nginx是服務端負載均衡。客戶端負載均衡，所有客戶端節點都維護自己要訪問的服務端清單。服務端負載均衡的軟件模塊會維護一個可用的服務清單,ribbon 是一個客戶端負載均衡器，可以簡單的理解成類似于 nginx的負載均衡模塊的功能。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“nginx實現高并發的示例”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!