Home  >  Article  >  Backend Development  >  PHP 大流量优化?

PHP 大流量优化?

WBOY
WBOYOriginal
2016-06-17 08:31:331738browse

现在网站流量大幅上升 我们技术组基本的思路是 所有的PHP与mysql脱钩 中间加入缓存层 比如会员报名先写入服务器内存 然后统一的时间一起写入数据库 请问中间的缓存层会用到哪些技术 对这个重来没有接触过

回复内容:

如果是觉得mysql的读和写是瓶颈的话(mysql的查询和写入耗时很长,或者量级比较大),的确可以引入中间缓存。
搭建mysql和PHP之间的缓存,推荐直接使用redis作为中间缓存服务。

不过,还是需要分析下为什么是mysql的读和写耗时很长,才能够真正解决你系统的问题,可以开启mysql的慢查询日志分析下。
读和写如果有问题,可以往这几个方面做下尝试:
(1)sql语句是不是合理的,是否带有太多的表join等操作?
(2)table的记录是否太多了,好几百万的数据,是否需要分库分表或者分区?
(3)是否使用了合适的索引,sql查询语句是否有充分利用索引字段?
(4)可以通过调整mysql配置参数,来优化mysql读和写的性能,例如增大innodb_buffer_pool_size,提高缓存的命中率等。
(5)mysql如果是单台部署,可以考虑主从分离,或者搭建主主互备。
... ...

如果觉得mysql在上述优化之后,仍然存在一些瓶颈,再引入redis作为中间cache也并不迟。

其实,我上面写的只是冰山一角,可以优化的地方还有非常多哈。
早期写的一篇文章:
亿级Web系统搭建――单机到分布式集群 优化不难,但需要对症下药。

题主,你的问题描述,没说症状,没查病因,就直接跳跃到制定治疗方案:【所有的PHP与mysql脱钩......】,这真的好? 我是来关注问题的,不过。。。现在大部分内存缓存都是对读做优化的。。。对写优化的解决方案???

我其实是来关注问题的。。 先应该找出症结,而不应该盲目优化。

常见的写入引起系统速度慢通常是计数这种频繁写入的场景,比如:每访问页面一次,pv字段+1,频繁写入导致MySQL的查询缓存刚创建就马上失效,相当于没发挥作用。这种情况是很适合搞个缓冲区(写入极频繁、无数据一致性要求),来存放新增的pv的,当缓冲区满了,再一次性写入。

你说的“所有的PHP与mysql脱钩 中间加入缓存层”就不太好,其实大部分情况下你所谓的缓存层不过是把mysql的查询缓存功能废了自己接管,意义不大。而且像报名这种重要的数据也不适合缓存,一旦缓存丢失,比较麻烦。 你说的这个中间层 叫队列,可以用redis的list去做 最好还是先优化一下读写MySQL的业务逻辑,会员注册报名这种功能都需要加缓存了,那跑起来得多慢 缓存挂了你这数据难道不要了?不是在开玩笑吧。
缓存优化的是读,写数据不要走这邪路。 1.缓存
规划下目标数据的更改频率和读写频率。
读写频率:更改频率 值越大,越适合做缓存;值小的就别做了

2.优化SQL
大部分的初级系统的SQL 优化程度都不高……
索引的使用、单一查询是否过大、联表查询替换为单表查询
MYISAM替换为INNODB 这类的……

3.优化系统架构
单一页面中涉及的内容是否太多,是否有不必要的数据展示
能否将很多的功能与系统拆分成不同的业务模块 分开展示

4.静态化页面
静态页面比起动态页面来自然会消耗小的多

5.缓存数据延时读取
写入队列、缓存暂存数据(比如计数器) 都属于这种

6.异步式获取数据

7.分布式架构
数据库的读写分离 , 多台数据库服务器 乃至 多台PHP服务器 等 读这篇,全部读懂再说:
编辑于 2014-05-07 有时候的瓶颈不一定在数据库,先搞清楚是前端还是后端问题。如果是前端就要做各种优化处理,包括缓存静态文件,合并并且压缩css, js等文件,尽量减少HTTP request等等。如果是后端数据库读写性能问题就先做下Profiling找下瓶颈在哪。如果真的是要加缓存层建议用Redis, 支持数据持久化。另外可以考虑消息队列异步处理通信,达到程序解耦的目的。消息队列可以很好地应付 突然的峰值流量,个人推荐RabbitMQ,我们公司也在用。还有就是可以使用独立的全文搜索引擎,降低数据库的搜索压力,Solr, ElasticSearch都好用,我自己用的是Solr。
Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact [email protected]