php 高并发解决思路解决方案

php 高并发解决思路解决方案，如何应对网站大流量高并发情况。本文为大家总结了常用的处理方式，但不是细节，后续一系列细节教程给出。希望大家喜欢。

一 高并发的概念

在互联网时代，并发，高并发通常是指并发访问。也就是在某个时间点，有多少个访问同时到来。

二 高并发架构相关概念

1、QPS (每秒查询率) : 每秒钟请求或者查询的数量，在互联网领域，指每秒响应请求数(指 HTTP 请求)

2、PV（Page View）：综合浏览量，即页面浏览量或者点击量，一个访客在 24 小时内访问的页面数量

--注：同一个人浏览你的网站的同一页面，只记做一次 pv

3、吞吐量（fetches/sec） ：单位时间内处理的请求数量 （通常由 QPS 和并发数决定）

4、响应时间：从请求发出到收到响应花费的时间

5、独立访客（UV）：一定时间范围内，相同访客多次访问网站，只计算为 1 个独立访客

6、带宽：计算带宽需关注两个指标，峰值流量和页面的平均大小

7、日网站带宽： PV/统计时间（换算到秒） * 平均页面大小（kb）* 8

三 需要注意点：

1、QPS 不等于并发连接数（QPS 是每秒 HTTP 请求数量，并发连接数是系统同时处理的请求数量）

2、峰值每秒请求数（QPS）= （总 PV 数*80%）/ （六小时秒数*20%）【代表 80%的访问量都集中在 20%的时间内】

3、压力测试： 测试能承受的最大并发数 以及测试最大承受的 QPS 值

4、常用的性能测试工具【ab，wrk，httpload，Web Bench，Siege，Apache JMeter】

四 优化

1、当 QPS 小于 50 时

优化方案:为一般小型网站,不用考虑优化

2、当 QPS 达到 100 时,遇到数据查询瓶颈

优化方案: 数据库缓存层,数据库的负载均衡

3、当 QPS 达到 800 时, 遇到带宽瓶颈

优化方案:CDN 加速,负载均衡

4、当 QPS 达到 1000 时

优化方案: 做 html 静态缓存

5、当 QPS 达到 2000 时

优化方案: 做业务分离,分布式存储

五、高并发解决方案案例:

1、流量优化

防盗链处理(去除恶意请求)

2、前端优化

(1) 减少 HTTP 请求[将 css,js 等合并]

(2) 添加异步请求(先不将所有数据都展示给用户,用户触发某个事件,才会异步请求数据)

(3) 启用浏览器缓存和文件压缩

(4) CDN 加速

(5) 建立独立的图片服务器(减少 I/O)

3、服务端优化

(1) 页面静态化

(2) 并发处理

(3) 队列处理

4、数据库优化

(1) 数据库缓存

(2) 分库分表,分区

(3) 读写分离

(4) 负载均衡

5、web 服务器优化

(1) nginx 反向代理实现负载均衡

(2) lvs 实现负载均衡

一、What

跨团队联合项目管理：顾名思义，是管理一个两支（或两支以上）的团队共同完成的项目，其中，各方并无特别明显主导与配合的角色之分。

同时，补充两个较生词汇：高并发和隐性。

高并发：在服务器后台，我们常用qps（每秒访问次数）来反映服务请求并发数的多寡，同理，当同一时段中项目总数量（尤其是与人数的比例）超出某阈值时，我们称之为高并发；

隐性：说白了，就是老大当下并不那么关心的项目。

二、Why

1、新的挑战

从上表可见，隐性高并发跨团队联合项目管理，面临了诸多因素的管理困境，是跨团队的、高并发的、隐性所可能带来的项目管理难题的合集。

2、新形势

互联网行业发展迅猛，竞争异常激烈，不进则退。这几年，我们很多产品都在大跨步前进，追赶细分领域的行业第一，除了常规的版本日常发版外，各种跨公司跨事业部的重点重大战役没少打，跨团队联合项目的总数随时间整体呈上升趋势（暂无数据支撑）。其中，高并发以及隐性高并发作为跨团队联合项目管理的子类（或子类的子类），总数也必须在快速增长，不容小觑。

3、if not, then...

如果对于隐性高并发跨团队联合项目，不给予足够甚至针对性的重视，会导致一系列问题：

 若仅是一般跨团队联合项目，所带来的问题不在这里展开，暂略；

 若同时是高并发的，如得不到应有重视，很可能会造成人力匮乏，捉襟见肘，团队混乱，切换浪费较为普遍；

 若同时是隐性的，如得不到应有重视，很可能会士气起落，人员归属感弱、进出频繁，若该项目是大项目/项目集的一部分，则很可能在项目后期成为总项目的最长路径。

三、How

1、实战案例

实例一：百度糯米白条项目

这是典型的显性跨团队联合项目，因为是白条支付功能实现是公司级的重大决策，该项目一旦实现糯米将成为第一家支持白条支付的O2O产品（超越美团），百度金融也将迎来一拨值得期待的授信、用信用户，钱包也将获得一些拉新用户。在此背景下，三大产品线背靠三大体系，采用了最紧密的协作方式，开展联合项目管理，诸如沟通地图、日报、周报等，糯米侧的项目工作早在2016年春节就全部结束；

实例二：百度糯米交易中心的不到十人，却同时承载着约50个项目；

这是个隐性高并发跨团队联合项目。在实例中，因为交易中心处于整个糯米技术架构的中心，所以交易中心的几乎所有项目都是跨团队联合项目。目前所有项目是整合在一起以一个大站会进行的，整体的项目打包是经过立项审核的，但因为项目数量太多，即使人均仅负责一个项目，依然有5-6个项目/人，所以，对于每一位具体的RD工程师，都有可能有若干条隐性高并发项目风险埋伏在前面。作为项目负责人，我们应该怎么帮助团队尽可能降低这类风险呢？

2、如何做

以下，结合案例经验，附上一些方法心得：

1）别挑活、Keep hands dirty

不仅对自己，包括对项目组成员，必须树立这种意识。只要项目有业务收益，应该有人做，这是我们做不做该项目的标准。至于干活为了抢功，为了表现，那就赶紧滚到火星上去吧。

所以，端正心态，让团队投入到事情本身，这是非常重要的基础。

2）保持对项目价值（是否应该是隐性）的察觉

有时，被忽略是一种错误；有时，被忽略，在那时那刻，就是对的。作为项目管理者，当我们遇到是前者时，责无旁贷，需要争取老大对该项目的重视，升级该项目为显性项目。这时，争取来的一次机会，比如项目汇报、原型演示，甚至电梯演讲，都可能是项目的转折点。

所以，保持对项目价值的察觉，及时争取老大对项目的重视，是非常重要的方法。

3）风险管理的分阶段不同策略

在多项目并发前期时，，显性项目容易获得资源，容易得到启动，这时，隐性项目一般还未启动，或暂时pending在某一步骤，以低级别风险存在着。随著多项目的整体推进，尤其是进去项目中后期时，这时，显性项目逐个完成或者某显性项目的往下开展会依赖于某些隐性项目。这时，隐性项目的关注度会逐步凸显，同时，隐性项目在开头和结尾时，还有可能会被拿掉，所以，这时的风险管理，必须首先确认下，这个项目是否确定要做。

所以，在项目的不同阶段，主动采用不同的风险管理策略，是种常用的方法。

4）接受可能失败的勇气

如前所述，跨团队联合项目管理是件难事，而隐性高并发跨团队联合项目管理则是件难上加难的事情。虽然世上无难事，只要有心人，但是难易还是客观存在在那里。项目的失败有很多中原因，比如，铁三角被打破后难以再平衡，项目最后时刻关键干系人跳出来否决了项目成果，也包括咱们这里所说的隐性高并发，因为没人没关注，最终活活饿死，甚至还包括项目做的很漂亮，但是上线后数据不理想，深层次暴露出业务战略出了问题等。

所以，管理无定式，没有绝对包治百病且立竿见影的方法。尽人力，听天命，成败好好总结，不断改进，不怕输，不怕败，这是最终极的方法。

---