golang高並發架構,go 高並發編程

本文目錄一覽：

• 1、為什麼我全力推薦Golang
• 2、golang有哪些不錯的遊戲服務器框架
• 3、golang csp 模型
• 4、golang怎麼使用redis，最基礎的有效的方法
• 5、【golang】高並發下TCP常見問題解決方案

為什麼我全力推薦Golang

討論哪個語言更好，就像在爭論姚明和劉翔誰是更優秀的運動員。因為各自的坐標象限不同，常常會陷入一個難有結論怪圈。

所以本文絕不是在說Golang是比其他語言更好的語言。Golang只是最值得推薦的語言，尤其適合快速成長中的後端研發團隊。

我推薦Golang的主要理由，並不是技術性的要素：不是他的高並發能力，編譯的速度，跨平台能力，內存效率，也不是社區的活躍度等等。

事實上，創業之後，或者說成為一個技術管理者之後，技術優點就已經不再是我推薦任何一種語言的關鍵因素了。

因為，對於一個研發團隊來說，項目成敗的關鍵因素是：成本、質量和時間！

1、人力資源的成本

人力資源是研發團隊最重要的資源，也是唯一的資源。其成本不僅僅是團隊要支付的薪資代價。也包括獲得資源的難易程度，例如招聘和培訓的速度。以及維持資源，也就是保持員工滿意度或者說士氣的代價，也就是管理成本。（上述成本不僅指錢，時間也是非常昂貴的成本）

Golang有一系列特點，使它既容易上手，又易於維護。Golang可以讓初階和中階工程師，經過少許培訓，就寫出相當不錯的代碼。直接點說，一票1-2年經驗少許靈性的年輕工程師轉Golang，只要少許指導，很快就可以寫出高並發高負載能力生產級別的代碼，而且質量相當有保證。而同樣的工程，如果用C++或java等語言，則需要至少3-5年經驗的工程師來完成，同時質量還是要讓人擔心。

那麼，對於團隊特別是成長型的或創業團隊來說，現在有Golang這樣一種語言，可以讓大量初階和中級工程師承擔主要開發工作，還能保證相當優秀的結果，從資金成本和時間成本控制的角度，簡直就是美夢成真。

2、項目研發的效率

說到高並發高負載，讓我不能不想起nginx。nginx在2004年從web server領域橫空出世，所向披靡。精巧嚴謹易於維護和擴展的代碼結構，也是教科書級別的。

但是要知道，一個用C寫出一個nginx，是需要世界上最優秀的工程師的。這樣的工程師，不僅團隊裡面沒有，連遇到一個都很難。

可現在，我再告訴你，一個使用Golang的中級工程師，就已經可以寫出性能與nginx相近的高並發高負載應用。而且不僅性能相近，而且需要的代碼行數和開發時間也短很多。這對於團隊成員來說，這很可能是決定生死存亡還是走上人生巔峰的區別。

—

總之：

對於團隊管理者來說，Golang可以讓團隊用更低的人力成本，更快的速度，更高的質量，完成項目研發。

對於工程師來說，Golang可以讓人有更多的時間去思考和生活。

所以，我推薦Golang。

golang有哪些不錯的遊戲服務器框架

為什麼golang的開發效率高？

golang是一編譯型的強類型語言，它在開發上的高效率主要來自於後發優勢，不用考慮舊有噁心的歷史，又有一個較高的工程視角。良好的避免了程序員因為“ { 需不需要獨佔一行 ”這種革命問題打架，也解決了一部分趁編譯時間找產品妹妹搭訕的階級敵人。

它有自己的包管理機制，工具鏈成熟，從開發、調試到發布都很簡單方便；

有反向接口、defer、coroutine等大量的syntactic sugar；

編譯速度快，因為是強類型語言又有gc，只要通過編譯，非業務毛病就很少了；

它在語法級別上支持了goroutine，這是大家說到最多的內容，這裡重點提一下。首先，coroutine並不稀罕，語言並不能超越硬件、操作系統實現神乎其神的功能。golang可以做到事情，其他語言也可以做到，譬如c++，在boost庫裡面自己就有的coroutine實現（當然用起來跟其他boost庫一樣噁心）。golang做的事情，是把這一套東西的使用過程簡化了，並且提供了一套channel的通信模式，使得程序員可以忽略諸如死鎖等問題。

goroutine的目的是描述並發編程模型。並發與並行不同，它並不需要多核的硬件支持，它不是一種物理運行狀態，而是一種程序邏輯流程。它的主要目的不是利用多核提高運行效率，而是提供一種更容易理解、不容易出錯的語言來描述問題。

實際上golang默認就是運行在單OS進程上面的，通過指定環境變量GOMAXPROCS才能轉身跑在多OS進程上面。有人提到了的pomelo，開源本來是一件很不錯的事情，但是基於自己對callback hell的偏見，我一直持有這種態度：敢用nodejs寫大規模遊戲服務器的人，都是真正的勇士 : ) 。

2、Erlang與Golang的coroutine有啥區別，coroutine是啥？

coroutine本質上是語言開發者自己實現的、處於user space內的線程，無論是erlang、還是golang都是這樣。需要解決沒有時鐘中斷；碰着阻塞式i\o，整個進程都會被操作系統主動掛起；需要自己擁有調度控制能力（放在並行環境下面還是挺麻煩的一件事）等等問題。那為啥要廢老大的勁自己做一套線程放user space裡面呢？

並發是服務器語言必須要解決的問題；

system space的進程還有線程調度都太慢了、佔用的空間也太大了。

把線程放到user space的可以避免了陷入system call進行上下文切換以及高速緩衝更新，線程本身以及切換等操作可以做得非常的輕量。這也就是golang這類語言反覆提及的超高並發能力，分分鐘給你開上幾千個線程不費力。

不同的是，golang的並發調度在i/o等易發阻塞的時候才會發生，一般是內封在庫函數內；erlang則更誇張，對每個coroutine維持一個計數器，常用語句都會導致這個計數器進行reduction，一旦到點，立即切換調度函數。

中斷介入程度的不同，導致erlang看上去擁有了preemptive scheduling的能力，而golang則是cooperative shceduling的。golang一旦寫出純計算死循環，進程內所有會話必死無疑；要有大計算量少i\o的函數還得自己主動叫runtime.Sched()來進行調度切換。

3、golang的運行效率怎麼樣？

我是相當反感所謂的ping\pong式benchmark，運行效率需要放到具體的工作環境下面考慮。

首先，它再快也是快不過c的，畢竟底下做了那麼多工作，又有調度，又有gc什麼的。那為什麼在那些benchmark裡面，golang、nodejs、erlang的響應效率看上去那麼優秀呢，響應快，並發強？並發能力強的原因上面已經提到了，響應快是因為大量非阻塞式i\o操作出現的原因。這一點c也可以做到，並且能力更強，但是得多寫不少優質代碼。

然後，針對遊戲服務器這種高實時性的運行環境，GC所造成的跳幀問題確實比較麻煩，前面的大神 @達達 有比較詳細的論述和緩解方案，就不累述了 。隨着golang的持續開發，相信應該會有非常大的改進。一是屏蔽內存操作是現代語言的大勢所趨，它肯定是需要被實現的；二是GC算法已經相當的成熟，效率勉勉強強過得去；三是可以通過incremental的操作來均攤cpu消耗。

用這一點點效率損失換取一個更高的生產能力是不是值得呢？我覺得是值得的，硬件已經很便宜了，人生苦短，讓自己的生活更輕鬆一點吧: )。

4、基於以上的論述，我認為採用go進行小範圍的MMORPG開發是可行的。

golang csp 模型

調度器 由三方面實體構成：

三者對應關係：

上圖有2個 物理線程 M，每一個 M 都擁有一個上下文（P），每一個也都有一個正在運行的goroutine（G）。

P 的數量可由 runtime.GOMAXPROCS() 進行設置，它代表了真正的並發能力，即可有多少個 goroutine 同時運行。

調度器為什麼要維護多個上下文P 呢？ 因為當一個物理線程 M 被阻塞時，P 可以轉而投奔另一個OS線程 M （即 P 帶着 G 連莖拔起，去另一個 M 節點下運行）。這是 Golang調度器厲害的地方，也是高並發能力的保障。

golang怎麼使用redis，最基礎的有效的方法

應用Redis實現數據的讀寫，同時利用隊列處理器定時將數據寫入mysql。同時要注意避免衝突，在redis啟動時去mysql讀取所有表鍵值存入redis中，往redis寫數據時，對redis主鍵自增並進行讀取，若mysql更新失敗，則需要及時清除緩存及同步redis主鍵。這樣處理，主要是實時讀寫redis，而mysql數據則通過隊列異步處理，緩解mysql壓力，不過這種方法應用場景主要基於高並發，而且redis的高可用集群架構相對更複雜，一般不是很推薦。

【golang】高並發下TCP常見問題解決方案

首先，看一下TCP握手簡單描繪過程：

其握手過程原理，就不必說了，有很多詳細文章進行敘述，本文只關注研究重點。

在第三次握手過程中，如果服務器收到ACK，就會與客戶端建立連接，此時內核會把連接從半連接隊列移除，然後創建新的連接，並將其添加到全連接隊列，等待進程調用。

如果服務器繁忙，來不及調用連接導致全連接隊列溢出，服務器就會放棄當前握手連接，發送RST給客戶端，即connection reset by peer。

在linux平台上，客戶端在進行高並發TCP連接處理時，最高並發數量都要受系統對用戶單一進程同時打開文件數量的限制（這是因為系統每個TCP都是SOCKET句柄，每個soker句柄都是一個文件），當打開連接超過限制，就會出現too many open files。

使用下指令查看最大句柄數量：

增加句柄解決方案