go語言用作廣告dsp開發有什麼優勢和劣勢?

01-26

之前看到在國內的一個go語言應用列表裡面看到QLeelulu用go實現dsp. 貌似達到10萬qps. 就是不知道是在什麼機器環境下達到的. 有沒有什麼問題?

QLeelulu是我們部門老大，我不久前加入這家公司，現在正好負責RTB這塊。所以簡單說一下。

首先更正LZ，目前我們的峰值已達到15萬以上qps而不是10萬。

1.我們使用Go語言的優勢和劣勢

先說優勢吧。談一門語言不能脫離業務場景，雖然現在我們系統大部分是純Go實現的了，但最能體現和發揮Go語言優勢的無疑是實時競價這塊。它對響應時間要很短，而並發請求量又非常高。15萬的qps，每個請求要在30ms以進行響應。實時競價是一個CPU密積型的服務，使用Go語言可以充分地發揮出多核的優勢。Go語言對並發和網路編程非常友好，用它來實現系統可以減少很多心智負擔。

每來一個請求開一個goroutine處理，goroutine很輕量，不會造成多少額外開銷。而如果換成C語言每來一個請求開一個thread，那幾乎是不敢想像的。當然用C/C++一類語言，自己做線程池，做調度，網路這塊自己封裝好epoll，然後經過很細緻的性能調優，也可以做出一個吞吐量很高的系統來。但是，不是每個人都有做這種系統的實力，就我對QLeelulu的了解，也許勉強能搞定，夠嗆的。自己專門寫一套底層框架不一定能寫出來，而且給新來維護的同事也會帶來巨大的學習成本。

當然，聰明的人會有聰明的做事方式。其它語言中有些庫可以做這些事，也是增加了學習成本。但是Go語言在語言層面提供了這些東西，而它提供的運行時已經把多線程模型，網路處理這些都弄好了，可以避免使用者重造輪子，劣質的輪子。

使用了Go語言之後，不需要明星員工，就能夠做出強大的系統，低延時，高吞吐。

總結幾點就是:

程序員心智負擔低，開發效率高

充分發揮多核機器的性能

劣勢當然也是有的。比如說不好招人/不好找工作。我從Go1.0版本就開始關注這門語言的底層實現，一路見證了像垃圾回收的簡單Stop the world，到1.1的並行垃圾回收，到1.3的精確垃圾回收；見證了goroutine棧從4k到8k，從分段式棧到連續棧等等變遷。但是當我想找一份使用Go語言的工作時，卻發現選擇面非常小。有一次面試聊到後面對方表示，招一個懂資料庫，精通分散式存儲的人，讓他去學Go語言很容易(所以我不是很適合)，但是最諷刺的是他們招聘職位寫的是Go語言工程師。扯遠了，還是聊技術。

對於用Go語言實現競價服務，外界最容易擔憂的是垃圾回收問題，因為現階段的Go垃圾回收還是會stop the world的，而對於像實時競價這種響應時間要求很嚴格的服務，stop the world是不允許的。其實這是誤解，垃圾回收現在並不是很困擾我們的很大問題，其實我們的垃圾回收只在5ms左右，問題不大。

因為RTB一個CPU密積型的，內存使用並不大(至於很大內存的cookie map和人群屬性數據，它們都是單獨使用外部的資料庫的)。每個進程大概佔120-200M的內存，其中有60M是一個IP地址資料庫，以及載入活動數據大概有30M，進程本身的內存使用很少，只要控制好代碼寫的不是太爛，中間生成的臨時變數不要太多，幾十M的數據對於多核並行的垃圾回收，即使stop the world，毫無壓力。還要提及的一點是，因為業務原因，我們每個物理機器上拆了很多競價服務進程，這樣均攤到每個進程上的內存的垃圾回收就更無壓力了。我們是web服務，像@達達他們的遊戲是不能這麼拆的。

那麼主要問題是什麼呢？CPU使用率高，響應時間波動有點大。這不是Go語言帶來的劣勢，換任何一門其它的語言，都避不開。CPU使用率高這正好是Go發揮出多核的性能，副作用是有的，想了解一下DSP這邊的一些技術挑戰，可以去看一下我的博客：

http://www.zenlife.tk/dsp-challenge.md

2.機器環境

其實我們也是家正在高速發展中的公司，很多東西還很原始，這裡可以發展的空間很大。不怕告訴LZ我們現階段是怎麼做的----加機器硬扛！！！

這是過去一段時間的數據了，雖然現在好了很多。在我來公司之前，單個競價服務的Go進程，處理能力大概在1500qps的時候CPU使用至少也在500%以上了，每個機器上開4個進程，因為峰值的時候可能一個進程要跑滿7個核！單台機器按大概6000-8000qps算的話，那麼就可以知道10萬qps需要多少機器。然後硬體的話，是16核或24核的。

dsp的qps是極大受到商業模式影響的，dsp之間業務邏輯可以千差萬別，特定類型的dps業務可以非常非常簡單，並不一定是大而全的，所以脫離業務複雜度去談qps其實意義不大