欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  后端开发

用 PHP 编写支持高并发的网站,需要做什么处理?

程序员文章站 2022-04-16 10:12:58
...
但是很难做静态化啊,像做一个微博那样子的东西,并发又高,跟新又快,这种需求的话,应该怎么处理呢?

回复内容:

一般来说,解决WEB高并发的有效手段都是采用可线性扩展的多层分布式架构,
我生产项目的架构是这样的,就在这里抛砖引玉一下。
  1. Webserver (Nginx) :这一层是可以轻松分布式部署的,结合智能DNS解析可以简易地防止单点故障、实现区域访问加速,结合LVS很容易实现负载均衡。这一层主要是负责处理静态请求和转发PHP请求至第二层的PHP处理节点,至于静态资源地址(misc.xxxx.com)可以单独拿出来部署,或者直接使用商用的云存储服务(国内七牛不错,国外有Amazon S3)
  2. PHP处理节点:一个节点其实就是一个监听特定端口的系统进程,webserver的请求通过负载均衡器(我用的AWS的loadbalancer)进行分发,很好实现分布式和负载均衡。我现在用的还是php自带的php-fpm,其实facebook出的hhvm性能非常强悍,但是还不能100%通过我项目的单元测试,等hhvm成熟过后可以平滑替换
  3. 高速缓存:用的memcached,这一层的作用主要是减轻数据库IO和加快热数据访问,缓存策略与程序耦合度较高,不赘述,但简单地说有两种方式,一种是在程序的全局层面加一个缓存处理,这种方法代码耦合度低,但是有效命中率不高,有些项目不一定适应,另一种是在具体的数据存取处加缓存处理,这种办法程序耦合度较高,但是缓存命中率非常高,几乎没有无效缓存存在,我用的是这种。
  4. 数据库 :我现在的项目数据规模不大,暂时只用了单台数据库,但是程序逻辑上已做好了数据库线性扩展的准备。其实数据库层的扩展是老生常谈了,常用手段是分库分表,这一块需要在前期的代码就打下基础,另外更平滑地手段是使用中间件,比如360的Atlas,阿里巴巴的cobar,淘宝的TDDL,中间件可以在不大范围变更代码的情况下扩展,但是具体的使用场景还是有限的,具体项目还需单独考察。
  5. 其他:根据不同的项目,架构还可以选择性地使用队列,我现在用的beantalkd,Redis也是一个很好的选择。队列常用的使用环境是邮件发送和站内消息推送上面,但是在某些场景下也可以作为核心数据库的缓冲,对应对大并发或者突发性流量也是不错的选择
一般使用LVS+PHP集群(1000台),就算日均80亿次请求,每秒有10万并发,那分到每台机器的请求只有100个。只要你的PHP程序不是太差,100QPS总没问题吧?

而真正的瓶颈在于数据库和存储系统,数据的一致性,可扩展性,可用性很难保证。所以需要根据具体的业务场景再做横向和纵向的分库分表。

再辅以memcache集群缓存,key-value高性能存储,异步队列任务系统,整个架构就可以建立起来。

还有一类是真正的高并发,比如WebIM,一台机器要承受数十万的TCP客户端连接,进行大规模的实时通信。这种的可以用PHP的异步高并发扩展swoole 。链接:Swoole: PHP的异步、并行、分布式扩展框架 亿级Web系统搭建——单机到分布式集群
【问底】徐汉彬:亿级Web系统搭建——单机到分布式集群-CSDN.NET 这个问题能写本书了、
PHP网站的瓶颈基本在数据库上。
一般中小项目,硬件比人力便宜,老板都是会算账的。别说主从同步了,那只能解决实时性不高的场景。比如12306,用户A在第一台DB里下了单,还没传到第100号DB,这时候第100号DB已经接受用户B下单了。

恩,那就减少数据库连接吧,100个用户读一样的内容,那么读一次就行了。于是有了cache。
有了cache也有问题啊,比如怎么保证cache和数据库的内容一致,缓存失效一下子涌到DB怎么办?

恩,上面那个问题等遇见再谈吧。 前面讲了减少读,现在要讲减少写,减少写的频率。 比如微博里给一群好友发条信息,实际上好多没上线的,把上线的那些用户的消息放在Redis里,数据不急着更新。

有钱,能不能再加台DB服务器,反正服务器便宜?每台各存一部分数据,要偶数id的帖子到A服务器去拿,奇数到B服务器拿。 什么?帖子按照时间排序怎么办?按照点击数排序怎么办? 新搞个DB服务器去存点击数和帖子id,有了id啥都好办。 再有乱七八糟的需求找搜索团队支持,实时性不高都好办。另外看看访问量大的搞几个缓存。

N条评论,但是点了是空列表?这些功能99%可用就行,ICP说不定也有问题,用户点一次没反应,再点一次就行。

图片。文件小啊,linux inode有限制。 把所有图片保存在几个大文件里,建个服务读取。

音乐,视频服务。

违规文字,音乐版权,小视频,慢慢头痛吧。 yishan 一层层剥开来讲,有以下部位需要注意。
1.资源。能静态实现的就静态实现,静态资源也要尽量使用分布式存储,例如云存储。
2.效率。PHP代码里,尽量注意内存的使用,单个脚本的运行效率要Ok.
3.缓存。使用memcache来实现非持久存储,使用no-sql来实现持久存储。
4.server。使用nginx+fpm或者nginx+apache,来实现动静态分离访问。
5.mysql。作为最终的存储库以及一些不可避免的实时调用库,做主从处理,Master+多Slave,多个只读副本来实现实时的调用库。
6.负载。建议架设一层负载均衡,来实现web server的轮询。例如云平台中的LBS。 真不知道这个世界上有多少“亿级PV”的网站。
真上有上亿PV的网站现在一定不会再问这样的问题。 能静态化的静态化
不能静态化的用分布式算法


最好不要将运算交给数据库,尤其是复杂的算法

做静态化 这样就减少了数据库的压力
php是一个语言工具,由php来把apache/nginx/memcache/redis/mysql/httpds等工具组合到一起,根据具体的业务需求,选取不同的系统架构模型;高并发其实考验的是系统的架构
1. 数据的读写层
高并发更多考验的是数据的读写,最终考验的是根据具体的业务需求进行系统的架构;哪些数据要满足实时读写,哪些数据可以异步读写等要考虑好;数据的读写模型分析清楚后就要设计数据的存储方案,mysql擅长的是关系数据和数据统计,但是并发访问是瓶颈;memcache擅长的是数据缓存,但kv的数据结构有限;redis作为内存数据库但内存空间毕竟没有硬盘空间大;
各有优缺点,那么就要根据自己的业务来综合或者选取用这些工具
2. 静态/动态访问
有条件的就使用cdn,没条件的至少弄一个静态访问层,至于使用apache还是nginx或者其它的,自己在虚拟机上都安装一遍,做一个压力测试对比一下
非静态访问转发到动态访问层
3. 逻辑处理即php
到php了,php承接动态访问的输入,进行逻辑运算,最后到数据层去进行读写;
别做太傻的事就可以了,比如无谓的foreach循环,复制等操作;再比如,对于实时访问,对10个数据进行排序,就不要再用mysql 的select order by 了,直接用php的函数来排序就好了。