如果有仔細看過 swoole task 的文件的話，應該都會注意到這句話
task 操作的次數必須小於ontask處理速度，如果投遞容量超過處理能力，task會塞滿快取區，導致worker程序發生阻塞。worker程序將無法接收新的請求task 如果阻塞會引發 woker 程序阻塞，造成服務無法工作，引發問題。
我曾經使用 task 傳送服務的鏈路日誌，接收日誌的服務出現bug，造成傳送日誌的 task 阻塞，然後服務 gg 的情況，之後我就對 task 做了一波優化。
思路就是使用 swoole channel （和 swoole user process （實現一套 task 。
使用 channel 接收資料，然後在 user process 消費資料，假如 channel 滿了僅僅會造成 push 資料失敗，並不會引發阻塞，因為是鏈路日誌，是允許丟失的，所以這個方案完全沒問題。
在swoole user process 消費 channel 的策略的偽**如下
$sleeptime = 5;
$maxsleeptime = 100;
while (true)
usleep($sleeptime * 1000);
continue;
}$sleeptime = 0;
// 處理資料
}
如果消費不到資料，就 sleep 5ms，sleep的時間依次累加，直到達到最大值 100ms，達到 cpu 使用率和處理資料實時性的乙個平衡，具體平衡點可以根據自己的業務按需調整。
另外，還有使用channel還有乙個小坑，往 channel 傳送資料使用的 swoole 程序通訊機制（不僅僅是channel，swoole 使用程序通訊地方基本都有這問題，task 也是），swoole 的程序通訊有個點需要注意一下，那就是超過8k的資料會在磁碟產生臨時檔案，而且這個臨時檔案 swoole 自己並不會清理，因為這個問題，測試環境的磁碟被這些臨時檔案打爆過。
怎麼處理這個問題呢？我的思路就是使用gzip壓縮一下資料，這樣可以解決在我的應用場景中超過8k的資料，但是如果在其他場景下，即使處理過資料依然超過8k怎麼辦呢？寫個指令碼，定時刪吧，好像也沒很好的方法。
專案踩坑及成長
4月1號那天，我領導給我安排了乙個任務，讓我負責乙個小系統，帶北京的兩個同事，還有上海這邊的乙個前端。講實話，我又興奮又覺得有壓力。在這三個星期當中，我覺得我從這個專案裡成長的不僅僅是技術 還有對整個專案的把控 專案的進度計畫 部署都得到完整的體驗性成長，當然有成長，就會有很多麻煩的事情，不過我覺得...
jupyter notebook踩坑及解決方案
1.jupyter notebook無法自動開啟瀏覽器 首先在cmd開啟anoconda prompt，輸入命令 jupyter notebook generate config，系統會自動產生乙個名為jupyter notebook config.py的檔案，並且anoconda prompt視窗...
ngnix 配置及踩坑
1安裝完ngnix後 在sbin資料夾對ngnix操作 1 ngnix 啟動 2 ngnix s stop 3 ngnix s reload 4 losf i 80 檢視相關的ngnix程序 5 kill 9 pid 2坑 配置完不起作用一直停留在welcome to nginx介面 前提是對應的埠...