golang sync.pool對象復用 并發(fā)原理 緩存池

在go http每一次go serve(l)都會構(gòu)建Request數(shù)據(jù)結(jié)構(gòu)。在大量數(shù)據(jù)請求或高并發(fā)的場景中，頻繁創(chuàng)建銷毀對象，會導致GC壓力。解決辦法之一就是使用對象復用技術(shù)。在http協(xié)議層之下，使用對象復用技術(shù)創(chuàng)建Request數(shù)據(jù)結(jié)構(gòu)。在http協(xié)議層之上，可以使用對象復用技術(shù)創(chuàng)建(w,*r,ctx)數(shù)據(jù)結(jié)構(gòu)。這樣即可以回快TCP層讀包之后的解析速度，也可也加快請求處理的速度。

創(chuàng)新互聯(lián)主營承留網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,成都App制作,承留h5微信小程序搭建,承留網(wǎng)站營銷推廣歡迎承留等地區(qū)企業(yè)咨詢

先上一個測試：

結(jié)論是這樣的：

貌似使用池化，性能弱爆了？？？這似乎與net/http使用sync.pool池化Request來優(yōu)化性能的選擇相違背。這同時也說明了一個問題，好的東西，如果濫用反而造成了性能成倍的下降。在看過pool原理之后，結(jié)合實例，將給出正確的使用方法，并給出預期的效果。

sync.Pool是一個 協(xié)程安全 的 臨時對象池 。數(shù)據(jù)結(jié)構(gòu)如下：

local 成員的真實類型是一個 poolLocal 數(shù)組，localSize 是數(shù)組長度。這涉及到Pool實現(xiàn)，pool為每個P分配了一個對象，P數(shù)量設(shè)置為runtime.GOMAXPROCS(0)。在并發(fā)讀寫時，goroutine綁定的P有對象，先用自己的，沒有去偷其它P的。go語言將數(shù)據(jù)分散在了各個真正運行的P中，降低了鎖競爭，提高了并發(fā)能力。

不要習慣性地誤認為New是一個關(guān)鍵字，這里的New是Pool的一個字段，也是一個閉包名稱。其API：

如果不指定New字段，對象池為空時會返回nil，而不是一個新構(gòu)建的對象。Get()到的對象是隨機的。

原生sync.Pool的問題是，Pool中的對象會被GC清理掉，這使得sync.Pool只適合做簡單地對象池，不適合作連接池。

pool創(chuàng)建時不能指定大小，沒有數(shù)量限制。pool中對象會被GC清掉，只存在于兩次GC之間。實現(xiàn)是pool的init方法注冊了一個poolCleanup()函數(shù)，這個方法在GC之前執(zhí)行，清空pool中的所有緩存對象。

為使多協(xié)程使用同一個POOL。最基本的想法就是每個協(xié)程，加鎖去操作共享的POOL，這顯然是低效的。而進一步改進，類似于ConcurrentHashMap（JDK7）的分Segment，提高其并發(fā)性可以一定程度性緩解。

注意到pool中的對象是無差異性的，加鎖或者分段加鎖都不是較好的做法。go的做法是為每一個綁定協(xié)程的P都分配一個子池。每個子池又分為私有池和共享列表。共享列表是分別存放在各個P之上的共享區(qū)域，而不是各個P共享的一塊內(nèi)存。協(xié)程拿自己P里的子池對象不需要加鎖，拿共享列表中的就需要加鎖了。

Get對象過程：

Put過程：

如何解決Get最壞情況遍歷所有P才獲取得對象呢：

方法1止前sync.pool并沒有這樣的設(shè)置。方法2由于goroutine被分配到哪個P由調(diào)度器調(diào)度不可控，無法確保其平衡。

由于不可控的GC導致生命周期過短，且池大小不可控，因而不適合作連接池。僅適用于增加對象重用機率，減少GC負擔。2

執(zhí)行結(jié)果:

單線程情況下，遍歷其它無元素的P，長時間加鎖性能低下。啟用協(xié)程改善。

結(jié)果：

測試場景在goroutines遠大于GOMAXPROCS情況下，與非池化性能差異巨大。

測試結(jié)果

可以看到同樣使用*sync.pool，較大池大小的命中率較高，性能遠高于空池。

結(jié)論：pool在一定的使用條件下提高并發(fā)性能，條件1是協(xié)程數(shù)遠大于GOMAXPROCS，條件2是池中對象遠大于GOMAXPROCS。歸結(jié)成一個原因就是使對象在各個P中均勻分布。

池pool和緩存cache的區(qū)別。池的意思是，池內(nèi)對象是可以互換的，不關(guān)心具體值，甚至不需要區(qū)分是新建的還是從池中拿出的。緩存指的是KV映射，緩存里的值互不相同，清除機制更為復雜。緩存清除算法如LRU、LIRS緩存算法。

池空間回收的幾種方式。一些是GC前回收，一些是基于時鐘或弱引用回收。最終確定在GC時回收Pool內(nèi)對象，即不回避GC。用java的GC解釋弱引用。GC的四種引用：強引用、弱引用、軟引用、虛引用。虛引用即沒有引用，弱引用GC但有空間則保留，軟引用GC即清除。ThreadLocal的值為弱引用的例子。

regexp 包為了保證并發(fā)時使用同一個正則，而維護了一組狀態(tài)機。

fmt包做字串拼接，從sync.pool拿[]byte對象。避免頻繁構(gòu)建再GC效率高很多。

JedisPool和ShardedJedisPool有什么區(qū)別

區(qū)別是： ShardedJedis是基于一致性哈希算法實現(xiàn)的分布式Redis集群客戶端；ShardedJedis的設(shè)計分為以下幾塊： 對象池設(shè)計：Pool，ShardedJedisPool，ShardedJedisFactory 面向用戶的操作封裝：BinaryShardedJedis，BinaryShardedJedis 一致性哈。

設(shè)計模式 對象池和對象倉庫有什么區(qū)別

每一種語言的程序設(shè)計思想大同小異,只是一些由語言特性的而帶來的細微差別,比如.結(jié)構(gòu)模式(Layering分層,Pipe/Filter管道或過濾器),設(shè)計模式(有很多,比如對象池。

如何實現(xiàn)支持數(shù)億用戶的長連消息系統(tǒng)

此文是根據(jù)周洋在【高可用架構(gòu)群】中的分享內(nèi)容整理而成，轉(zhuǎn)發(fā)請注明出處。

周洋，360手機助手技術(shù)經(jīng)理及架構(gòu)師，負責360長連接消息系統(tǒng)，360手機助手架構(gòu)的開發(fā)與維護。

不知道咱們?nèi)好裁磿r候改為“Python高可用架構(gòu)群”了，所以不得不說，很榮幸能在接下來的一個小時里在Python群里討論golang....

360消息系統(tǒng)介紹

360消息系統(tǒng)更確切的說是長連接push系統(tǒng)，目前服務于360內(nèi)部多個產(chǎn)品，開發(fā)平臺數(shù)千款app，也支持部分聊天業(yè)務場景，單通道多app復用，支持上行數(shù)據(jù)，提供接入方不同粒度的上行數(shù)據(jù)和用戶狀態(tài)回調(diào)服務。

目前整個系統(tǒng)按不同業(yè)務分成9個功能完整的集群，部署在多個idc上（每個集群覆蓋不同的idc），實時在線數(shù)億量級。通常情況下，pc，手機，甚至是智能硬件上的360產(chǎn)品的push消息，基本上是從我們系統(tǒng)發(fā)出的。

關(guān)于push系統(tǒng)對比與性能指標的討論

很多同行比較關(guān)心go語言在實現(xiàn)push系統(tǒng)上的性能問題，單機性能究竟如何，能否和其他語言實現(xiàn)的類似系統(tǒng)做對比么？甚至問如果是創(chuàng)業(yè),第三方云推送平臺，推薦哪個?

其實各大廠都有類似的push系統(tǒng)，市場上也有類似功能的云服務。包括我們公司早期也有erlang，nodejs實現(xiàn)的類似系統(tǒng)，也一度被公司要求做類似的對比測試。我感覺在討論對比數(shù)據(jù)的時候，很難保證大家環(huán)境和需求的統(tǒng)一，我只能說下我這里的體會，數(shù)據(jù)是有的，但這個數(shù)據(jù)前面估計會有很多定語~

第一個重要指標：單機的連接數(shù)指標

做過長連接的同行，應該有體會，如果在穩(wěn)定連接情況下，連接數(shù)這個指標，在沒有網(wǎng)絡(luò)吞吐情況下對比，其實意義往往不大，維持連接消耗cpu資源很小，每條連接tcp協(xié)議棧會占約4k的內(nèi)存開銷，系統(tǒng)參數(shù)調(diào)整后，我們單機測試數(shù)據(jù)，最高也是可以達到單實例300w長連接。但做更高的測試，我個人感覺意義不大。

因為實際網(wǎng)絡(luò)環(huán)境下，單實例300w長連接，從理論上算壓力就很大：實際弱網(wǎng)絡(luò)環(huán)境下，移動客戶端的斷線率很高，假設(shè)每秒有1000分之一的用戶斷線重連。300w長連接，每秒新建連接達到3w，這同時連入的3w用戶，要進行注冊，加載離線存儲等對內(nèi)rpc調(diào)用，另外300w長連接的用戶心跳需要維持,假設(shè)心跳300s一次，心跳包每秒需要1w tps。單播和多播數(shù)據(jù)的轉(zhuǎn)發(fā)，廣播數(shù)據(jù)的轉(zhuǎn)發(fā)，本身也要響應內(nèi)部的rpc調(diào)用，300w長連接情況下，gc帶來的壓力，內(nèi)部接口的響應延遲能否穩(wěn)定保障。這些集中在一個實例中，可用性是一個挑戰(zhàn)。所以線上單實例不會hold很高的長連接,實際情況也要根據(jù)接入客戶端網(wǎng)絡(luò)狀況來決定。

第二個重要指標:消息系統(tǒng)的內(nèi)存使用量指標

這一點上，使用go語言情況下，由于協(xié)程的原因，會有一部分額外開銷。但是要做兩個推送系統(tǒng)的對比，也有些需要確定問題。比如系統(tǒng)從設(shè)計上是否需要全雙工（即讀寫是否需要同時進行）如果半雙工，理論上對一個用戶的連接只需要使用一個協(xié)程即可（這種情況下，對用戶的斷線檢測可能會有延時），如果是全雙工，那讀/寫各一個協(xié)程。兩種場景內(nèi)存開銷是有區(qū)別的。

另外測試數(shù)據(jù)的大小往往決定我們對連接上設(shè)置的讀寫buffer是多大，是全局復用的，還是每個連接上獨享的，還是動態(tài)申請的。另外是否全雙工也決定buffer怎么開。不同的策略，可能在不同情況的測試中表現(xiàn)不一樣。

第三個重要指標：每秒消息下發(fā)量

這一點上，也要看我們對消息到達的QoS級別(回復ack策略區(qū)別），另外看架構(gòu)策略，每種策略有其更適用的場景，是純粹推？還是推拉結(jié)合？甚至是否開啟了消息日志？日志庫的實現(xiàn)機制、以及緩沖開多大？flush策略……這些都影響整個系統(tǒng)的吞吐量。

另外為了HA，增加了內(nèi)部通信成本，為了避免一些小概率事件，提供閃斷補償策略，這些都要考慮進去。如果所有的都去掉，那就是比較基礎(chǔ)庫的性能了。

所以我只能給出大概數(shù)據(jù)，24核，64G的服務器上，在QoS為message at least，純粹推，消息體256B~1kB情況下，單個實例100w實際用戶（200w+）協(xié)程，峰值可以達到2~5w的QPS...內(nèi)存可以穩(wěn)定在25G左右，gc時間在200~800ms左右（還有優(yōu)化空間）。

我們正常線上單實例用戶控制在80w以內(nèi)，單機最多兩個實例。事實上，整個系統(tǒng)在推送的需求上，對高峰的輸出不是提速，往往是進行限速，以防push系統(tǒng)瞬時的高吞吐量，轉(zhuǎn)化成對接入方業(yè)務服務器的ddos攻擊所以對于性能上，我感覺大家可以放心使用，至少在我們這個量級上，經(jīng)受過考驗，go1.5到來后，確實有之前投資又增值了的感覺。

消息系統(tǒng)架構(gòu)介紹

下面是對消息系統(tǒng)的大概介紹，之前一些同學可能在gopher china上可以看到分享，這里簡單講解下架構(gòu)和各個組件功能，額外補充一些當時遺漏的信息：

架構(gòu)圖如下，所有的service都 written by golang.

幾個大概重要組件介紹如下：

dispatcher service根據(jù)客戶端請求信息，將應網(wǎng)絡(luò)和區(qū)域的長連接服務器的，一組IP傳送給客戶端。客戶端根據(jù)返回的IP，建立長連接，連接Room service.

room Service，長連接網(wǎng)關(guān)，hold用戶連接，并將用戶注冊進register service，本身也做一些接入安全策略、白名單、IP限制等。

register service是我們?nèi)謘ession存儲組件，存儲和索引用戶的相關(guān)信息，以供獲取和查詢。

coordinator service用來轉(zhuǎn)發(fā)用戶的上行數(shù)據(jù)，包括接入方訂閱的用戶狀態(tài)信息的回調(diào)，另外做需要協(xié)調(diào)各個組件的異步操作，比如kick用戶操作,需要從register拿出其他用戶做異步操作.

saver service是存儲訪問層，承擔了對redis和mysql的操作，另外也提供部分業(yè)務邏輯相關(guān)的內(nèi)存緩存，比如廣播信息的加載可以在saver中進行緩存。另外一些策略，比如客戶端sdk由于被惡意或者意外修改，每次加載了消息，不回復ack，那服務端就不會刪除消息，消息就會被反復加載，形成死循環(huán)，可以通過在saver中做策略和判斷。（客戶端總是不可信的）。

center service提供給接入方的內(nèi)部api服務器，比如單播或者廣播接口，狀態(tài)查詢接口等一系列api,包括運維和管理的api。

舉兩個常見例子，了解工作機制：比如發(fā)一條單播給一個用戶，center先請求Register獲取這個用戶之前注冊的連接通道標識、room實例地址，通過room service下發(fā)給長連接 Center Service比較重的工作如全網(wǎng)廣播，需要把所有的任務分解成一系列的子任務，分發(fā)給所有center，然后在所有的子任務里，分別獲取在線和離線的所有用戶，再批量推到Room Service。通常整個集群在那一瞬間壓力很大。

deployd/agent service用于部署管理各個進程，收集各組件的狀態(tài)和信息,zookeeper和keeper用于整個系統(tǒng)的配置文件管理和簡單調(diào)度

關(guān)于推送的服務端架構(gòu)

常見的推送模型有長輪訓拉取，服務端直接推送（360消息系統(tǒng)目前主要是這種），推拉結(jié)合（推送只發(fā)通知，推送后根據(jù)通知去拉取消息）.

拉取的方式不說了，現(xiàn)在并不常用了，早期很多是nginx+lua+redis，長輪訓，主要問題是開銷比較大，時效性也不好，能做的優(yōu)化策略不多。

直接推送的系統(tǒng)，目前就是360消息系統(tǒng)這種，消息類型是消耗型的，并且對于同一個用戶并不允許重復消耗,如果需要多終端重復消耗，需要抽象成不同用戶。

推的好處是實時性好，開銷小，直接將消息下發(fā)給客戶端，不需要客戶端走從接入層到存儲層主動拉取.

但純推送模型，有個很大問題，由于系統(tǒng)是異步的，他的時序性無法精確保證。這對于push需求來說是夠用的，但如果復用推送系統(tǒng)做im類型通信，可能并不合適。

對于嚴格要求時序性，消息可以重復消耗的系統(tǒng)，目前也都是走推拉結(jié)合的模型，就是只使用我們的推送系統(tǒng)發(fā)通知，并附帶id等給客戶端做拉取的判斷策略，客戶端根據(jù)推送的key，主動從業(yè)務服務器拉取消息。并且當主從同步延遲的時候，跟進推送的key做延遲拉取策略。同時也可以通過消息本身的QoS，做純粹的推送策略，比如一些“正在打字的”低優(yōu)先級消息，不需要主動拉取了，通過推送直接消耗掉。

哪些因素決定推送系統(tǒng)的效果？

首先是sdk的完善程度，sdk策略和細節(jié)完善度，往往決定了弱網(wǎng)絡(luò)環(huán)境下最終推送質(zhì)量.

SDK選路策略,最基本的一些策略如下：有些開源服務可能會針對用戶hash一個該接入?yún)^(qū)域的固定ip，實際上在國內(nèi)環(huán)境下不可行，最好分配器（dispatcher）是返回散列的一組，而且端口也要參開，必要時候，客戶端告知是retry多組都連不上，返回不同idc的服務器。因為我們會經(jīng)常檢測到一些case，同一地區(qū)的不同用戶，可能對同一idc內(nèi)的不同ip連通性都不一樣，也出現(xiàn)過同一ip不同端口連通性不同，所以用戶的選路策略一定要靈活，策略要足夠完善.另外在選路過程中，客戶端要對不同網(wǎng)絡(luò)情況下的長連接ip做緩存，當網(wǎng)絡(luò)環(huán)境切換時候（wifi、2G、3G)，重新請求分配器，緩存不同網(wǎng)絡(luò)環(huán)境的長連接ip。

客戶端對于數(shù)據(jù)心跳和讀寫超時設(shè)置,完善斷線檢測重連機制

針對不同網(wǎng)絡(luò)環(huán)境，或者客戶端本身消息的活躍程度，心跳要自適應的進行調(diào)整并與服務端協(xié)商，來保證鏈路的連通性。并且在弱網(wǎng)絡(luò)環(huán)境下，除了網(wǎng)絡(luò)切換（wifi切3G）或者讀寫出錯情況，什么時候重新建立鏈路也是一個問題。客戶端發(fā)出的ping包，不同網(wǎng)絡(luò)下，多久沒有得到響應，認為網(wǎng)絡(luò)出現(xiàn)問題，重新建立鏈路需要有個權(quán)衡。另外對于不同網(wǎng)絡(luò)環(huán)境下，讀取不同的消息長度，也要有不同的容忍時間，不能一刀切。好的心跳和讀寫超時設(shè)置，可以讓客戶端最快的檢測到網(wǎng)絡(luò)問題，重新建立鏈路，同時在網(wǎng)絡(luò)抖動情況下也能完成大數(shù)據(jù)傳輸。

結(jié)合服務端做策略

另外系統(tǒng)可能結(jié)合服務端做一些特殊的策略，比如我們在選路時候，我們會將同一個用戶盡量映射到同一個room service實例上。斷線時，客戶端盡量對上次連接成功的地址進行重試。主要是方便服務端做閃斷情況下策略，會暫存用戶閃斷時實例上的信息，重新連入的 時候，做單實例內(nèi)的遷移，減少延時與加載開銷.

客戶端保活策略

很多創(chuàng)業(yè)公司愿意重新搭建一套push系統(tǒng)，確實不難實現(xiàn)，其實在協(xié)議完備情況下（最簡單就是客戶端不回ack不清數(shù)據(jù)），服務端會保證消息是不丟的。但問題是為什么在消息有效期內(nèi),到達率上不去？往往因為自己app的push service存活能力不高。選用云平臺或者大廠的，往往sdk會做一些保活策略，比如和其他app共生，互相喚醒，這也是云平臺的push service更有保障原因。我相信很多云平臺旗下的sdk，多個使用同樣sdk的app，為了實現(xiàn)服務存活，是可以互相喚醒和保證活躍的。另外現(xiàn)在push sdk本身是單連接，多app復用的，這為sdk實現(xiàn)，增加了新的挑戰(zhàn)。

綜上，對我來說，選擇推送平臺，優(yōu)先會考慮客戶端sdk的完善程度。對于服務端，選擇條件稍微簡單，要求部署接入點（IDC）越要多，配合精細的選路策略，效果越有保證，至于想知道哪些云服務有多少點，這個群里來自各地的小伙伴們，可以合伙測測。

go語言開發(fā)問題與解決方案

下面講下，go開發(fā)過程中遇到挑戰(zhàn)和優(yōu)化策略，給大家看下當年的一張圖，在第一版優(yōu)化方案上線前一天截圖~

可以看到，內(nèi)存最高占用69G，GC時間單實例最高時候高達3~6s.這種情況下，試想一次悲劇的請求，經(jīng)過了幾個正在執(zhí)行g(shù)c的組件，后果必然是超時... gc照成的接入方重試，又加重了系統(tǒng)的負擔。遇到這種情況當時整個系統(tǒng)最差情況每隔2，3天就需要重啟一次~

當時出現(xiàn)問題，現(xiàn)在總結(jié)起來，大概以下幾點

1.散落在協(xié)程里的I/O，Buffer和對象不復用。

當時（12年）由于對go的gc效率理解有限，比較奔放，程序里大量short live的協(xié)程，對內(nèi)通信的很多io操作，由于不想阻塞主循環(huán)邏輯或者需要及時響應的邏輯，通過單獨go協(xié)程來實現(xiàn)異步。這回會gc帶來很多負擔。

針對這個問題，應盡量控制協(xié)程創(chuàng)建，對于長連接這種應用，本身已經(jīng)有幾百萬并發(fā)協(xié)程情況下，很多情況沒必要在各個并發(fā)協(xié)程內(nèi)部做異步io，因為程序的并行度是有限，理論上做協(xié)程內(nèi)做阻塞操作是沒問題。

如果有些需要異步執(zhí)行，比如如果不異步執(zhí)行，影響對用戶心跳或者等待response無法響應，最好通過一個任務池，和一組常駐協(xié)程，來消耗，處理結(jié)果，通過channel再傳回調(diào)用方。使用任務池還有額外的好處，可以對請求進行打包處理，提高吞吐量，并且可以加入控量策略.

2.網(wǎng)絡(luò)環(huán)境不好引起激增

go協(xié)程相比較以往高并發(fā)程序，如果做不好流控，會引起協(xié)程數(shù)量激增。早期的時候也會發(fā)現(xiàn)，時不時有部分主機內(nèi)存會遠遠大于其他服務器，但發(fā)現(xiàn)時候，所有主要profiling參數(shù)都正常了。

后來發(fā)現(xiàn)，通信較多系統(tǒng)中，網(wǎng)絡(luò)抖動阻塞是不可免的(即使是內(nèi)網(wǎng))，對外不停accept接受新請求，但執(zhí)行過程中，由于對內(nèi)通信阻塞，大量協(xié)程被 創(chuàng)建，業(yè)務協(xié)程等待通信結(jié)果沒有釋放，往往瞬時會迎來協(xié)程暴漲。但這些內(nèi)存在系統(tǒng)穩(wěn)定后，virt和res都并沒能徹底釋放，下降后，維持高位。

處理這種情況，需要增加一些流控策略，流控策略可以選擇在rpc庫來做，或者上面說的任務池來做，其實我感覺放在任務池里做更合理些，畢竟rpc通信庫可以做讀寫數(shù)據(jù)的限流，但它并不清楚具體的限流策略，到底是重試還是日志還是緩存到指定隊列。任務池本身就是業(yè)務邏輯相關(guān)的，它清楚針對不同的接口需要的流控限制策略。

3.低效和開銷大的rpc框架

早期rpc通信框架比較簡單，對內(nèi)通信時候使用的也是短連接。這本來短連接開銷和性能瓶頸超出我們預期，短連接io效率是低一些，但端口資源夠，本身吞吐可以滿足需要，用是沒問題的，很多分層的系統(tǒng)，也有http短連接對內(nèi)進行請求的

但早期go版本，這樣寫程序，在一定量級情況，是支撐不住的。短連接大量臨時對象和臨時buffer創(chuàng)建，在本已經(jīng)百萬協(xié)程的程序中，是無法承受的。所以后續(xù)我們對我們的rpc框架作了兩次調(diào)整。

第二版的rpc框架，使用了連接池，通過長連接對內(nèi)進行通信（復用的資源包括client和server的：編解碼Buffer、Request/response），大大改善了性能。

但這種在一次request和response還是占用連接的，如果網(wǎng)絡(luò)狀況ok情況下，這不是問題，足夠滿足需要了，但試想一個room實例要與后面的數(shù)百個的register，coordinator，saver，center，keeper實例進行通信，需要建立大量的常駐連接，每個目標機幾十個連接，也有數(shù)千個連接被占用。

非持續(xù)抖動時候（持續(xù)逗開多少無解），或者有延遲較高的請求時候，如果針對目標ip連接開少了，會有瞬時大量請求阻塞，連接無法得到充分利用。第三版增加了Pipeline操作，Pipeline會帶來一些額外的開銷，利用tcp的全雙特性，以盡量少的連接完成對各個服務集群的rpc調(diào)用。

4.Gc時間過長

Go的Gc仍舊在持續(xù)改善中，大量對象和buffer創(chuàng)建，仍舊會給gc帶來很大負擔，尤其一個占用了25G左右的程序。之前go team的大咖郵件也告知我們，未來會讓使用協(xié)程的成本更低，理論上不需要在應用層做更多的策略來緩解gc.

改善方式，一種是多實例的拆分，如果公司沒有端口限制，可以很快部署大量實例，減少gc時長，最直接方法。不過對于360來說，外網(wǎng)通常只能使用80和433。因此常規(guī)上只能開啟兩個實例。當然很多人給我建議能否使用SO_REUSEPORT，不過我們內(nèi)核版本確實比較低，并沒有實踐過。

另外能否模仿nginx，fork多個進程監(jiān)控同樣端口，至少我們目前沒有這樣做，主要對于我們目前進程管理上，還是獨立的運行的，對外監(jiān)聽不同端口程序，還有配套的內(nèi)部通信和管理端口，實例管理和升級上要做調(diào)整。

解決gc的另兩個手段，是內(nèi)存池和對象池,不過最好做仔細評估和測試，內(nèi)存池、對象池使用，也需要對于代碼可讀性與整體效率進行權(quán)衡。

這種程序一定情況下會降低并行度，因為用池內(nèi)資源一定要加互斥鎖或者原子操作做CAS，通常原子操作實測要更快一些。CAS可以理解為可操作的更細行為粒度的鎖（可以做更多CAS策略，放棄運行，防止忙等）。這種方式帶來的問題是，程序的可讀性會越來越像C語言，每次要malloc，各地方用完后要free，對于對象池free之前要reset，我曾經(jīng)在應用層嘗試做了一個分層次結(jié)構(gòu)的“無鎖隊列”

上圖左邊的數(shù)組實際上是一個列表，這個列表按大小將內(nèi)存分塊，然后使用atomic操作進行CAS。但實際要看測試數(shù)據(jù)了，池技術(shù)可以明顯減少臨時對象和內(nèi)存的申請和釋放，gc時間會減少，但加鎖帶來的并行度的降低，是否能給一段時間內(nèi)的整體吞吐量帶來提升，要做測試和權(quán)衡…

在我們消息系統(tǒng)，實際上后續(xù)去除了部分這種黑科技，試想在百萬個協(xié)程里面做自旋操作申請復用的buffer和對象，開銷會很大，尤其在協(xié)程對線程多對多模型情況下，更依賴于golang本身調(diào)度策略，除非我對池增加更多的策略處理，減少忙等，感覺是在把runtime做的事情，在應用層非常不優(yōu)雅的實現(xiàn)。普遍使用開銷理論就大于收益。

但對于rpc庫或者codec庫，任務池內(nèi)部，這些開定量協(xié)程，集中處理數(shù)據(jù)的區(qū)域，可以嘗試改造~

對于有些固定對象復用，比如固定的心跳包什么的，可以考慮使用全局一些對象，進行復用，針對應用層數(shù)據(jù)，具體設(shè)計對象池，在部分環(huán)節(jié)去復用，可能比這種無差別的設(shè)計一個通用池更能進行效果評估.

消息系統(tǒng)的運維及測試

下面介紹消息系統(tǒng)的架構(gòu)迭代和一些迭代經(jīng)驗，由于之前在其他地方有過分享，后面的會給出相關(guān)鏈接，下面實際做個簡單介紹，感興趣可以去鏈接里面看

架構(gòu)迭代~根據(jù)業(yè)務和集群的拆分，能解決部分灰度部署上線測試，減少點對點通信和廣播通信不同產(chǎn)品的相互影響，針對特定的功能做獨立的優(yōu)化.

消息系統(tǒng)架構(gòu)和集群拆分，最基本的是拆分多實例，其次是按照業(yè)務類型對資源占用情況分類，按用戶接入網(wǎng)絡(luò)和對idc布點要求分類（目前沒有條件，所有的產(chǎn)品都部署到全部idc）

系統(tǒng)的測試go語言在并發(fā)測試上有獨特優(yōu)勢。

對于壓力測試，目前主要針對指定的服務器，選定線上空閑的服務器做長連接壓測。然后結(jié)合可視化，分析壓測過程中的系統(tǒng)狀態(tài)。但壓測早期用的比較多，但實現(xiàn)的統(tǒng)計報表功能和我理想有一定差距。我覺得最近出的golang開源產(chǎn)品都符合這種場景，go寫網(wǎng)絡(luò)并發(fā)程序給大家?guī)淼谋憷尨蠹野岩酝鶠榱私档蛷碗s度，拆解或者分層協(xié)作的組件，又組合在了一起。

QA

Q1:協(xié)議棧大小，超時時間定制原則？

移動網(wǎng)絡(luò)下超時時間按產(chǎn)品需求通常2g，3G情況下是5分鐘，wifi情況下5~8分鐘。但對于個別場景，要求響應非常迅速的場景，如果連接idle超過1分鐘，都會有ping，pong，來校驗是否斷線檢測，盡快做到重新連接。

Q2:消息是否持久化？

消息持久化，通常是先存后發(fā)，存儲用的redis，但落地用的mysql。mysql只做故障恢復使用。

Q3:消息風暴怎么解決的？

如果是發(fā)送情況下，普通產(chǎn)品是不需要限速的，對于較大產(chǎn)品是有發(fā)送隊列做控速度，按人數(shù)，按秒進行控速度發(fā)放，發(fā)送成功再發(fā)送下一條。

Q4:golang的工具鏈支持怎么樣？我自己寫過一些小程序千把行之內(nèi)，確實很不錯，但不知道代碼量上去之后，配套的debug工具和profiling工具如何，我看上邊有分享說golang自帶的profiling工具還不錯，那debug呢怎么樣呢，官方一直沒有出debug工具，gdb支持也不完善，不知你們用的什么？

是這樣的，我們正常就是println，我感覺基本上可以定位我所有問題，但也不排除由于并行性通過println無法復現(xiàn)的問題，目前來看只能靠經(jīng)驗了。只要常見并發(fā)嘗試，經(jīng)過分析是可以找到的。go很快會推出調(diào)試工具的~

Q5:協(xié)議棧是基于tcp嗎？

是否有協(xié)議拓展功能？協(xié)議棧是tcp，整個系統(tǒng)tcp長連接，沒有考慮擴展其功能~如果有好的經(jīng)驗，可以分享~

Q6:問個問題，這個系統(tǒng)是接收上行數(shù)據(jù)的吧，系統(tǒng)接收上行數(shù)據(jù)后是轉(zhuǎn)發(fā)給相應系統(tǒng)做處理么，是怎么轉(zhuǎn)發(fā)呢，如果需要給客戶端返回調(diào)用結(jié)果又是怎么處理呢？

系統(tǒng)上行數(shù)據(jù)是根據(jù)協(xié)議頭進行轉(zhuǎn)發(fā)，協(xié)議頭里面標記了產(chǎn)品和轉(zhuǎn)發(fā)類型，在coordinator里面跟進產(chǎn)品和轉(zhuǎn)發(fā)類型，回調(diào)用戶，如果用戶需要阻塞等待回復才能后續(xù)操作，那通過再發(fā)送消息，路由回用戶。因為整個系統(tǒng)是全異步的。

Q7:問個pushsdk的問題。pushsdk的單連接，多app復用方式，這樣的情況下以下幾個問題是如何解決的：1）系統(tǒng)流量統(tǒng)計會把所有流量都算到啟動連接的應用吧？而啟動應用的連接是不固定的吧？2）同一個pushsdk在不同的應用中的版本號可能不一樣，這樣暴露出來的接口可能有版本問題，如果用單連接模式怎么解決？

流量只能算在啟動的app上了，但一般這種安裝率很高的app承擔可能性大，常用app本身被檢測和殺死可能性較少，另外消息下發(fā)量是有嚴格控制 的。整體上用戶還是省電和省流量的。我們pushsdk盡量向上兼容，出于這個目的，push sdk本身做的工作非常有限，抽象出來一些常見的功能，純推的系統(tǒng)，客戶端策略目前做的很少，也有這個原因。

Q8:生產(chǎn)系統(tǒng)的profiling是一直打開的么？

不是一直打開，每個集群都有采樣，但需要開啟哪個可以后臺控制。這個profling是通過接口調(diào)用。

Q9:面前系統(tǒng)中的消息消費者可不可以分組？類似于Kafka。

客戶端可以訂閱不同產(chǎn)品的消息，接受不同的分組。接入的時候進行bind或者unbind操作

Q10:為什么放棄erlang,而選擇go，有什么特別原因嗎？我們現(xiàn)在用的erlang？

erlang沒有問題，原因是我們上線后，其他團隊才做出來，經(jīng)過qa一個部門對比測試，在沒有顯著性能提升下，選擇繼續(xù)使用go版本的push，作為公司基礎(chǔ)服務。

Q11:流控問題有排查過網(wǎng)卡配置導致的idle問題嗎？

流控是業(yè)務級別的流控，我們上線前對于內(nèi)網(wǎng)的極限通信量做了測試，后續(xù)將請求在rpc庫內(nèi)，控制在小于內(nèi)部通信開銷的上限以下.在到達上限前作流控。

Q12:服務的協(xié)調(diào)調(diào)度為什么選擇zk有考慮過raft實現(xiàn)嗎？golang的raft實現(xiàn)很多啊，比如Consul和ectd之類的。

3年前，還沒有后兩者或者后兩者沒聽過應該。zk當時公司內(nèi)部成熟方案，不過目前來看，我們不準備用zk作結(jié)合系統(tǒng)的定制開發(fā)，準備用自己寫的keeper代替zk，完成配置文件自動轉(zhuǎn)數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)結(jié)構(gòu)自動同步指定進程，同時里面可以完成很多自定義的發(fā)現(xiàn)和控制策略，客戶端包含keeper的sdk就可以實現(xiàn)以上的所有監(jiān)控數(shù)據(jù)，profling數(shù)據(jù)收集，配置文件更新，啟動關(guān)閉等回調(diào)。完全抽象成語keeper通信sdk，keeper之間考慮用raft。

Q13:負載策略是否同時在服務側(cè)與CLIENT側(cè)同時做的 (DISPATCHER 會返回一組IP)？另外，ROOM SERVER/REGISTER SERVER連接狀態(tài)的一致性|可用性如何保證? 服務側(cè)保活有無特別關(guān)注的地方? 安全性方面是基于TLS再加上應用層加密?

會在server端做，比如重啟操作前，會下發(fā)指令類型消息，讓客戶端進行主動行為。部分消息使用了加密策略，自定義的rsa+des，另外滿足我們安全公司的需要，也定制開發(fā)很多安全加密策略。一致性是通過冷備解決的，早期考慮雙寫，但實時狀態(tài)雙寫同步代價太高而且容易有臟數(shù)據(jù)，比如register掛了，調(diào)用所有room，通過重新刷入指定register來解決。

Q14:這個keeper有開源打算嗎？

還在寫，如果沒耦合我們系統(tǒng)太多功能，一定會開源的，主要這意味著，我們所有的bind在sdk的庫也需要開源~

Q15:比較好奇lisence是哪個如果開源？

FreeBSD

使用Go實現(xiàn)一個數(shù)據(jù)庫連接池

開始本文之前，我們看一段Go連接數(shù)據(jù)庫的代碼：

本文內(nèi)容我們將解釋連接池背后是如何工作的，并 探索 如何配置數(shù)據(jù)庫能改變或優(yōu)化其性能。

轉(zhuǎn)自：

整理：地鼠文檔：

那么sql.DB連接池是如何工作的呢?

需要理解的最重要一點是，sql.DB池包含兩種類型的連接——“正在使用”連接和“空閑”連接。當您使用連接執(zhí)行數(shù)據(jù)庫任務(例如執(zhí)行SQL語句或查詢行)時，該連接被標記為正在使用，任務完成后，該連接被標記為空閑。

當您使用Go執(zhí)行數(shù)據(jù)庫操作時，它將首先檢查池中是否有可用的空閑連接。如果有可用的連接，那么Go將重用這個現(xiàn)有連接，并在任務期間將其標記為正在使用。如果在您需要空閑連接時池中沒有空閑連接，那么Go將創(chuàng)建一個新的連接。

當Go重用池中的空閑連接時，與該連接有關(guān)的任何問題都會被優(yōu)雅地處理。異常連接將在放棄之前自動重試兩次，這時Go將從池中刪除異常連接并創(chuàng)建一個新的連接來執(zhí)行該任務。

連接池有四個方法，我們可以使用它們來配置連接池的行為。讓我們一個一個地來討論。

SetMaxOpenConns()方法允許您設(shè)置池中“打開”連接(使用中+空閑連接)數(shù)量的上限。默認情況下，打開的連接數(shù)是無限的。

一般來說，MaxOpenConns設(shè)置得越大，可以并發(fā)執(zhí)行的數(shù)據(jù)庫查詢就越多，連接池本身成為應用程序中的瓶頸的風險就越低。

但讓它無限并不是最好的選擇。默認情況下，PostgreSQL最多100個打開連接的硬限制，如果達到這個限制的話，它將導致pq驅(qū)動返回”sorry, too many clients already”錯誤。

為了避免這個錯誤，將池中打開的連接數(shù)量限制在100以下是有意義的，可以為其他需要使用PostgreSQL的應用程序或會話留下足夠的空間。

設(shè)置MaxOpenConns限制的另一個好處是，它充當一個非常基本的限流器，防止數(shù)據(jù)庫同時被大量任務壓垮。

但設(shè)定上限有一個重要的警告。如果達到MaxOpenConns限制，并且所有連接都在使用中，那么任何新的數(shù)據(jù)庫任務將被迫等待，直到有連接空閑。在我們的API上下文中，用戶的HTTP請求可能在等待空閑連接時無限期地“掛起”。因此，為了緩解這種情況，使用上下文為數(shù)據(jù)庫任務設(shè)置超時是很重要的。我們將在書的后面解釋如何處理。

SetMaxIdleConns()方法的作用是：設(shè)置池中空閑連接數(shù)的上限。缺省情況下，最大空閑連接數(shù)為2。

理論上，在池中允許更多的空閑連接將增加性能。因為它減少了從頭建立新連接發(fā)生概率—，因此有助于節(jié)省資源。

但要意識到保持空閑連接是有代價的。它占用了本來可以用于應用程序和數(shù)據(jù)庫的內(nèi)存，而且如果一個連接空閑時間過長，它也可能變得不可用。例如，默認情況下MySQL會自動關(guān)閉任何8小時未使用的連接。

因此，與使用更小的空閑連接池相比，將MaxIdleConns設(shè)置得過高可能會導致更多的連接變得不可用，浪費資源。因此保持適量的空閑連接是必要的。理想情況下，你只希望保持一個連接空閑，可以快速使用。

另一件要指出的事情是MaxIdleConns值應該總是小于或等于MaxOpenConns。Go會強制保證這點，并在必要時自動減少MaxIdleConns值。

SetConnMaxLifetime()方法用于設(shè)置ConnMaxLifetime的極限值，表示一個連接保持可用的最長時間。默認連接的存活時間沒有限制，永久可用。

如果設(shè)置ConnMaxLifetime的值為1小時，意味著所有的連接在創(chuàng)建后，經(jīng)過一個小時就會被標記為失效連接，標志后就不可復用。但需要注意：

理論上，ConnMaxLifetime為無限大（或設(shè)置為很長生命周期）將提升性能，因為這樣可以減少新建連接。但是在某些情況下，設(shè)置短期存活時間有用。比如：

如果您決定對連接池設(shè)置ConnMaxLifetime，那么一定要記住連接過期(然后重新創(chuàng)建)的頻率。例如，如果連接池中有100個打開的連接，而ConnMaxLifetime為1分鐘，那么您的應用程序平均每秒可以殺死并重新創(chuàng)建多達1.67個連接。您不希望頻率太大而最終影響性能吧。

SetConnMaxIdleTime()方法在Go 1.15版本引入對ConnMaxIdleTime進行配置。其效果和ConnMaxLifeTime類似，但這里設(shè)置的是：在被標記為失效之前一個連接最長空閑時間。例如，如果我們將ConnMaxIdleTime設(shè)置為1小時，那么自上次使用以后在池中空閑了1小時的任何連接都將被標記為過期并被后臺清理操作刪除。

這個配置非常有用，因為它意味著我們可以對池中空閑連接的數(shù)量設(shè)置相對較高的限制，但可以通過刪除不再真正使用的空閑連接來周期性地釋放資源。

所以有很多信息要吸收。這在實踐中意味著什么？我們把以上所有的內(nèi)容總結(jié)成一些可行的要點。

1、根據(jù)經(jīng)驗，您應該顯式地設(shè)置MaxOpenConns值。這個值應該低于數(shù)據(jù)庫和操作系統(tǒng)對連接數(shù)量的硬性限制，您還可以考慮將其保持在相當?shù)偷乃剑猿洚敾镜南蘖髯饔谩?/p>

對于本書中的項目，我們將MaxOpenConns限制為25個連接。我發(fā)現(xiàn)這對于小型到中型的web應用程序和API來說是一個合理的初始值，但理想情況下，您應該根據(jù)基準測試和壓測結(jié)果調(diào)整這個值。

2、通常，更大的MaxOpenConns和MaxIdleConns值會帶來更好的性能。但是，效果是逐漸降低的，而且您應該注意，太多的空閑連接(連接沒有被復用)實際上會導致性能下降和不必要的資源消耗。

因為MaxIdleConns應該總是小于或等于MaxOpenConns，所以對于這個項目，我們還將MaxIdleConns限制為25個連接。

3、為了降低上面第2點的風險，通常應該設(shè)置ConnMaxIdleTime值來刪除長時間未使用的空閑連接。在這個項目中，我們將設(shè)置ConnMaxIdleTime持續(xù)時間為15分鐘。

4、ConnMaxLifetime默認設(shè)置為無限大是可以的，除非您的數(shù)據(jù)庫對連接生命周期施加了硬限制，或者您需要它協(xié)助一些操作，比如優(yōu)雅地交換數(shù)據(jù)庫。這些都不適用于本項目，所以我們將保留這個默認的無限制配置。

與其硬編碼這些配置，不如更新cmd/api/main.go文件通過命令行參數(shù)讀取配置。

ConnMaxIdleTime值比較有意思，因為我們希望它傳遞一段時間，最終需要將其轉(zhuǎn)換為Go的time.Duration類型。這里有幾個選擇:

1、我們可以使用一個整數(shù)來表示秒(或分鐘)的數(shù)量，并將其轉(zhuǎn)換為time.Duration。

2、我們可以使用一個表示持續(xù)時間的字符串——比如“5s”(5秒)或“10m”(10分鐘)——然后使用time.ParseDuration()函數(shù)解析它。

3、兩種方法都可以很好地工作，但是在這個項目中我們將使用選項2。繼續(xù)并更新cmd/api/main.go文件如下:

File: cmd/api/main.go

網(wǎng)頁題目：go語言對象池設(shè)計,golang 對象池
鏈接地址：http://chinadenli.net/article12/hecsdc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、、企業(yè)網(wǎng)站制作、全網(wǎng)營銷推廣、品牌網(wǎng)站制作、搜索引擎優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)