使用 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/