经常在群里听到一些朋友问：TP 的项目怎么迁移到 mixphp 来处理高并发，我通常都是回复需要重写，可是一个开发很久的 TP 项目，代码量巨大，又怎么可能会花大量时间成本来重写呢？
那么为何我们不尝试换一种思路来解决问题？
在现有框架不变的情况下，引入 mixphp 来处理高并发的部分。
瓶颈分析
二八效应在任何领域都存在，如果你做过多个项目，你就会发现：
一个项目中高并发的接口或页面，通常只占到项目的 20% 以下。
具体会有哪些场景
一些常见的高并发场景的问题：
APP 用户数据采集接口：由于是通过接口按秒定时上传用户数据，随着用户量的增长，QPS 极高，该类型需求是写库动作，无法使用缓存优化。
股票行情展示：由于需每秒查询股票的实时数据，随着用户量的增长，QPS 极高，即便可以使用缓存给数据库减压，但是频繁的请求任然使应用服务器不堪重负。
一些常见的大量计算场景的问题：
定时统计：定时统计表中大量的数据，一个进程计算太慢，多个进程计算又有数据不同步的问题。
如何使用 mixphp 优化
1. 高并发场景（写库 / 或者耗时计算）：
在 TP 的接口中使用消息队列，把要入库的数据写入 redis 的 list 类型中。
$redis->lpush($key, $data);
然后在 mixphp 中使用多进程服务来消费这个队列：
DEMO：https://github.com/mixstart/mixphp/blob/master/apps/daemon/commands/MultiCommand.php
mixphp 的多进程服务有很多传统框架所不具备的特点：
平滑重启：当 kill 主进程时，子进程处理完工作再退出，不丢失数据。
高容错：子进程异常奔溃时，主进程将重建子进程。
高性能：多进程运行，充分利用多个CPU并行计算，性能强劲。
使用灵活：工作进程使用生产者消费者模型，生产者/消费者的数量都可自定义。
2. 高并发频繁查询场景（增加缓存依然达到瓶颈）：
该种场景瓶颈已经不在数据库，因为 HTTP 接口是请求响应式，如此频繁的请求，不断的建立与关闭连接消耗了太多的服务器性能，这时需使用长连接协议 WebSocket 来优化。
使用 mixphp 的 WebSocketd 封装，能很快就搭建一个数据推送系统，解决 API 轮询的性能瓶颈：
DEMO：https://github.com/mixstart/mixphp/blob/master/apps/websocketd/commands/ServiceCommand.php
3. 大量数据计算场景：
如果从一个数据表中取出大量数据，一个进程计算又太慢了，如果分多个进程分页去查询后，再分开计算，速度是快了，但是如果查询中数据有变化，因为每个进程分别会查一次数据库，就会导致有数据遗漏没有计算到。
这时使用 mixphp 的多进程服务就不会有这个问题，mixphp 的多进程服务在进程内部做了生产者消费者模型，只需使用一个进程去数据表取出数据，然后一行一行发送给消费者进程去计算，这样就高效安全的完成了一次大量计算。
MixPHP
GitHub: https://github.com/mixstart/mixphp
官网：http://www.mixphp.cn/
作者：撸代码的乡下人
链接：https://www.jianshu.com/p/a0556e74939a