本文目錄一覽:
- 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。
使用下指令查看最大句柄數量:
增加句柄解決方案
原創文章,作者:小藍,如若轉載,請註明出處:https://www.506064.com/zh-tw/n/242164.html