经常在群里听到一些朋友问:TP 的项目怎么迁移到 mixphp 来处理高并发,我通常都是回复需要重写,可是一个开发很久的 TP 项目,代码量巨大,又怎么可能会花大量时间成本来重写呢?

那么为何我们不尝试换一种思路来解决问题?

在现有框架不变的情况下,引入 mixphp 来处理高并发的部分。

瓶颈分析

二八效应在任何领域都存在,如果你做过多个项目,你就会发现:

一个项目中高并发的接口或页面,通常只占到项目的 20% 以下。

具体会有哪些场景

一些常见的高并发场景的问题:

  • APP 用户数据采集接口:由于是通过接口按秒定时上传用户数据,随着用户量的增长,QPS 极高,该类型需求是写库动作,无法使用缓存优化。
  • 股票行情展示:由于需每秒查询股票的实时数据,随着用户量的增长,QPS 极高,即便可以使用缓存给数据库减压,但是频繁的请求任然使应用服务器不堪重负。

一些常见的大量计算场景的问题:

  • 定时统计:定时统计表中大量的数据,一个进程计算太慢,多个进程计算又有数据不同步的问题。

如何使用 mixphp 优化

1. 高并发场景(写库 / 或者耗时计算):

在 TP 的接口中使用消息队列,把要入库的数据写入 redis 的 list 类型中。

$redis->lpush($key, $data);

然后在 mixphp 中使用多进程服务来消费这个队列:

DEMO:https://github.com/mixstart/m...

mixphp 的多进程服务有很多传统框架所不具备的特点:

  • 平滑重启:当 kill 主进程时,子进程处理完工作再退出,不丢失数据。
  • 高容错:子进程异常奔溃时,主进程将重建子进程。
  • 高性能:多进程运行,充分利用多个CPU并行计算,性能强劲。
  • 使用灵活:工作进程使用生产者消费者模型,生产者/消费者的数量都可自定义。

2. 高并发频繁查询场景(增加缓存依然达到瓶颈):

该种场景瓶颈已经不在数据库,因为 HTTP 接口是请求响应式,如此频繁的请求,不断的建立与关闭连接消耗了太多的服务器性能,这时需使用长连接协议 WebSocket 来优化。

使用 mixphp 的 WebSocketd 封装,能很快就搭建一个数据推送系统,解决 API 轮询的性能瓶颈:

DEMO:https://github.com/mixstart/m...

3. 大量数据计算场景:

如果从一个数据表中取出大量数据,一个进程计算又太慢了,如果分多个进程分页去查询后,再分开计算,速度是快了,但是如果查询中数据有变化,因为每个进程分别会查一次数据库,就会导致有的数据遗漏没有计算到、有的又被多次计算,导致计算结果错误。

这时使用 mixphp 的多进程服务就不会有这个问题,mixphp 的多进程服务在进程内部做了生产者消费者模型,只需使用一个进程去数据表取出数据,然后一行一行发送给消费者进程去计算,这样就高效安全的完成了一次大量计算。

MixPHP

GitHub: https://github.com/mixstart/m...
官网:http://www.mixphp.cn/

你可能感兴趣的文章

载入中...
細変 細変

40 声望