從swoole專案開始到現在，一直有人在問這個問題。今天來抽空講一下它。為什麼swoole非要使用純c來寫而不是php**來實現，核心的原因有2點：
如sendfile、eventfd、timerfd、pthread等等，這裡就不一一枚舉了，所以純php實現的 phpdaemon，reactphp，還有最近剛剛出來的workerman。這些框架都是基於php的sockets/pcntl/stream /libevent擴充套件實現，提供的功能很有限，很多功能都無法實現。如
而c語言寫的swoole可以直接呼叫作業系統底層api，沒有侷限，swoole可以實現任何功能特性。
php中想要做記憶體管理太困難了，基本上只有array可用。在高併發大負載的網路server中，記憶體複製簡直就是效能殺手。php中根本無法解決此問題。
舉乙個簡單的例子，客戶端向伺服器發起乙個800k的包，每次傳送8k，共傳送100次。server也會分成100次收到資料。那麼php中 拼接此資料報的方法是 $package .= $recv_data 。共需要複製100次記憶體，第一次為 8k+ 8k，第二次是 16k + 8k，第三次24k + 8k，依次類推，僅僅一次請求就發生了大量的記憶體拷貝。如果每秒有10萬次請求，這個server的效能必然極差。
而純c的**可以做到0次記憶體拷貝，在請求到來申請一塊800k的buffer記憶體，通過指標運算，直接將資料寫入buffer。一氣呵成，記憶體拷貝為0。
當然這裡僅是其中乙個小小的點，真正的**中不止這些。通過壓測也能發現，純c的swoole寫乙個echoserver，做-c 500 -n 100000的測試中，cpu始終在5%-10%之間。而php實現的psf網路server框架，cpu佔用率高達70%-90%。
以上也就是swoole和其他網路框架的差異。除此之外swoole以擴充套件方式提供，免去了**中include php檔案的問題。不需要去包含一堆外部檔案，更容易融合到現有**中。使用者僅需掌握swoole擴充套件的api即可。reactphp提供了api封 裝，耦合程度較低。phpdaemon/workerman耦合太高，不是你的**整合它們，而是它們的**整合你的**。而且還需要了解其內部結構和耦 合關係。
再看swoole，它其實就像mysql之類的擴充套件一樣，僅僅是作為一層api存在，耦合度非常低。swoole一直堅持低耦合高內聚，api化。使用者可以方便的將swoole的功能整合到自己的**中。
php到底能不能做手遊伺服器，我也不想多說，看一下《大掌門》的伺服器架構圖：
第一層是 slb,負載均衡。
第二層是web server,伺服器遊戲邏輯塊。
第三層是cacheserver,常見的有redis,memcached.
第四層是資料庫。
現在你還敢說php不能做伺服器麼？？？
《龍之谷》手遊伺服器資料管理
昨天聽同事聊起龍之谷的服務端架構，有些新穎和值得學習的地方，姑且在此總結，加深下理解，也算是做個筆記。龍之谷的服務端架構主要的特點就是將資料分塊。服務端在設計資料時，按照不同功能將資料分塊，比如 玩家屬性，技能，幫派，排行塊等，每個模組就是乙個記憶體物件 keeper，這樣就能按功能模組來管理資料。...
業餘寫個moba手遊系列之 連上伺服器
希望這次的系列文章，我能堅持寫完啊 先交代個背景。之前在a公司作為校招生培訓時做了個moba手遊，覺得自個當時太年輕，小團隊不敢自個內部孵化，就跑去某半成品專案組了，自己的moba也就沒繼續去做了。現在跳槽到了b公司，b公司規模很大，但是每天也都是業務邏輯為主，而且還是天天敲python。為了不荒廢...
開源手遊伺服器引擎Scut 助力快速開發
scut是乙個開源 免費 穩定 快速開發的遊戲伺服器引擎，支援開發人員使用python指令碼語言或c 語言開發，底層採用c 編寫，基於mvc框架思想設計，開發人員只需要關注如何定義資料實體類及屬性，不再需要關注多據庫 mssql mysql等 及表設計，scut會幫助您自動檢測生成相應資料庫的表結構...