经常听到群里有朋友问：如何把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进程服务有很多传统框架没有的特性：平滑重启：当主进程被杀死时，子进程在退出之前完成它们的工作而不会丢失数据。容错性高：当子进程异常崩溃时，主进程会重建子进程。高性能：多进程运行，充分利用多CPU并行计算，性能强劲。使用灵活：worker进程采用生产者-消费者模型，生产者/消费者的数量可以自定义。2、高并发、查询频繁的场景（增加缓存还是到瓶颈）：这个场景的瓶颈已经不在数据库了，因为HTTP接口是请求响应的，所以请求频繁，不断的建立和关闭连接消耗过多的服务器性能。这时候就需要使用长连接协议WebSocket进行优化。使用mixphp的WebSocketd包，可以快速搭建一个数据推送系统，解决API轮询的性能瓶颈：DEMO（V1）：https://github.com/mix-php/mi...3.海量数据计算场景：如果从一个数据表中取出大量的数据，一个过程的计算速度太慢。如果多个进程分页查询，然后分别计算，速度是快的，但是如果查询中的数据发生变化，因为每个进程都会分别去查一次数据库，这样会造成一些数据漏掉，没有计算出来，有的要计算多次，导致计算结果不正确。这时候使用mixphp的多进程服务就不会出现这个问题了。mixphp的多进程服务在进程内部有一个生产者消费者模型。只需要用一个进程从数据表中取数据，然后一行一行的发送给消费者进程。去计算，让大量的计算高效、安全的完成。MixPHPGitHub：https://github.com/mixstart/m...官网：http://www.mixphp.cn/
