通知设置 新通知
PHP大会笔记：PHP在机器学习上的应用和云深度学习平台的架构设计与实现
会议 • zkbhj 发表了文章 • 0 个评论 • 1836 次浏览 • 2017-06-10 14:03
咳咳，计算机课开始了……
机器学习
ML、DL引用
图像、语音、文本
如何实现？
什么是机器学习？
从数据中抽取规律，用于提取有用信息，解释数据、预测未来
机器学习过程：
数据预处理（去噪/归一化）
训练模型
评估模型（MSE/F1Score/AUC ）
应用模型
机器学习算法的应用
神经网络
机器学习框架对神经网络的实现 -- TensorFlow
TensorFlow的编程模型 -- 数据流图
TensorFlow的架构
PHP-ML（终于到重点了）
就到这吧，，，，，结束！ 查看全部
机器学习
ML、DL引用
图像、语音、文本
如何实现？
什么是机器学习？
从数据中抽取规律，用于提取有用信息，解释数据、预测未来
机器学习过程：
数据预处理（去噪/归一化）
训练模型
评估模型（MSE/F1Score/AUC ）
应用模型
机器学习算法的应用
神经网络
机器学习框架对神经网络的实现 -- TensorFlow
TensorFlow的编程模型 -- 数据流图
TensorFlow的架构
PHP-ML（终于到重点了）
就到这吧，，，，，结束！ 查看全部
咳咳，计算机课开始了……
机器学习
ML、DL引用
图像、语音、文本
如何实现？
什么是机器学习？
从数据中抽取规律，用于提取有用信息，解释数据、预测未来
机器学习过程：
数据预处理（去噪/归一化）
训练模型
评估模型（MSE/F1Score/AUC ）
应用模型
机器学习算法的应用
神经网络
机器学习框架对神经网络的实现 -- TensorFlow
TensorFlow的编程模型 -- 数据流图
TensorFlow的架构
PHP-ML（终于到重点了）
就到这吧，，，，，结束！
机器学习
ML、DL引用
图像、语音、文本
如何实现？
什么是机器学习？
从数据中抽取规律，用于提取有用信息，解释数据、预测未来
机器学习过程：
数据预处理（去噪/归一化）
训练模型
评估模型（MSE/F1Score/AUC ）
应用模型
机器学习算法的应用
神经网络
机器学习框架对神经网络的实现 -- TensorFlow
TensorFlow的编程模型 -- 数据流图
TensorFlow的架构
PHP-ML（终于到重点了）
就到这吧，，，，，结束！
PHP大会笔记：瓜子的架构变迁
会议 • zkbhj 发表了文章 • 0 个评论 • 2685 次浏览 • 2017-06-10 11:55
石器时代
蒸汽时代
EP的实践工作
代码的艺术
单测试
服务的解耦
前后端分离
目标和展望
平台化、服务化、智能化
蒸汽时代
EP的实践工作
代码的艺术
单测试
服务的解耦
前后端分离
目标和展望
平台化、服务化、智能化
PHP大会笔记：使用C++编写PHP7扩展
会议 • zkbhj 发表了文章 • 0 个评论 • 1551 次浏览 • 2017-06-10 10:17
【音频资源今晚放进来】
PHP的原生扩展
一、PHP的扩展加载过程
*.so （*.lib）
Zend引擎的php_load_extension函数
加载并执行so中get_module函数，返回zend_module_entry
struct中设置了M（R)INT\M(R)SHUTDOWN 4个函数指针
执行zend_s
PHP扩展加载
创建PHP的扩展工程
扩展骨架生成工具：ext_skel
编辑 config.m4
PHP和C++互补性强，实现动静结合
唯一与PHP直接在内存堆栈上实现互相调用的
PHP-X
不听了，，，去学怎么写PHP代码了。。
查看全部
PHP的原生扩展
一、PHP的扩展加载过程
*.so （*.lib）
Zend引擎的php_load_extension函数
加载并执行so中get_module函数，返回zend_module_entry
struct中设置了M（R)INT\M(R)SHUTDOWN 4个函数指针
执行zend_s
PHP扩展加载
创建PHP的扩展工程
扩展骨架生成工具：ext_skel
编辑 config.m4
PHP和C++互补性强，实现动静结合
唯一与PHP直接在内存堆栈上实现互相调用的
PHP-X
不听了，，，去学怎么写PHP代码了。。
查看全部
【音频资源今晚放进来】
PHP的原生扩展
一、PHP的扩展加载过程
*.so （*.lib）
Zend引擎的php_load_extension函数
加载并执行so中get_module函数，返回zend_module_entry
struct中设置了M（R)INT\M(R)SHUTDOWN 4个函数指针
执行zend_s
PHP扩展加载
创建PHP的扩展工程
扩展骨架生成工具：ext_skel
编辑 config.m4
PHP和C++互补性强，实现动静结合
唯一与PHP直接在内存堆栈上实现互相调用的
PHP-X
不听了，，，去学怎么写PHP代码了。。
PHP的原生扩展
一、PHP的扩展加载过程
*.so （*.lib）
Zend引擎的php_load_extension函数
加载并执行so中get_module函数，返回zend_module_entry
struct中设置了M（R)INT\M(R)SHUTDOWN 4个函数指针
执行zend_s
PHP扩展加载
创建PHP的扩展工程
扩展骨架生成工具：ext_skel
编辑 config.m4
PHP和C++互补性强，实现动静结合
唯一与PHP直接在内存堆栈上实现互相调用的
PHP-X
不听了，，，去学怎么写PHP代码了。。
PHP大会笔记：新浪微博LNMP架构分享
会议 • zkbhj 发表了文章 • 0 个评论 • 1675 次浏览 • 2017-06-10 09:42
【音频资源晚上放进来】
大会议题：高可用PHP。
一：新浪微博PC主站升级PHP7后的问题分析，新一代LNMP架构，基于混合云平台的弹性扩容架构
新浪微博内部技术体系：
后端语言，Java和PHP两大体系，开放平台用户关系和内容，是Java实现，所有业务需求开发用PHP。
模块并行化
突发大流量如何处理？改善架构，弹性扩容架构
分享大纲
背景和挑战
DCP平台介绍
PHP服务docker化
弹性扩容
1、背景和挑战
突发热点事件，引发大流量
大型活动及三节保障：春节红包飞
PUSH推送，运营的各种站内站外推送
话题业务特点
平时流量稳定，每日峰值波动较小
传统解决方案：提前申请足够的设备
设备冗余的问题，机架位不足，千万级采购成本，采购周期长，运行三个月只为一晚。
服务降级
降级非核心及周边业务
极端情况PC主站只保留主Feed
扩容繁琐，目标实现业务的弹性扩容部署
采购（采购机器）--》基础运维（操作系统、网络）--》业务运维（环境、监控、服务、流量）
运营设备成本高，目标要降低成本
各业务线利用率不高，未充分利用设备
各业务模型不同，峰值事件不同，不能进行错峰使用
每个业务都有自己的冗余，多个业务池会造成极大的成本
2、DCP平台介绍
主要思想：业务弹性调度、基础设施支持跨云
业务弹性调度：容器化来抹平运行环境的差异（借助docker）
基础设施支持跨云：
私有云（透明、安全、高性能）----- 按负载迁移（混合云）------公有云（敏捷、低成本、弹性）
固定工作负载 ，放在私有云----- 如根据预警，申请临时阿里云公有云，来进行弹性工作负载（按需申请使用和归还（无需闲置，成本低））
架构图
私有云“化零为整”
二、服务docker化
docker服务启动快
docker镜像一次制作，多次部署
尤其适合动态扩容部署
部署方案设计
PHP服务器包括Nginx、php-fpm、memcache、scribe等几大组件
PHP组件容器单独部署
代码、配置、日志等经常变更部分通过挂载的方式和docker容器互动
镜像制作
镜像方案
首次部署服务
通过下发配置文件、上线代码、启动容器完成服务部署。
代码上线
通过镜像完成上线
代码镜像使用busybox为基础，大小仅1m
创建代码镜像
一些细节
四、弹性扩容
扩容效果：一键式扩容
流量切换
总结
LNMP服务docker化，制作PHP服务先关镜像
结合DP平台完成PHP服务的首次部署、配置更改、代码上线 查看全部
大会议题：高可用PHP。
一：新浪微博PC主站升级PHP7后的问题分析，新一代LNMP架构，基于混合云平台的弹性扩容架构
新浪微博内部技术体系：
后端语言，Java和PHP两大体系，开放平台用户关系和内容，是Java实现，所有业务需求开发用PHP。
模块并行化
突发大流量如何处理？改善架构，弹性扩容架构
分享大纲
背景和挑战
DCP平台介绍
PHP服务docker化
弹性扩容
1、背景和挑战
突发热点事件，引发大流量
大型活动及三节保障：春节红包飞
PUSH推送，运营的各种站内站外推送
话题业务特点
平时流量稳定，每日峰值波动较小
传统解决方案：提前申请足够的设备
设备冗余的问题，机架位不足，千万级采购成本，采购周期长，运行三个月只为一晚。
服务降级
降级非核心及周边业务
极端情况PC主站只保留主Feed
扩容繁琐，目标实现业务的弹性扩容部署
采购（采购机器）--》基础运维（操作系统、网络）--》业务运维（环境、监控、服务、流量）
运营设备成本高，目标要降低成本
各业务线利用率不高，未充分利用设备
各业务模型不同，峰值事件不同，不能进行错峰使用
每个业务都有自己的冗余，多个业务池会造成极大的成本
2、DCP平台介绍
主要思想：业务弹性调度、基础设施支持跨云
业务弹性调度：容器化来抹平运行环境的差异（借助docker）
基础设施支持跨云：
私有云（透明、安全、高性能）----- 按负载迁移（混合云）------公有云（敏捷、低成本、弹性）
固定工作负载 ，放在私有云----- 如根据预警，申请临时阿里云公有云，来进行弹性工作负载（按需申请使用和归还（无需闲置，成本低））
架构图
私有云“化零为整”
二、服务docker化
docker服务启动快
docker镜像一次制作，多次部署
尤其适合动态扩容部署
部署方案设计
PHP服务器包括Nginx、php-fpm、memcache、scribe等几大组件
PHP组件容器单独部署
代码、配置、日志等经常变更部分通过挂载的方式和docker容器互动
镜像制作
镜像方案
首次部署服务
通过下发配置文件、上线代码、启动容器完成服务部署。
代码上线
通过镜像完成上线
代码镜像使用busybox为基础，大小仅1m
创建代码镜像
一些细节
四、弹性扩容
扩容效果：一键式扩容
流量切换
总结
LNMP服务docker化，制作PHP服务先关镜像
结合DP平台完成PHP服务的首次部署、配置更改、代码上线 查看全部
【音频资源晚上放进来】
大会议题：高可用PHP。
一：新浪微博PC主站升级PHP7后的问题分析，新一代LNMP架构，基于混合云平台的弹性扩容架构
新浪微博内部技术体系：
后端语言，Java和PHP两大体系，开放平台用户关系和内容，是Java实现，所有业务需求开发用PHP。
模块并行化
突发大流量如何处理？改善架构，弹性扩容架构
分享大纲
背景和挑战
DCP平台介绍
PHP服务docker化
弹性扩容
1、背景和挑战
突发热点事件，引发大流量
大型活动及三节保障：春节红包飞
PUSH推送，运营的各种站内站外推送
话题业务特点
平时流量稳定，每日峰值波动较小
传统解决方案：提前申请足够的设备
设备冗余的问题，机架位不足，千万级采购成本，采购周期长，运行三个月只为一晚。
服务降级
降级非核心及周边业务
极端情况PC主站只保留主Feed
扩容繁琐，目标实现业务的弹性扩容部署
采购（采购机器）--》基础运维（操作系统、网络）--》业务运维（环境、监控、服务、流量）
运营设备成本高，目标要降低成本
各业务线利用率不高，未充分利用设备
各业务模型不同，峰值事件不同，不能进行错峰使用
每个业务都有自己的冗余，多个业务池会造成极大的成本
2、DCP平台介绍
主要思想：业务弹性调度、基础设施支持跨云
业务弹性调度：容器化来抹平运行环境的差异（借助docker）
基础设施支持跨云：
私有云（透明、安全、高性能）----- 按负载迁移（混合云）------公有云（敏捷、低成本、弹性）
固定工作负载 ，放在私有云----- 如根据预警，申请临时阿里云公有云，来进行弹性工作负载（按需申请使用和归还（无需闲置，成本低））
架构图
私有云“化零为整”
二、服务docker化
docker服务启动快
docker镜像一次制作，多次部署
尤其适合动态扩容部署
部署方案设计
PHP服务器包括Nginx、php-fpm、memcache、scribe等几大组件
PHP组件容器单独部署
代码、配置、日志等经常变更部分通过挂载的方式和docker容器互动
镜像制作
镜像方案
首次部署服务
通过下发配置文件、上线代码、启动容器完成服务部署。
代码上线
通过镜像完成上线
代码镜像使用busybox为基础，大小仅1m
创建代码镜像
一些细节
四、弹性扩容
扩容效果：一键式扩容
流量切换
总结
LNMP服务docker化，制作PHP服务先关镜像
结合DP平台完成PHP服务的首次部署、配置更改、代码上线
大会议题：高可用PHP。
一：新浪微博PC主站升级PHP7后的问题分析，新一代LNMP架构，基于混合云平台的弹性扩容架构
新浪微博内部技术体系：
后端语言，Java和PHP两大体系，开放平台用户关系和内容，是Java实现，所有业务需求开发用PHP。
模块并行化
突发大流量如何处理？改善架构，弹性扩容架构
分享大纲
背景和挑战
DCP平台介绍
PHP服务docker化
弹性扩容
1、背景和挑战
突发热点事件，引发大流量
大型活动及三节保障：春节红包飞
PUSH推送，运营的各种站内站外推送
话题业务特点
平时流量稳定，每日峰值波动较小
传统解决方案：提前申请足够的设备
设备冗余的问题，机架位不足，千万级采购成本，采购周期长，运行三个月只为一晚。
服务降级
降级非核心及周边业务
极端情况PC主站只保留主Feed
扩容繁琐，目标实现业务的弹性扩容部署
采购（采购机器）--》基础运维（操作系统、网络）--》业务运维（环境、监控、服务、流量）
运营设备成本高，目标要降低成本
各业务线利用率不高，未充分利用设备
各业务模型不同，峰值事件不同，不能进行错峰使用
每个业务都有自己的冗余，多个业务池会造成极大的成本
2、DCP平台介绍
主要思想：业务弹性调度、基础设施支持跨云
业务弹性调度：容器化来抹平运行环境的差异（借助docker）
基础设施支持跨云：
私有云（透明、安全、高性能）----- 按负载迁移（混合云）------公有云（敏捷、低成本、弹性）
固定工作负载 ，放在私有云----- 如根据预警，申请临时阿里云公有云，来进行弹性工作负载（按需申请使用和归还（无需闲置，成本低））
架构图
私有云“化零为整”
二、服务docker化
docker服务启动快
docker镜像一次制作，多次部署
尤其适合动态扩容部署
部署方案设计
PHP服务器包括Nginx、php-fpm、memcache、scribe等几大组件
PHP组件容器单独部署
代码、配置、日志等经常变更部分通过挂载的方式和docker容器互动
镜像制作
镜像方案
首次部署服务
通过下发配置文件、上线代码、启动容器完成服务部署。
代码上线
通过镜像完成上线
代码镜像使用busybox为基础，大小仅1m
创建代码镜像
一些细节
四、弹性扩容
扩容效果：一键式扩容
流量切换
总结
LNMP服务docker化，制作PHP服务先关镜像
结合DP平台完成PHP服务的首次部署、配置更改、代码上线
搭建ELK过程中遇到的问题记录
总结 • zkbhj 发表了文章 • 0 个评论 • 1467 次浏览 • 2017-03-07 14:36
一、安装elasticsearch 5.2.2后，启动报错：
问题原因：elasticsearch版本和安装的Java版本不兼容，请教运维朋友后，建议安装elasticsearch 2.4版本，比较成熟稳定。目前市场上用的比较多。
二、安装elasticsearch 2.4.4后，启动报错：
问题原因：明显是目录权限不足。分配可写权限后解决。
三、再次启动，报错：
问题原因：输入switch java，显示：/usr/bin/java
解决方法：启动命令/etc/init.d/elasticsearch start
查看全部
问题原因：elasticsearch版本和安装的Java版本不兼容，请教运维朋友后，建议安装elasticsearch 2.4版本，比较成熟稳定。目前市场上用的比较多。
二、安装elasticsearch 2.4.4后，启动报错：
问题原因：明显是目录权限不足。分配可写权限后解决。
三、再次启动，报错：
问题原因：输入switch java，显示：/usr/bin/java
解决方法：启动命令/etc/init.d/elasticsearch start
查看全部
一、安装elasticsearch 5.2.2后，启动报错：
问题原因：elasticsearch版本和安装的Java版本不兼容，请教运维朋友后，建议安装elasticsearch 2.4版本，比较成熟稳定。目前市场上用的比较多。
二、安装elasticsearch 2.4.4后，启动报错：
问题原因：明显是目录权限不足。分配可写权限后解决。
三、再次启动，报错：
问题原因：输入switch java，显示：/usr/bin/java
解决方法：启动命令/etc/init.d/elasticsearch start
问题原因：elasticsearch版本和安装的Java版本不兼容，请教运维朋友后，建议安装elasticsearch 2.4版本，比较成熟稳定。目前市场上用的比较多。
二、安装elasticsearch 2.4.4后，启动报错：
问题原因：明显是目录权限不足。分配可写权限后解决。
三、再次启动，报错：
问题原因：输入switch java，显示：/usr/bin/java
解决方法：启动命令/etc/init.d/elasticsearch start
#工作总结#对于周末服务器502问题的分享会总结笔记
总结 • zkbhj 发表了文章 • 0 个评论 • 1669 次浏览 • 2017-02-28 11:02
一、问题场景复现：
周六早上9:55左右，ZR的APP间接性出现首页、列表页和详情页无法访问的问题，提示用户“后台接口异常”。通过排查得知，部分接口请求返回的结果是502，通过进一步排查，得知出现502的原因是因为后台应用服务器一共两台，其中一台的php-fpm服务异常，无法处理用户请求导致。（该台服务器周五的时候，运维同事修改过日志归档整理脚本，也是由于这个改动引起的这个问题，后面会说明）
二、处理方式：
排查到这个原因后，立即将服务器的php-fpm服务进行了重启操作，解决了线上服务几乎不可用的状态。
（有问题的正确做法是：摘掉有问题的机器，让正常服务的机器对外提供服务。然后对有问题的机器进行问题排查，分析并找到问题产生的原因，并对问题进行总结和修复，并对其他机器进行排查是否同样有此问题或可能会产生此问题，避免同样的问题再次发生）
三、问题回顾及分析：
在得知线上的问题产生的原因是php-fpm服务挂掉引起的，那是什么原因导致的fpm服务器被“处死”了呢？
通过运维的监控数据分析得知，被改过归档日志脚本的这台机器，在服务器做完归档日志之后，fpm的数量陆续减少，而且在稍后一个时间段有断点，最后在9点50分左右变为0，即线上问题爆发的时间点前后。
然后对修改的脚本日志进行检查，发现日志归档脚本里对fpm进行reload的命令里，有这样一个命令：
其中，用到的是（-HUP信号）kill -HUP `cat $PIDFILE` || echo -n " can't reload"
然而，PHP官方源码中提供的PHP-FPM reload方法中，用的则是（-USR2信号）：kill -USR2 `cat $php_fpm_PID`
PHP官方源码截图（https://github.com/php/php-src/blob/master/sapi/fpm/init.d.php-fpm.in）
问题就出在这！PHP-FPM对HUP和SUR2这两个信号处理方式上的区别。
在PHP-FPM中，对于HUP信号，会进行的操作是重启fpm服务，而USR2信号，则是仅仅对fpm的配置文件进行重载，并不会重启fpm的服务（master）。
对于nginx的这些信号，不同的服务有其各自的处理方式，然而，FPM并没有像大家预想的那样，正是这个差异，让FPM服务在这个脚本命令执行之后，master主服务被“杀死”，而且没有顺利重新启动（报错，报端口9000被占用，因为此时，fpm的works们并没有停止服务，还在接受这请求）。
FPM如何处理各个指令，可以研究源码，地址：https://github.com/php/php-src/blob/e3feeba3aedd8e4347fefa315effd7d4f9fa0ca1/sapi/fpm/fpm/fpm_signals.c
来看一条来自维基百科的解释（https://zh.wikipedia.org/wiki/SIGUSR1%E5%92%8CSIGUSR2 ）：
SIG是信号名的通用前缀。USR是user-defined的缩写，即用户定义的。
SIGUSR1和SIGUSR2的含义在POSIX中没有定义。它们的用途在不同的程序中可能有所不同。
USR1亦通常被用来告知应用程序重载配置文件；
例如，向Apache HTTP服务器发送一个USR1信号将导致以下步骤的发生：停止接受新的连接，等待当前连接停止，重新载入配置文件，重新打开日志文件，重启服务器，从而实现相对平滑的不关机的更改。
然而，对HUP命令的常规描述是：
kill -HUP pid 或者 killall -HUP pName：
其中pid是进程标识，pName是进程的名称。如果想要更改配置而不需停止并重新启动服务，可以使用上面两个命令。在对配置文件作必要的更改后，发出该命令以动态更新服务配置。根据约定，当你发送一个挂起信号(信号1或HUP)时，大多数服务器进程(所有常用的进程)都会进行复位操作并重新加载它们的配置文件。
如果按照上面这个“常规”的用法理解，咱们的设置并没有问题！但是，FPM就是那么“隔路”！！！所以，要看一个命令是否符合自己的预期，一定要进行测试或者使用官方提供的方式。
从上面线上服务器php-fpm.conf的配置项中可以看到，fpm配置了static模式，并且指定了50个children数，每个worker处理的最大请求数是2048（至于为何要进行重启，这是一种自我保护和修复的机制，就像是路由器，每天闲时自动重启一遍，会运行的更加稳定）。正是这50个（可能更少，最多50）worker，支撑了3点之后这段时间内的50*2048（最多，会少于这些）个请求。直至所有worker全部“死掉”之后，线上服务出现了问题。
四、问题总结：
针对此次线上问题，应该总结：
关键业务节点完善报警机制运维方面，nginx要健全健康检查所有的脚本，使用官方提供的源码；网上找的脚本要进行测试关键业务，增加机器出问题先摘掉机器，以便于排查问题原因
五、扩展：
关于fpm如何处理请求，可以参考文章《php-fpm解读-进程管理的三种模式》：http://www.jianshu.com/p/c9a028c834ff
六、其他：
fpm服务重启：/etc/init.d/php-fpm start/stop/restart
php-fpm执行kill下列命令后的结果：
-HUP会杀死进程
此时再去启动php-fpm服务时，报错端口被占用
-USR2顺利重新启动服务（更换了PID）
-USR1未做任何操作（PID未更新）
SIGTERM
程序结束(terminate)信号, 与SIGKILL不同的是该信号可以被阻塞和处理。通常用来要求程序自己正常退出，shell命令kill缺省产生这个信号。如果进程终止不了，我们才会尝试SIGKILL。
参考文档：http://blog.csdn.net/qq646232041/article/details/45642103
查看全部
周六早上9:55左右，ZR的APP间接性出现首页、列表页和详情页无法访问的问题，提示用户“后台接口异常”。通过排查得知，部分接口请求返回的结果是502，通过进一步排查，得知出现502的原因是因为后台应用服务器一共两台，其中一台的php-fpm服务异常，无法处理用户请求导致。（该台服务器周五的时候，运维同事修改过日志归档整理脚本，也是由于这个改动引起的这个问题，后面会说明）
二、处理方式：
排查到这个原因后，立即将服务器的php-fpm服务进行了重启操作，解决了线上服务几乎不可用的状态。
（有问题的正确做法是：摘掉有问题的机器，让正常服务的机器对外提供服务。然后对有问题的机器进行问题排查，分析并找到问题产生的原因，并对问题进行总结和修复，并对其他机器进行排查是否同样有此问题或可能会产生此问题，避免同样的问题再次发生）
三、问题回顾及分析：
在得知线上的问题产生的原因是php-fpm服务挂掉引起的，那是什么原因导致的fpm服务器被“处死”了呢？
通过运维的监控数据分析得知，被改过归档日志脚本的这台机器，在服务器做完归档日志之后，fpm的数量陆续减少，而且在稍后一个时间段有断点，最后在9点50分左右变为0，即线上问题爆发的时间点前后。
然后对修改的脚本日志进行检查，发现日志归档脚本里对fpm进行reload的命令里，有这样一个命令：
其中，用到的是（-HUP信号）kill -HUP `cat $PIDFILE` || echo -n " can't reload"
然而，PHP官方源码中提供的PHP-FPM reload方法中，用的则是（-USR2信号）：kill -USR2 `cat $php_fpm_PID`
PHP官方源码截图（https://github.com/php/php-src/blob/master/sapi/fpm/init.d.php-fpm.in）
问题就出在这！PHP-FPM对HUP和SUR2这两个信号处理方式上的区别。
在PHP-FPM中，对于HUP信号，会进行的操作是重启fpm服务，而USR2信号，则是仅仅对fpm的配置文件进行重载，并不会重启fpm的服务（master）。
对于nginx的这些信号，不同的服务有其各自的处理方式，然而，FPM并没有像大家预想的那样，正是这个差异，让FPM服务在这个脚本命令执行之后，master主服务被“杀死”，而且没有顺利重新启动（报错，报端口9000被占用，因为此时，fpm的works们并没有停止服务，还在接受这请求）。
FPM如何处理各个指令，可以研究源码，地址：https://github.com/php/php-src/blob/e3feeba3aedd8e4347fefa315effd7d4f9fa0ca1/sapi/fpm/fpm/fpm_signals.c
来看一条来自维基百科的解释（https://zh.wikipedia.org/wiki/SIGUSR1%E5%92%8CSIGUSR2 ）：
SIG是信号名的通用前缀。USR是user-defined的缩写，即用户定义的。
SIGUSR1和SIGUSR2的含义在POSIX中没有定义。它们的用途在不同的程序中可能有所不同。
USR1亦通常被用来告知应用程序重载配置文件；
例如，向Apache HTTP服务器发送一个USR1信号将导致以下步骤的发生：停止接受新的连接，等待当前连接停止，重新载入配置文件，重新打开日志文件，重启服务器，从而实现相对平滑的不关机的更改。
然而，对HUP命令的常规描述是：
kill -HUP pid 或者 killall -HUP pName：
其中pid是进程标识，pName是进程的名称。如果想要更改配置而不需停止并重新启动服务，可以使用上面两个命令。在对配置文件作必要的更改后，发出该命令以动态更新服务配置。根据约定，当你发送一个挂起信号(信号1或HUP)时，大多数服务器进程(所有常用的进程)都会进行复位操作并重新加载它们的配置文件。
如果按照上面这个“常规”的用法理解，咱们的设置并没有问题！但是，FPM就是那么“隔路”！！！所以，要看一个命令是否符合自己的预期，一定要进行测试或者使用官方提供的方式。
从上面线上服务器php-fpm.conf的配置项中可以看到，fpm配置了static模式，并且指定了50个children数，每个worker处理的最大请求数是2048（至于为何要进行重启，这是一种自我保护和修复的机制，就像是路由器，每天闲时自动重启一遍，会运行的更加稳定）。正是这50个（可能更少，最多50）worker，支撑了3点之后这段时间内的50*2048（最多，会少于这些）个请求。直至所有worker全部“死掉”之后，线上服务出现了问题。
四、问题总结：
针对此次线上问题，应该总结：
关键业务节点完善报警机制运维方面，nginx要健全健康检查所有的脚本，使用官方提供的源码；网上找的脚本要进行测试关键业务，增加机器出问题先摘掉机器，以便于排查问题原因
五、扩展：
关于fpm如何处理请求，可以参考文章《php-fpm解读-进程管理的三种模式》：http://www.jianshu.com/p/c9a028c834ff
六、其他：
fpm服务重启：/etc/init.d/php-fpm start/stop/restart
php-fpm执行kill下列命令后的结果：
-HUP会杀死进程
此时再去启动php-fpm服务时，报错端口被占用
-USR2顺利重新启动服务（更换了PID）
-USR1未做任何操作（PID未更新）
SIGTERM
程序结束(terminate)信号, 与SIGKILL不同的是该信号可以被阻塞和处理。通常用来要求程序自己正常退出，shell命令kill缺省产生这个信号。如果进程终止不了，我们才会尝试SIGKILL。
参考文档：http://blog.csdn.net/qq646232041/article/details/45642103
查看全部
一、问题场景复现：
周六早上9:55左右，ZR的APP间接性出现首页、列表页和详情页无法访问的问题，提示用户“后台接口异常”。通过排查得知，部分接口请求返回的结果是502，通过进一步排查，得知出现502的原因是因为后台应用服务器一共两台，其中一台的php-fpm服务异常，无法处理用户请求导致。（该台服务器周五的时候，运维同事修改过日志归档整理脚本，也是由于这个改动引起的这个问题，后面会说明）
二、处理方式：
排查到这个原因后，立即将服务器的php-fpm服务进行了重启操作，解决了线上服务几乎不可用的状态。
（有问题的正确做法是：摘掉有问题的机器，让正常服务的机器对外提供服务。然后对有问题的机器进行问题排查，分析并找到问题产生的原因，并对问题进行总结和修复，并对其他机器进行排查是否同样有此问题或可能会产生此问题，避免同样的问题再次发生）
三、问题回顾及分析：
在得知线上的问题产生的原因是php-fpm服务挂掉引起的，那是什么原因导致的fpm服务器被“处死”了呢？
通过运维的监控数据分析得知，被改过归档日志脚本的这台机器，在服务器做完归档日志之后，fpm的数量陆续减少，而且在稍后一个时间段有断点，最后在9点50分左右变为0，即线上问题爆发的时间点前后。
然后对修改的脚本日志进行检查，发现日志归档脚本里对fpm进行reload的命令里，有这样一个命令：
其中，用到的是（-HUP信号）
PHP官方源码截图（https://github.com/php/php-src/blob/master/sapi/fpm/init.d.php-fpm.in）
问题就出在这！PHP-FPM对HUP和SUR2这两个信号处理方式上的区别。
对于nginx的这些信号，不同的服务有其各自的处理方式，然而，FPM并没有像大家预想的那样，正是这个差异，让FPM服务在这个脚本命令执行之后，master主服务被“杀死”，而且没有顺利重新启动（报错，报端口9000被占用，因为此时，fpm的works们并没有停止服务，还在接受这请求）。
FPM如何处理各个指令，可以研究源码，地址：https://github.com/php/php-src/blob/e3feeba3aedd8e4347fefa315effd7d4f9fa0ca1/sapi/fpm/fpm/fpm_signals.c
来看一条来自维基百科的解释（https://zh.wikipedia.org/wiki/SIGUSR1%E5%92%8CSIGUSR2 ）：
然而，对HUP命令的常规描述是：
如果按照上面这个“常规”的用法理解，咱们的设置并没有问题！但是，FPM就是那么“隔路”！！！所以，要看一个命令是否符合自己的预期，一定要进行测试或者使用官方提供的方式。
从上面线上服务器php-fpm.conf的配置项中可以看到，fpm配置了static模式，并且指定了50个children数，每个worker处理的最大请求数是2048（至于为何要进行重启，这是一种自我保护和修复的机制，就像是路由器，每天闲时自动重启一遍，会运行的更加稳定）。正是这50个（可能更少，最多50）worker，支撑了3点之后这段时间内的50*2048（最多，会少于这些）个请求。直至所有worker全部“死掉”之后，线上服务出现了问题。
四、问题总结：
针对此次线上问题，应该总结：
五、扩展：
关于fpm如何处理请求，可以参考文章《php-fpm解读-进程管理的三种模式》：http://www.jianshu.com/p/c9a028c834ff
六、其他：
fpm服务重启：/etc/init.d/php-fpm start/stop/restart
php-fpm执行kill下列命令后的结果：
-HUP会杀死进程
此时再去启动php-fpm服务时，报错端口被占用
-USR2顺利重新启动服务（更换了PID）
-USR1未做任何操作（PID未更新）
SIGTERM
程序结束(terminate)信号, 与SIGKILL不同的是该信号可以被阻塞和处理。通常用来要求程序自己正常退出，shell命令kill缺省产生这个信号。如果进程终止不了，我们才会尝试SIGKILL。
参考文档：http://blog.csdn.net/qq646232041/article/details/45642103
周六早上9:55左右，ZR的APP间接性出现首页、列表页和详情页无法访问的问题，提示用户“后台接口异常”。通过排查得知，部分接口请求返回的结果是502，通过进一步排查，得知出现502的原因是因为后台应用服务器一共两台，其中一台的php-fpm服务异常，无法处理用户请求导致。（该台服务器周五的时候，运维同事修改过日志归档整理脚本，也是由于这个改动引起的这个问题，后面会说明）
二、处理方式：
排查到这个原因后，立即将服务器的php-fpm服务进行了重启操作，解决了线上服务几乎不可用的状态。
（有问题的正确做法是：摘掉有问题的机器，让正常服务的机器对外提供服务。然后对有问题的机器进行问题排查，分析并找到问题产生的原因，并对问题进行总结和修复，并对其他机器进行排查是否同样有此问题或可能会产生此问题，避免同样的问题再次发生）
三、问题回顾及分析：
在得知线上的问题产生的原因是php-fpm服务挂掉引起的，那是什么原因导致的fpm服务器被“处死”了呢？
通过运维的监控数据分析得知，被改过归档日志脚本的这台机器，在服务器做完归档日志之后，fpm的数量陆续减少，而且在稍后一个时间段有断点，最后在9点50分左右变为0，即线上问题爆发的时间点前后。
然后对修改的脚本日志进行检查，发现日志归档脚本里对fpm进行reload的命令里，有这样一个命令：
其中，用到的是（-HUP信号）
kill -HUP `cat $PIDFILE` || echo -n " can't reload"然而，PHP官方源码中提供的PHP-FPM reload方法中，用的则是（-USR2信号）：
kill -USR2 `cat $php_fpm_PID`
PHP官方源码截图（https://github.com/php/php-src/blob/master/sapi/fpm/init.d.php-fpm.in）
问题就出在这！PHP-FPM对HUP和SUR2这两个信号处理方式上的区别。
在PHP-FPM中，对于HUP信号，会进行的操作是重启fpm服务，而USR2信号，则是仅仅对fpm的配置文件进行重载，并不会重启fpm的服务（master）。
对于nginx的这些信号，不同的服务有其各自的处理方式，然而，FPM并没有像大家预想的那样，正是这个差异，让FPM服务在这个脚本命令执行之后，master主服务被“杀死”，而且没有顺利重新启动（报错，报端口9000被占用，因为此时，fpm的works们并没有停止服务，还在接受这请求）。
FPM如何处理各个指令，可以研究源码，地址：https://github.com/php/php-src/blob/e3feeba3aedd8e4347fefa315effd7d4f9fa0ca1/sapi/fpm/fpm/fpm_signals.c
来看一条来自维基百科的解释（https://zh.wikipedia.org/wiki/SIGUSR1%E5%92%8CSIGUSR2 ）：
SIG是信号名的通用前缀。USR是user-defined的缩写，即用户定义的。
SIGUSR1和SIGUSR2的含义在POSIX中没有定义。它们的用途在不同的程序中可能有所不同。
USR1亦通常被用来告知应用程序重载配置文件；
例如，向Apache HTTP服务器发送一个USR1信号将导致以下步骤的发生：停止接受新的连接，等待当前连接停止，重新载入配置文件，重新打开日志文件，重启服务器，从而实现相对平滑的不关机的更改。
然而，对HUP命令的常规描述是：
kill -HUP pid 或者 killall -HUP pName：
其中pid是进程标识，pName是进程的名称。如果想要更改配置而不需停止并重新启动服务，可以使用上面两个命令。在对配置文件作必要的更改后，发出该命令以动态更新服务配置。根据约定，当你发送一个挂起信号(信号1或HUP)时，大多数服务器进程(所有常用的进程)都会进行复位操作并重新加载它们的配置文件。
如果按照上面这个“常规”的用法理解，咱们的设置并没有问题！但是，FPM就是那么“隔路”！！！所以，要看一个命令是否符合自己的预期，一定要进行测试或者使用官方提供的方式。
从上面线上服务器php-fpm.conf的配置项中可以看到，fpm配置了static模式，并且指定了50个children数，每个worker处理的最大请求数是2048（至于为何要进行重启，这是一种自我保护和修复的机制，就像是路由器，每天闲时自动重启一遍，会运行的更加稳定）。正是这50个（可能更少，最多50）worker，支撑了3点之后这段时间内的50*2048（最多，会少于这些）个请求。直至所有worker全部“死掉”之后，线上服务出现了问题。
四、问题总结：
针对此次线上问题，应该总结：
- 关键业务节点完善报警机制
- 运维方面，nginx要健全健康检查
- 所有的脚本，使用官方提供的源码；网上找的脚本要进行测试
- 关键业务，增加机器
- 出问题先摘掉机器，以便于排查问题原因
五、扩展：
关于fpm如何处理请求，可以参考文章《php-fpm解读-进程管理的三种模式》：http://www.jianshu.com/p/c9a028c834ff
六、其他：
fpm服务重启：/etc/init.d/php-fpm start/stop/restart
php-fpm执行kill下列命令后的结果：
-HUP会杀死进程
此时再去启动php-fpm服务时，报错端口被占用
-USR2顺利重新启动服务（更换了PID）
-USR1未做任何操作（PID未更新）
SIGTERM
程序结束(terminate)信号, 与SIGKILL不同的是该信号可以被阻塞和处理。通常用来要求程序自己正常退出，shell命令kill缺省产生这个信号。如果进程终止不了，我们才会尝试SIGKILL。
参考文档：http://blog.csdn.net/qq646232041/article/details/45642103
面试初中级开发工程师需要注意的方面
面试 • zkbhj 发表了文章 • 0 个评论 • 1634 次浏览 • 2017-02-17 10:15
1、逻辑思维能力：抛出一个场景，让面试者思考如何实现，从中提出问题，考察面试者的逻辑思维能力；
2、学习能力：从学历、意愿、自己的项目（github\blog）,是否经常参加社团活动、是否经常阅读技术书籍，已经自驱能力等；
3、成长规划：对自己的定位、最近一年的规划计划；
4、基本技能：PHP基本技能、前端、服务器、缓存、数据库、设计模式、工具使用、框架等；
5、沟通能力：职业经历中遇到的通过自己的努力解决问题的事情；面试过程中的说话谈吐；
6、
查看全部
2、学习能力：从学历、意愿、自己的项目（github\blog）,是否经常参加社团活动、是否经常阅读技术书籍，已经自驱能力等；
3、成长规划：对自己的定位、最近一年的规划计划；
4、基本技能：PHP基本技能、前端、服务器、缓存、数据库、设计模式、工具使用、框架等；
5、沟通能力：职业经历中遇到的通过自己的努力解决问题的事情；面试过程中的说话谈吐；
6、
查看全部
1、逻辑思维能力：抛出一个场景，让面试者思考如何实现，从中提出问题，考察面试者的逻辑思维能力；
2、学习能力：从学历、意愿、自己的项目（github\blog）,是否经常参加社团活动、是否经常阅读技术书籍，已经自驱能力等；
3、成长规划：对自己的定位、最近一年的规划计划；
4、基本技能：PHP基本技能、前端、服务器、缓存、数据库、设计模式、工具使用、框架等；
5、沟通能力：职业经历中遇到的通过自己的努力解决问题的事情；面试过程中的说话谈吐；
6、
2、学习能力：从学历、意愿、自己的项目（github\blog）,是否经常参加社团活动、是否经常阅读技术书籍，已经自驱能力等；
3、成长规划：对自己的定位、最近一年的规划计划；
4、基本技能：PHP基本技能、前端、服务器、缓存、数据库、设计模式、工具使用、框架等；
5、沟通能力：职业经历中遇到的通过自己的努力解决问题的事情；面试过程中的说话谈吐；
6、