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