架构优化

高并发 高可用

  • 对整个链路上各个步骤进行优化
    • cdn,nginx,php-fpm
    • 业务逻辑
    • 数据库
  • 对系统进行扩容,并且优化不能进行线性扩容的点(使得整个系统可以进行线性扩容)

nginx

  • 调整系统文件打开数限制
  • 调整每个进程的mac_connections
  • 线程池,异步io
  • 浏览器异步对同个域名下的并发连接有数量限制
  • nginx worker进程数,max_connections 每个进程维持的最大连接数(可能需要调整linux系统文件打开数)

swoole 跑httpserver

mysql ,redis长连接

  • 业务扩张,数据使用放不断增加的情况下,将数据库连接收归service层,避免过多连接查过mysql的连接数限制

  • 分离静态资源

  • 使用php7,开启opcache

  • 高频计算逻辑,使用php扩展来实现,或者使用go来写,然后提供rpc调用

mysql索引优化

数据库优化

  • 在内存有限的情况下,区分快慢数据库
    • 需要高并发的数据库实例占用跟多内存
    • 使用Raid磁盘阵列增加磁盘写入性能
    • 使用ssd增加硬盘随机读性能
    • 调整fsync强制磁盘刷新机制,降低刷新频率,能显著提升性能,不过发送意外时,未刷新到磁盘的数据会丢失
    • 使用Raid的write back功能,也可以显著提升性能,需要有BBU(Battery Backup Unit)电池备份单元,否则同样有数据丢失的
  • 如果瓶颈是读库操作,就增大内存,优化缓存策略
  • 如果瓶颈是写操作,就降低刷新磁盘的频率

缓存失效,瞬间大量请求可能会直接访问数据库时的优化措施

  • 主要防止并发更新
  • 对底层数据库的访问加锁
  • 异步队列更新数据
  • 对没有锁的请求,进行二次缓存查询(一般这个时候已经更新好了)

风险 * lvs

  • 高峰时期性能优化,熔断,服务降级
  • 二八法则

  • 如果项目功能很简单,也不需要暴露给其他业务方调用,即使访问量很大,也不需要做服务化

  • 如果业务复杂,进行业务拆分,部署成单独的服务

高内聚,低耦合

  • 互相关联,尤其是需要放在一个事务里面的操作,尽量放在同一个服务当中
  • 互相没有关联的业务应该进行拆分
  • 核心数据缓存在redis中,设置一定量的过期时间比如一周
  • 使用redis在很多场景可以替代

*只要程序本身没有明显的问题,性能瓶颈肯定先出现IO上,文件IO,或者网络IO

浏览器的一个请求从发送到返回都经历了什么 1、先从网络模型层面:

client (浏览器)与 server 通过 http 协议通讯,http 协议属于应用层协议,http 基于 tcp 协议,所以 client 与 server 主要通过 socket 进行通讯;

而 tcp 属于传输层协议、如果走 https 还需要会话层 TLS、SSL 等协议; 传输层之下网络层,这里主要是路由协议 OSPF 等进行路由转发之类的。再向下数据链路层主要是 ARP、RARP 协议完成 IP 和 Mac 地址互解析,再向下到最底层物理层基本就是 IEEE 802.X 等协议进行数据比特流转成高低电平的的一些定义等等;

当浏览器发出请求,首先进行数据封包,然后数据链路层解析 IP 与 mac 地址的映射,然后上层网路层进行路由查表路由,通过应用层 DNS 协议得到目标地址对应的 IP ,在这里进行 n 跳的路由寻路;而传输层 tcp 协议可以说下比较经典的三次握手、四次分手的过程和状态机,这里放个图可以作为参考:

2、应用层方面:

数据交换主要通过 http 协议, http 协议是无状态协议, post、get 的区别以及 RESTFul 接口设计,然后可以讲服务器 server 模型 epoll、select 等,

This article is my 16th oldest. It is 118 words long