1 Go的應用場景
在斗魚我們將GO的應用場景分為以下三類，緩存類型數據，實時類型數據，CPU密集型任務。這三類應用場景都有著各自的特點。
?●??緩存類型數據在斗魚的案例就是我們的首頁，列表頁，這些頁面和接口的特點是不同用戶在同一段時間得到的數據都是一樣的，通常這些緩存類型數據的包都比較大，并且這些數據沒有用戶態，具有一定價值，很容易被爬蟲爬取。?●??實時類型數據在斗魚的案例就是視頻流，關注數據，這些數據的特點是每次請求獲取的數據都不一樣。并且容易因為某些業務場景導流，例如主播開播提醒，或者某個大型賽事開賽，會在短時間內同時涌入大量用戶，導致服務器流量陡增。
?●??CPU密集型任務在斗魚的案例就是我們的列表排序引擎。斗魚的列表排序數據源較多，算法模型復雜。如何在短時間算完這些數據，提高列表的導流能力對于我們也是一個比較大的挑戰。
針對這三種業務場景如何做優化，我們也是走了不少彎路。而且跟一些程序員一樣，容易陷入到特定的技術和思維當中去。舉個簡單的例子。早期我們在優化GO的排序引擎的時候，上來就想著各種算法優化，引入了跳躍表，歸并排序，看似優化了不少性能，benchmark數據也比較好看。但實際上排序的算法時間和排序數據源獲取的時間數量級差別很大。優化如果找不對方向，業務中的優化只能是事倍功半。所以在往后的工作中，我們基本上是按照如下圖所示的時間區域，找到業務優化的主要耗時區域。
從圖中，我們主要列舉了幾個時間分布，讓大家對這幾個數值有所了解。從客戶端到CDN回源到機房的時間大概是50ms到300ms。機房內部服務端之間通信大概是5ms到50ms。我們訪問的內存數據庫redis返回數據大概是500us到1ms。GO內部獲取內存數據耗時ns級別。了解業務的主要耗時區域，我們就可以知道應該著重優化哪個部分。
2 Go的業務優化
2.1 緩存數據優化
對于用戶訪問一個url，我們假定這個url為/hello。這個url每個用戶返回的數據結構都是一樣的。我們通常有可能會向下面示例這樣做。對于開發而言，代碼是最直觀最可控的。但這種方式通常只是實現功能，但并不能夠提升用戶體驗。因為對于緩存數據我們沒有必要每次讓CDN回源到源站機房，增加用戶訪問的鏈路時間。
e := echo.New() e.Use(mw.Cache) // Routers e.GET("/hello", handler(HomeHandler)) 2.1.1 添加CDN緩存
所以接下來，對于緩存數據，我們不會用go進行緩存，而是在前端cdn進行緩存優化。CDN鏈路如下所示
} } go 代碼如下所示
import ( "fmt" "io" "net/http") func main() { http.Handle("/hello", &ServeMux{}) err := http.ListenAndServe(":9090", nil) if err != nil { fmt.Println("err", err.Error()) } } type ServeMux struct { } func (p *ServeMux) ServeHTTP(w http.ResponseWriter, r *http.Request) { fmt.Println("get one request") fmt.Println(r.RequestURI) io.WriteString(w, "hello world") } 啟動代碼后，我們可以發現。
?●??第一次訪問\hello，nginx和go都會收到請求，nginx的響應頭里cache-status中會有個miss內容，說明了nginx請求穿透到go
?●??第二次再訪問\hello，nginx會收到請求，go這個時候就不會收到請求。nginx里響應頭里cache-status會與個hit內容，說明了nginx請求沒有回源到go
?●??順帶提下nginx這個配置，還有額外的好處，如果后端go服務掛掉，這個緩存url\hello任然是可以返回數據的。nginx返回如下所
2.1.2 CDN去問號緩存
正常用戶在訪問\hellourl的時候，是通過界面引導，然后獲取\hello數據。但是對于爬蟲用戶而言，他們為了獲取更加及時的爬蟲數據，會在url后面加各種隨機數\hello?123456，這種行為會導致cdn緩存失效，讓很多請求回源到源站機房。造成更大的壓力。所以一般這種情況下，我們可以在CDN做去問號緩存。通過nginx可以模擬這種行為。nginx配置如下：
} location ~ /hello { access_log /home/www/logs/hello_access.log; proxy_pass http://127.0.0.1:9090; proxy_cache vipcache; proxy_cache_valid 200 302 20s; proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504 http_403 http_404; add_header Cache-Status "$upstream_cache_status"; } } 2.1.3 大流量上鎖
之前我們有講過如果突然之間有大型賽事開播，會出現大量用戶來訪問。這個時候可能會出現一個場景，緩存數據還沒有建立，大量用戶請求仍然可能回源到源站機房。導致服務負載過高。這個時候我們可以加入proxy_cache_lock和proxy_cache_lock_timeout參數
} location ~ /hello { access_log /home/www/logs/hello_access.log; proxy_pass http://127.0.0.1:9090; proxy_cache vipcache; proxy_cache_valid 200 302 20s; proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504 http_403 http_404; proxy_cache_lock on; procy_cache_lock_timeout 1; add_header Cache-Status "$upstream_cache_status"; } } 2.1.4 數據優化
在上面我們還提到斗魚緩存類型的首頁，列表頁。這些頁面接口數據通常會返回大量數據。在這里我們拿Go模擬了一次請求中獲取120個數據的情況。將slice分為三種情況，未預設slice的長度，預設了slice長度，預設了slice長度并且使用了sync.map。代碼如下所示。這里面每個goroutine相當于一次http請求。我們拿benchmark跑一次數據
roomId int roomName string}func BenchmarkDefaultSlice(b *testing.B) { b.ReportAllocs() var wg sync.WaitGroup for i := 0; i < b.N; i++ { wg.Add(1) go func(wg *sync.WaitGroup) { for i := 0; i < 120; i++ { output := make([]Something, 0) output = append(output, Something{ roomId: i, wg.Done() roomName: strconv.Itoa(i), }) } }func BenchmarkPreAllocSlice(b *testing.B) { }(&wg) } wg.Wait() b.ReportAllocs() var wg sync.WaitGroup for i := 0; i < b.N; i++ { wg.Add(1) go func(wg *sync.WaitGroup) { for i := 0; i < 120; i++ { output := make([]Something, 0, 120) output = append(output, Something{ roomId: i, wg.Done() roomName: strconv.Itoa(i), }) } }func BenchmarkSyncPoolSlice(b *testing.B) { }(&wg) } wg.Wait() b.ReportAllocs() var wg sync.WaitGroup var SomethingPool = sync.Pool{ New: func() interface{} { b := make([]Something, 120) return &b }, } for i := 0; i < b.N; i++ { wg.Add(1) go func(wg *sync.WaitGroup) { obj := SomethingPool.Get().(*[]Something) for i := 0; i < 120; i++ { some := *obj some[i].roomId = i some[i].roomName = strconv.Itoa(i) } SomethingPool.Put(obj) } wg.Done() }(&wg) } wg.Wait() 得到以下結果。可以從最慢的12us降低到1us。
上面我們提到了在業務突然導流的情況下，我們服務有可能在短時間內涌入大量流量，如果不對這些流量進行處理，有可能會將后端數據源擊垮。還有一種情況在突發流量下像視頻流這種請求如果耗時較長，用戶在長時間得不到的數據，有可能進一步刷新頁面重新請求接口，造成二次攻擊。所以我們針對這種實時接口，進行了合理優化。
我們對于量大的實時數據，做了三層緩存。第一層是白名單，這類數據主要是通過人工干預，預設一些內存數據。第二層是通過算法，將我們的一些比較重要的房間信息放入到服務內存里，第三層是通過請求量動態調整。通過這三層緩存設計。像大型賽事，大主播開播的時候，我們的請求是不會穿透到數據源，直接服務器的內存里已經將數據返回。這樣的好處不僅減少了IO操作，而且還對流量起到了鎮流的作用，使流量平穩的到達數據源。
其他量級小的非實時數據，我們都是通過etcd進行推送
2.2.2 對redis參數調優
要充分理解redis的參數。只有這樣我們才能根據業務合理調整redis的參數。達到最佳性能。maxIdle設置高點，可以保證突發流量情況下，能夠有足夠的連接去獲取redis，不用在高流量情況下建立連接。maxActive，readTimeout，writeTimeout的設置，對redis是一種保護，相當于go服務對redis這塊做的一種簡單限流，降頻操作。
maxIdle = 30 maxActive = 500 dialTimeout = "1s" readTimeout = "500ms" writeTimeout = "500ms" idleTimeout = "60s" 2.2.3 服務和redis調優
因為redis是內存數據庫，響應速度比較塊。服務里可能會大量使用redis，很多時候我們服務的壓測，瓶頸不在代碼編寫上，而是在redis的吞吐性能上。因為redis是單線程模型，所以為了提高速度，我們通常做的方式是采用pipeline指令，增加redis從庫，這樣go就可以根據redis數量，并發拉取數據，達到性能最佳。以下我們模擬了這種場景。
t1 := time.Now() for i := 0; i < 120; i++ { getRemoteOneRedisData(i) } fmt.Println("Test_OneRedisData cost: ",time.Since(t1)) }func Test_PipelineRedisData(t *testing.T) { t1 := time.Now() ids := make([]int,0, 120) for i := 0; i < 120; i++ { ids = append(ids, i) } getRemotePipelineRedisData(ids) fmt.Println("Test_PipelineRedisData cost: ",time.Since(t1)) }func Test_GoroutinePipelineRedisData(t *testing.T) { t1 := time.Now() ids := make([]int,0, 120) for i := 0; i < 120; i++ { ids = append(ids, i) } getGoroutinePipelineRedisData(ids) fmt.Println("Test_GoroutinePipelineRedisData cost: ",time.Since(t1)) }func getRemoteOneRedisData(i int) int { // 模擬單個redis請求，定義為600us time.Sleep(600 * time.Microsecond) return i }func getRemotePipelineRedisData(i []int) []int { length := len(i) // 使用pipeline的情況下，單個redis數據，為500us time.Sleep(time.Duration(length)*500*time.Microsecond) return i }func getGoroutinePipelineRedisData(ids []int) []int { idsNew := make(map[int][]int, 0) idsNew[0] = ids[0:30] idsNew[1] = ids[30:60] idsNew[2] = ids[60:90] idsNew[3] = ids[90:120] resp := make([]int,0,120) var wg sync.WaitGroup for j := 0; j < 4; j++ { wg.Add(1) go func(wg *sync.WaitGroup, j int) { resp = append(resp,getRemotePipelineRedisData(idsNew[j])...) wg.Done() }(&wg, j) } wg.Wait() return resp } 
從圖中，我們可以看出采用并發拉去加pipeline方式，性能可以提高5倍。 redis的優化方式還有很多。例如
1.增加redis從庫2.對批量數據，根據redis從庫數量，并發goroutine拉取數據3.對批量數據大量使用pipeline指令4.精簡key字段5.redis的value解碼改為msgpack3 GO的踩坑經驗
踩坑代碼地址： https://github.com/askuy/gopherlearn
3.1 指針類型串號
3.2 多重map上鎖問題
3.3 channel使用問題
4 相關文獻
坑踩得多，說明書看的少。
https://stackoverflow.com/questions/18435498/why-are-receivers-pass-by-value-in-go/18435638
以上問題都可以在相關文獻中找到原因，具體原因請閱讀文檔。
As in all languages in the C family, everything in Go is passed by value. That is, a function always gets a copy of the thing being passed, as if there were an assignment statement assigning the value to the parameter. For instance, passing an int value to a function makes a copy of the int, and passing a pointer value makes a copy of the pointer, but not the data it points to. (See a later section for a discussion of how this affects method receivers.) Map and slice values behave like pointers: they are descriptors that contain pointers to the underlying map or slice data. Copying a map or slice value doesn’t copy the data it points to. Copying 
顏色無法正常顯示問題)
![一個簡單的LINQ TO XML, AJAX 例子[譯]](http://pic.xiahunao.cn/一個簡單的LINQ TO XML, AJAX 例子[譯])
