使用 mixphp 处理其他框架 20% 的高并发部分

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

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

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

瓶颈分析

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

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

具体会有哪些场景

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

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

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

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

如何使用 mixphp 优化

1. 高并发场景（写库 / 或者耗时计算）：

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

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

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

DEMO (V1)：https://github.com/mix-php/mi...

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

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

2. 高并发频繁查询场景（增加缓存依然达到瓶颈）：

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

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

DEMO (V1)：https://github.com/mix-php/mi...

3. 大量数据计算场景：

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

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

MixPHP

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