LNMP架構下的進程模型分析

前言

若是已經在LNMP架構下工做2-3年時間，這個階段咱們對本身經常使用的技術棧的工做原理必定須要有一個基本的認識。一方面，能夠去學習這些優秀軟件的設計思路，另外一方面，能夠爲分析系統瓶頸和系統優化打好基礎。今天咱們就來看看php-fpm/nginx/redis/mysql的進程模型。

php-fpm的進程模型

php-fpm採用了master-worker多進程的模型，其次與php-cgi相比提供了更好的進程管理方式。php-fpm的進程模型示例圖以下：

master主進程的主要任務：

• 監聽socket(TCP/IP或者Unix Domain Socket)
• 管理子進程

master經過以下的信號來對進程進行管理：

SIGINT/SIGTERM 退出信號

SIGQUIT 優雅退出信號

SIGUSR1 從新加載日誌文件信號

SIGUSR2 平滑重啓信號

SIGCHLD 回收子進程資源信號(wait/waitpid防止異常退出的子進程變成殭屍進程,殭屍進程會佔用pid等內核資源)
複製代碼

worker工做進程的主要任務：

• accept請求
• 執行具體的php腳本

多進程(單線程)併發模型

nginx的進程模型

一樣，nginx也採用了master-worker多進程的模型，進程模型圖以下所示：

可是與php-fpm主要的不一樣的是：

1. master進程不負責監聽端口
2. worker進程自身監聽端口(多個進程會產生驚羣效應，nginx使用互斥鎖使同一時刻只有一個進程去listen端口)

master經過以下的信號來對進程進行管理：

SIGINT/SIGTERM 退出信號

SIGQUIT 優雅退出信號

SIGHUP 平滑重啓信號

SIGUSR1 從新加載日誌文件信號

SIGUSR2 平滑升級信號

SIGWINCH 優雅退出某個worker進程信號

複製代碼

多進程(單線程)和多路I/O複用併發模型

redis的進程模型

redis採用的是單進程的模型，以下圖所示：

可是，redis須要實現持久化，持久化的方式通常有兩種RDB(寫快照)/AOF(寫命令)，持久化的過程redis會fork一個子進程來完成，目的不阻塞master工做進程。以下圖所示：

單進程(單線程)和多路I/O複用併發模型

mysql的進程模型

mysql談進程模型其實仍是不合適，mysql主要採用的是多線程的架構。

多線程併發模型

總結

php-fpm多進程，符合php語言的設計思想「簡單」。進程間資源隔離，簡單且複雜性底，反之相對於而言高流量下性能會不是很好。

nginx多進程，worker去監聽端口，一方面，使得master專一於進程管理；另外一方面，提升服務的健壯性，若是有一個worker掛了別的worker還能夠繼續處理請求；其次，發揮計算機多核的優點。

redis單進程，採用I/O多路複用性能已經足夠的好，redis基本都是內存操做，不使用多線程，避免了大量競爭，簡化了系統的複雜度。其次，redis也沒涉及複雜的計算場景，單核足夠使用。

mysql多線程，按照我目前的理解，絕大多數經常使用的mysql引擎的性能瓶頸是在於磁盤IO，多線程技術已經足夠知足併發需求。

思考

從上面看來，不一樣的系統設計，根據它的運用場景都採用了符合它們自身需求的設計。好比，php的簡單；nginx的高可用高性能的web server；redis高性能的nosql；mysql大量的磁盤操做。

這些系統使用的多進程，多線程，協程，I/O多路複用(select/poll/epoll)等技術手段都是指引咱們去優化咱們系統的方向，這些優秀系統都爲咱們的設計思路提供了很好的案例，去提升併發能力，解決網路IO、磁盤IO問題。這些都是咱們如今以及將來須要去理解和消化的東西。

最後，以上內容有理解不對的地方，歡迎你們及時指正，很是謝謝～

附錄

常見linux信號和數字映射表：

信號	數字(LINUX)	含義
SIGKILL	9	force kill
SIGINT	2	interrupt
SIGQUIT	3	quit graceful
SIGTERM	15	terminate
SIGHUP	1	hang up
SIGUSR1	10	user defined
SIGUSR2	12	user defined