PHP底层和mysql的通信原理

需要清楚的几个概念：

FPM进程：进程数在php-fpm.ini中设置。没有设置 max_requests ，那么进程是不会销毁的，也就是说当一个进程里面出现死循环或者内存溢出等导致进程僵死的情况出现的时候，处理的进程就会少一个。

mysql连接数：一个进程连接到mysql的一个库，算是一个连接。连接数默认100，我们线上是5000，进程数在my.cnf中设置。mysql连接数要大于等于FPM进程数，否则会报错。

长连接和短连接：FPM短连接MYSQL的时候，无需调用CLOSE函数，因为在RSHUTDOWN的时候，会调用清理。长连接的时候，需要调用close，长连接会一直霸占资源，直到进程死掉。

首先我们来理解一下 php-fpm 的工作原理，php-fpm 是一个 php-cgi 进程管理器，其实就是一个连接池，它和nginx配合的工作原理如下。

我们先从最简单的静态方式入手观察他的工作原理

vim php-fpm.ini

[www]

pm = static

pm.max_children = 5

pm.max_requests = 2

上面三句话的含义是什么呢:

1、static 表示静态以静态方式生成 php-fpm 进程

2、pm.max_children = 5 表示当 php-fpm 启动时就启动 5 个 php-fpm 子进程等待处理 nginx 发过来的请求

3、pm.max_requests = 2 表示每个 php-fpm 子进程处理 2 个请求就销毁，当然父进程每次看到有销毁的自然也就会生成新的子进程

我们来简单验证一下这个说法：

首先重启 php-fpm，让它复位一下

接下来写一条简单的语句输出当前进程ID

echo "当前 php-fpm 进程ID：".posix_getpid();

不断刷新浏览器观察输出变化

当前 php-fpm 进程ID：24548

当前 php-fpm 进程ID：24549

当前 php-fpm 进程ID：24550

当前 php-fpm 进程ID：24547

当前 php-fpm 进程ID：24551

当前 php-fpm 进程ID：24548

当前 php-fpm 进程ID：24549

当前 php-fpm 进程ID：24550

当前 php-fpm 进程ID：24547

当前 php-fpm 进程ID：24551

当前 php-fpm 进程ID：24563

当前 php-fpm 进程ID：24564

当前 php-fpm 进程ID：24565

当前 php-fpm 进程ID：24566

当前 php-fpm 进程ID：24567

当前 php-fpm 进程ID：24563

当前 php-fpm 进程ID：24564

当前 php-fpm 进程ID：24565

当前 php-fpm 进程ID：24566

当前 php-fpm 进程ID：24567

当前 php-fpm 进程ID：24568

当前 php-fpm 进程ID：24569

当前 php-fpm 进程ID：24570

当前 php-fpm 进程ID：24571

当前 php-fpm 进程ID：24572

当前 php-fpm 进程ID：24568

当前 php-fpm 进程ID：24569

当前 php-fpm 进程ID：24570

当前 php-fpm 进程ID：24571

当前 php-fpm 进程ID：24572

可以看得出，第一批id不是按照顺序执行的，进程id为24547的进程是在第四位处理的，然后从下面开始，所有id都是顺序执行的而且每次生成的一批id都是递增，是不是有种mysql自增主键的赶脚呢？

这里需要注意的是，无论是静态还是下面的动态配置方式，只要没有设置 max_requests ，那么进程是不会销毁的，也就是说当一个进程里面出现死循环或者内存溢出等导致进程僵死的情况出现的时候，处理的进程就会少一个了

好吧理解了静态的处理方式，我们其实也很容易知道这个方式的弊端了，当然我们平时服务器不可能就开5个进程每个进程处理2个请求，我们来做一个简单的加减乘除，看看一个服务器应该开多少个 php-fpm 合适

首先我们来看看一个简单的echo需要多少内存：

$size = memory_get_usage();

$unit = array('b','kb','mb','gb','tb','pb');

$memory = @round($size/pow(1024,($i=floor(log($size,1024)))),2).' '.$unit[$i];

echo "当前 php-cgi 进程所使用内存：".$memory;

观察浏览器我们可以得到一下数据：

当前 php-cgi 进程所使用内存：227.17 kb

也就是说一个简单的什么都不干的php就已经占用了200多K的内存，当然这也不算多。

不过进程多了cpu切换进程速度就会变慢，所以这个数还是需要通过ab等测试工具才能测试出具体应该开多少比较合理

我们先从200个cgi进程开始，不断的增加，架设增加到800的时候，效率和400一样，那我们就没必要开800那么多进程浪费内存了。

那么问题就来了，如果同一时间请求出超过400呢？有人说会排队等待，真的会排队等待吗？答案明显是 php-fpm 是没能力排队了，因为处理请求的php-fpm子进程都用完了，那么等待也就只能是在 nginx 等待，通常一个 nginx 也不只是转发请求给 php-fpm 就完事了，他还要处理静态文件呢？如果这些php请求导致nginx的请求数过多一直在等待，那么访问静态文件自然也会卡了，这时候我们就需要配置成下面的动态处理方式。

[www]

pm.max_children = 10

pm.start_servers = 5

pm.min_spare_servers = 2

pm.max_spare_servers = 8

;pm.max_requests = 2

上面五句话的含义是什么呢:

1、dynamic 表示静态以动态方式生成 php-fpm 进程

2、pm.max_children = 10 同时活动的进程数 10个

3、pm.start_servers = 5 表示当 php-fpm 主进程启动时就启动 5 个 php-fpm 子进程

4、pm.min_spare_servers = 2 表示最小备用进程数

5、pm.max_spare_servers = 8 表示最大备用进程数

6、pm.max_requests = 2 上面说过就不说了

当前 php-fpm 进程ID：2270

当前 php-fpm 进程ID：2271

当前 php-fpm 进程ID：2272

当前 php-fpm 进程ID：2273

当前 php-fpm 进程ID：2274

当前 php-fpm 进程ID：2270

当前 php-fpm 进程ID：2271

当前 php-fpm 进程ID：2272

当前 php-fpm 进程ID：2273

当前 php-fpm 进程ID：2274

当前 php-fpm 进程ID：2270

当前 php-fpm 进程ID：2271

当前 php-fpm 进程ID：2272

当前 php-fpm 进程ID：2273

当前 php-fpm 进程ID：2274

为什么这里没有重新生成新的进程？因为pm.max_requests = 2被注释掉了，这个上面其实已经提及过一次了

我们也可以从 ps 看出这批进程id

ps aux|grep php

root 2269 0.0 0.1 134560 4616 ? Ss 14:27 0:00 php-fpm: master process (/etc/php/php-fpm.ini)

www-data 2270 0.2 0.2 136736 9188 ? S 14:27 0:00 php-fpm: pool www

www-data 2271 0.2 0.2 136740 9192 ? S 14:27 0:00 php-fpm: pool www

www-data 2272 0.2 0.2 134684 7284 ? S 14:27 0:00 php-fpm: pool www

www-data 2273 0.2 0.2 136732 9120 ? S 14:27 0:00 php-fpm: pool www

www-data 2274 0.1 0.2 134684 7244 ? S 14:27 0:00 php-fpm: pool www

从上面我们可以看到一个 id 为 2269 的 php-fpm 主进程管理着 id 为 2270、2271、2272、2273、2274 的5个php-fpm 子进程

这里需要注意的是，当并发大过start_servers数的处理能力是，备用进程才会启动，当并发数小的时候，备用进程也会销毁掉，所以无论什么时候，ps 出来的进程都是上面那5个

下面来看看php-fpm+mysql的效果

mysql> show processlist;

+----+------------------+-----------+------+---------+------+----------------+-------------------------+

+----+------------------+-----------+------+---------+------+----------------+-------------------------+

+----+------------------+-----------+------+---------+------+----------------+-------------------------+

接下来我们看短连接：

$conn = new mysqli("192.168.0.170", "redol", "redol", "test_db");

然后不断访问上面的php文件，每次看到的都是

+----+---------+-----------+------+---------+------+----------------+--------------------+

+----+---------+-----------+------+---------+------+----------------+--------------------+

+----+---------+-----------+------+---------+------+----------------+--------------------+

这也是php神奇的地方，居然不用close的，每次请求完了他就自己给你close掉和mysql的连接了，这点确实也让很多新手少了不少下面的烦恼啊

Warning: mysqli::mysqli(): (HY000/1040): Too many connections in ...

不要以为语言应该都是这样那就打错特错了，去看看golang吧

下面看看长连接

$conn = new mysqli("p:192.168.0.170", "redol", "redol", "test_db");

你没看错，mysqli的长连接和mysql不同，是在host前面加 p:，没有mysqli_pconnet 的用法，估计很多刚开始用mysqli也是摸不着头脑吧？

第一次访问：

+----+-------+-------------------------+-------+---------+------+-------+------------------+

+----+-------+-------------------------+-------+---------+------+-------+------------------+

+----+-------+-------------------------+-------+---------+------+-------+------------------+

刷新一下网页

+-----+-------+-------------------------+-------+---------+------+-------+------------------+

+-----+-------+-------------------------+-------+---------+------+-------+------------------+

+-----+-------+-------------------------+-------+---------+------+-------+------------------+

再刷新一下网页，效果我就不发了，反正你知道最后无论怎么刷新，都是如下即可

+-----+-------+-------------------------+-------+---------+------+-------+------------------+

+-----+-------+-------------------------+-------+---------+------+-------+------------------+

+-----+-------+-------------------------+-------+---------+------+-------+------------------+

也就是说，长连接是真的会一直霸占mysql连接的，那么问题就来了，如果我没有重启 php-fpm，只重启了mysql，会出现什么问题呢？答案是第一次连接的时候会报下面错误

Warning: mysqli::mysqli(): MySQL server has gone away in ###也就是连接已经存在

所以用长连接query前还是先判断有没有连接，没有就close连接，注意一定要close，再连接，否则连接是失效的。

下面我们来试试 Too many connections 的错误吧

先调整一下mysql的最大连接数

vim /etc/mysql/my.cnf

max_connections = 3

你没看错，我只给了他3个连接，而上面的php-fpm是5个，所以结果不用我说都知道了吧，如期的出现

Warning: mysqli::mysqli(): (HY000/1040): Too many connections in ...

所以线上的mysql，还是注意一下这个max_connections数吧，我只能告诉你他默认是100，如果你觉得100不够用的话，自己改去吧

从上面可知，短连接是不用close也会自动关闭的，那如果是设置了 pm.max_requests = 2，每个php-fpm处理两个请求就销毁，销毁了会close么？我就不截图了，直接告诉答案吧，会的，所以无论如何，看到的mysql都是1、2、3、4、5、4、3、2、1、2、3、4、5这样的连接数，就是慢慢增加，再慢慢减少，减少是因为php-fpm子进程销毁了嘛

最后编辑于：2018.01.09 16:45:19

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 158,560评论 4赞 361
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 67,104评论 1赞 291
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 108,297评论 0赞 243
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 43,869评论 0赞 204
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 52,275评论 3赞 287
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 40,563评论 1赞 216
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 31,833评论 2赞 312
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 30,543评论 0赞 197
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 34,245评论 1赞 241
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 30,512评论 2赞 244
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 32,011评论 1赞 258
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 28,359评论 2赞 253
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 33,006评论 3赞 235
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 26,062评论 0赞 8
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 26,825评论 0赞 194
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 35,590评论 2赞 273
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 35,501评论 2赞 268

PHP底层和mysql的通信原理

推荐阅读更多精彩内容